Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Bloated .FPT file is not getting backed up anymore

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Bloated .FPT file is not getting backed up anymore

    I designed a letter with several pictures (not embedded). The picture files themselves are only 20kb total for all of them but saving the report resulted in a bloating of the .FPT file to over 2Gb. Now when I run a backup the FPT file is not included in the backup. This scares me to death because I have already lost to letters mysteriously in this project and now it appears if it happens again, I won't be able to recover using the backup. Obviously at the point I am manually copying the file just to be sure.

    I thought letters and reports were part of the .DDD file but it is the .FPT file that has expanded. It is suposed to be related to memo fields in the table of which I have one in my table but the table data has not changed. 856 records since I started developing an still 856 records. Very few of the memo fields have any data. The .FPT file is selected in the files to backup in the backup settings!

    Is there a known issue where files are not backed up if they get too big? And why would the .FPT file bloat when the dbf is not changing. I packed the database and the .FPT got bigger not smaller. See next paragraph.

    I noticed the backup operation happening very quickly which prompted me to check what was being backed up because before it took a little time to give back control of the IDE. Before creating the letter the .FPT was being backed up as verified in eariler incremental backups. It was backed up when it was 1.5 Gb in size. After packing the database it ballooned up to just over 2Gb and at this point stopped getting backed up. I removed all images from the letter, saved and .FPT file is still at 2Gb and won’t backup. I duplicated the letter without the images, deleted the old one and renamed the new with the same name and the .FPT is still 2Gb and won’t backup. I compacted the database and the .FPT file is still 2Gb and won’t backup.
    It also takes forever to FTP during publishing. Don’t understand why it should be that big? Surely we are able to make letters and reports in alpha without all this bloat.
    Thanks for any thoughts.
    Last edited by Hansolo; 05-27-2009, 11:06 PM.

    #2
    Re: Bloated .FPT file is not getting backed up anymore

    From the control panel, right click on the table and choose the utility to repair memo fields
    Al Buchholz
    Bookwood Systems, LTD
    Weekly QReportBuilder Webinars Thursday 1 pm CST

    Occam's Razor - KISS
    Normalize till it hurts - De-normalize till it works.
    Advice offered and questions asked in the spirit of learning how to fish is better than someone giving you a fish.
    When we triage a problem it is much easier to read sample systems than to read a mind.
    "Make it as simple as possible, but not simpler."
    Albert Einstein

    http://www.iadn.com/images/media/iadn_member.png

    Comment


      #3
      Re: Bloated .FPT file is not getting backed up anymore

      Chuck,
      From past threads here, a bloated memo field basically represents a corrupted memo field....hopefully Al's suggestion works for you.
      Mike
      __________________________________________
      It is only when we forget all our learning that we begin to know.
      It's not what you look at that matters, it's what you see.
      Henry David Thoreau
      __________________________________________



      Comment


        #4
        Re: Bloated .FPT file is not getting backed up anymore

        Actually it is a check and repair and it checked them and reported no errors. But thanks for the suggestion.

        I am absolutly astonished at all the file corrupting issues with this Alpha5V9. I am told it is my environment but what the heck am I to do about that. Everything else works on my system as it should.

        How the heck can the memo fields corrupt when the table has not even been used yet except in the development environment? How can I have any trust in it once I put it online for my client (if I ever get too)?

        What if I delete the .FPT file. Will it get rebuilt since the table still exist in the dbf?

        Comment


          #5
          Re: Bloated .FPT file is not getting backed up anymore

          Ok. So this was my solution. Granted this would be difficult once my client is using it.

          1) Duplicate the data table.
          2) Exported the memo and a key field to an excel file.
          3) Deleted the memo field from the duplicate data table
          4) Deleted the original data table once I was sure the duplicate was correct.
          5) Renamed the duplicate table to the name of the original.
          5) Added A TEXT field with 150 character capacity with same name as previous memo field (after conferring with my client) to the duplicate table instead of a memo field thus avoiding any .FPT file.
          6) Imported the memo data from the excel file into the text field of the duplicate table.
          7) All seems well and no broken links to components.

          Maybe this should be in and Alpha help file somewhere under "what to do when .FPT file bloats for no reason"

          All is well except I cannot verify if the backup would still exclude the .FPT file because I no longer have one.

          I think the fact that the backup utility would not backup the .FPT file after it reached 2Gb needs to be addressed by someone at Alpha. This seems to be a programmed limitation of the utility. There was no error reported it just skipped the file. Just an FYI, when I dragged it into the zipped backup folder it was reduced to 20kb showing how much hot air alpha5 added to the file in the first place.

          Comment


            #6
            Re: Bloated .FPT file is not getting backed up anymore

            Chuck, the article at www.learn alpha.com called "Memos and Browses that work" was written for an earlier version of Alpha Five, and is for desktop environment. However, the design principles discussed there should be employed, in my opinion, whenever you include a memo field in your table structures. -- tom

            Comment


              #7
              Re: Bloated .FPT file is not getting backed up anymore

              Chuck

              How much data do you have in those fields?

              I'd be interested in the number of records and the average number of characters in the field.

              Are you actually storing the pictures in the field or a reference to them stored outside of the table?

              What format are the pictures?

              I (almost always) store pictures in an image reference field - which is a memo field, but doesn't have the special characters that a picture has in it.

              The dbase version that Alpha is based on has a 2 gb file size limit. Memo fields are handy for large amounts of data in a field, but are still limited to the 2gb file size.

              They also have a down side in the way that the data is stored and addressed. There can be wasted space that is acceptable when when memos are actually needed, but if no data exceeds 255 characters, memos are not needed.... Of course there wasted space in a 255 character field that only holds an average of 150 characters....

              You can google about dbase and memo fields and learn alot more about their internal structure. Dsalvage is a dbase utility that I used on Alpha and Foxpro tables that has helped explain and repair problems.

              But since the Alpha utility didn't find an issue, and a character field will work, you probably have a situation where a memo field is not the best choice.
              Al Buchholz
              Bookwood Systems, LTD
              Weekly QReportBuilder Webinars Thursday 1 pm CST

              Occam's Razor - KISS
              Normalize till it hurts - De-normalize till it works.
              Advice offered and questions asked in the spirit of learning how to fish is better than someone giving you a fish.
              When we triage a problem it is much easier to read sample systems than to read a mind.
              "Make it as simple as possible, but not simpler."
              Albert Einstein

              http://www.iadn.com/images/media/iadn_member.png

              Comment


                #8
                Re: Bloated .FPT file is not getting backed up anymore

                Originally posted by Tom Cone Jr View Post
                Chuck, the article at www.learn alpha.com called "Memos and Browses that work" was written for an earlier version of Alpha Five, and is for desktop environment. However, the design principles discussed there should be employed, in my opinion, whenever you include a memo field in your table structures. -- tom
                Interesting, but not really informative. What is the point of each of the secrets?

                There are a few secrets to maintaining reliable memo fields:
                1) All new memo fields are created using Xbasic. They are then edited by the user in a form that does not allow navigation off the record.
                2) All navigation through tables is done when the tables are in read-only mode. When editing is allowed, navigation is turned off.
                3) Deletion is not allowed in our application, but if deletion is required, it also should be done through Xbasic.
                Correct me if wrong but in the WAS environment memo feilds are created using xbasic as suggested above. Navigating off the record does nothing to the underlying table. Is there a suggestion that one can somehow both edit and navigate at the same time. One has to submit any changes at least in my designs using the WAS. If one navigates away then the edit was not submitted in any way shape or form. Again, using web components or dialogs that allow a Delete are using xbasic as far as I know. Am I wrong?

                Hard for me to get best practices that don't define why it is being done. Does this somehow prevent .FPT file bloat?

                Comment


                  #9
                  Re: Bloated .FPT file is not getting backed up anymore

                  Originally posted by Al Buchholz View Post
                  Chuck

                  How much data do you have in those fields?

                  I'd be interested in the number of records and the average number of characters in the field.

                  Are you actually storing the pictures in the field or a reference to them stored outside of the table?

                  What format are the pictures?

                  I (almost always) store pictures in an image reference field - which is a memo field, but doesn't have the special characters that a picture has in it.

                  The dbase version that Alpha is based on has a 2 gb file size limit. Memo fields are handy for large amounts of data in a field, but are still limited to the 2gb file size.

                  They also have a down side in the way that the data is stored and addressed. There can be wasted space that is acceptable when when memos are actually needed, but if no data exceeds 255 characters, memos are not needed.... Of course there wasted space in a 255 character field that only holds an average of 150 characters....

                  You can google about dbase and memo fields and learn alot more about their internal structure. Dsalvage is a dbase utility that I used on Alpha and Foxpro tables that has helped explain and repair problems.

                  But since the Alpha utility didn't find an issue, and a character field will work, you probably have a situation where a memo field is not the best choice.
                  Al,

                  Sorry my original post is somewhat fragmented. My original thought was that the .FPT file was somehow growing because of edits I was doing to a letter in alpha5. The letter contained the pictures. And I was having issues with the letter file disappearing.
                  Then I remembered the file structure of alpha 5 and verified in the help that the .FPT was related to memo fields. This surprised me because I started the project with a data table that has no pictures or references to pictures. It has 30 fields of which one was originally a memo and 10 calculated fields. IT has 856 records of which 100 records have memo data and 30 up to 200 characters. All the data was imported and all was well. The data in the table has not been changed in any way since it was imported. (Except now that I removed the memo field). I have been building the web application around this data.

                  YES, I actually do need a memo field here because future use of the app will require extensive notes but I don�t need any more headaches from Alpha5 so we are going to do with two or more text fields as a memo.

                  Comment


                    #10
                    Re: Bloated .FPT file is not getting backed up anymore

                    Chuck

                    Your message here along with the other thread that you have going about web files missing tells me that something else is going on here...

                    I'm not sure what, but both of this issues shouldn't be happening individually. And together they are quite puzzling. The structures of the memo fields and the web files are completely different and so the problems aren't related within Alpha.

                    But moving files/projects/databases around on your system or restoring parts of the system without restoring all of the pieces can cause this type of problem. Been there done that...

                    Also hardware failures or abnormal ending of the Alpha program can cause that too? What ever happened to the abend?

                    Are there any other strange occurrences that might help diagnose the problem?
                    Al Buchholz
                    Bookwood Systems, LTD
                    Weekly QReportBuilder Webinars Thursday 1 pm CST

                    Occam's Razor - KISS
                    Normalize till it hurts - De-normalize till it works.
                    Advice offered and questions asked in the spirit of learning how to fish is better than someone giving you a fish.
                    When we triage a problem it is much easier to read sample systems than to read a mind.
                    "Make it as simple as possible, but not simpler."
                    Albert Einstein

                    http://www.iadn.com/images/media/iadn_member.png

                    Comment


                      #11
                      Re: Bloated .FPT file is not getting backed up anymore

                      Originally posted by Al Buchholz View Post
                      Chuck

                      Your message here along with the other thread that you have going about web files missing tells me that something else is going on here...

                      I'm not sure what, but both of this issues shouldn't be happening individually. And together they are quite puzzling. The structures of the memo fields and the web files are completely different and so the problems aren't related within Alpha.

                      But moving files/projects/databases around on your system or restoring parts of the system without restoring all of the pieces can cause this type of problem. Been there done that...

                      Also hardware failures or abnormal ending of the Alpha program can cause that too? What ever happened to the abend?

                      Are there any other strange occurrences that might help diagnose the problem?
                      Have not had any abnormal ending of Alpha except one time in an unrelated test project where I tried to embed a word document into a report via the OLE control. Should have worked but just hung Alpha so I had to terminate the process.

                      As for hardware problems there better not be any and I doubt they would be occurring on two separate systems the same way. Both my systems have been rock solid reliable and I have had unusually stable experiences with my programs on Windows Vista and XP by any standard.

                      Moving files/projects/databases around? I don't move anything that alpha does not provide a tool for unless alpha forces me to perform workaround.

                      I create the project, I backup the project, I publish the project, I pack the data, I check the indexes.

                      Workarounds: Alpha would not back up the .FPT file in a project even though it was selected to backup in the settings. Forced to do it manually.

                      If you create a project, Publish said project and then add elements like reports and letters to the project then there is no facility to publish those .DDD, .DDX� etc files so that the change can take place on the server without overwriting the dbf. So you have to copy those manually to the server.

                      If that is what you mean by moving files/projects/databases around then I am guilty but please tell me what other options I have using Alpha5?

                      Ever since I started using A5V9 it has been a strange occurance. I am about to tell my clients I made a big mistake and will go back to A5V8. Started developing some new databases for new projects after a layoff for a year and thought I would reward myself with the newer version. The reward has been a punishment so far. :-)

                      Comment


                        #12
                        Re: Bloated .FPT file is not getting backed up anymore

                        I encountered this problem several times now. Once was with picture files, and I have to painfully change them all to picture reference.

                        Now I get it again when I am using memo field in the table, and the FPT file bloated to 1.77G when I really only have less than 5K letters in the fields.

                        My solution to the problem is to change my memo field to character with 100 length, and it seems to recover my data back. I guess I better not to use memo fields for the web app from now on?

                        Comment


                          #13
                          Re: Bloated .FPT file is not getting backed up anymore

                          Originally posted by hungry4grace View Post
                          I encountered this problem several times now. Once was with picture files, and I have to painfully change them all to picture reference.

                          Now I get it again when I am using memo field in the table, and the FPT file bloated to 1.77G when I really only have less than 5K letters in the fields.

                          My solution to the problem is to change my memo field to character with 100 length, and it seems to recover my data back. I guess I better not to use memo fields for the web app from now on?
                          Thanks for confirming this and the memo field problem which I posted last week. Both you and I are not the only ones with these problems judging by the comments of others. I also cannot use memo fields and have to resort to character. Of course I only develop webapps with alpha5 so can’t speak for other environments. It is a shame because having the memo field available tends to make one think it can be used but using it handicaps the database so horribly you would think there would at least be a warning.

                          I am going to use picture reference in my next report. I avoided it on purpose initially to keep from having more file management in the project but you seem to indicate it is the better way to go and I certainly cannot create another report without the .ddm file getting to big and acting up again.

                          I wish someone from Alpha would comment on these file size issues. Do they really expect that these reports and letters are going to be nothing but text? The bloating issue for .ddm and .fpt is so repeatable they have to know about it.
                          Last edited by Hansolo; 06-02-2009, 08:48 PM.

                          Comment


                            #14
                            Re: Bloated .FPT file is not getting backed up anymore

                            Originally posted by Hansolo View Post
                            ... Of course I only develop webapps with alpha5 so can�t speak for other environments.
                            So, wouldn't it make more sense to post all of this in the Application Server forum? You might actually get better help there.

                            In reference to the "Memos and Browses that work" article on Learnalpha.com you wrote:
                            Originally posted by Hansolo View Post
                            Interesting, but not really informative. What is the point of each of the secrets?
                            Since many of us long ago found that article to be very informative and the "secrets" fairly obvious, your statement to the contrary is at the very least interesting.

                            Good luck with your problem.

                            Raymond Lyons

                            Comment


                              #15
                              Re: Bloated .FPT file is not getting backed up anymore

                              Hansolo,

                              As a developer you should understand that in the database environment there are the tools used for development(Alpha) and then there is the DB engine. While Alpha comes packaged with a DB backend to allow people to immediately start developing, it is not limited to only dBase/foxpro files. Perhaps since you may not be aware of the delicate nature of the dBase/foxpro file system, you might want to explore something else like MySQL, for example.

                              Comment

                              Working...
                              X