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

Huge .alm file

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

    Huge .alm file

    When I attempt to compact and backup my database, my .alm file grows from about 16meg to over 1gig, and everything on my computer gets very slow. Can anyone tell me what is wrong?

    #2
    RE: Huge .alm file

    Try a search using growing files or the like. This was a problem w/v4.5 but thought v5 addressed the issue.

    kenn
    TYVM :) kenn

    Knowing what you can achieve will not become reality until you imagine and explore.

    Comment


      #3
      RE: Huge .alm file

      Hello Dick,

      You have a corrupt memo field file. This is unusual with the *.alm which is the database library memo file. You can create a new blank database of the same name in a different location, then add in all the tables, scripts, and global operations. Or you could try to copy the *.alm and *.alb to a different location, rename the files *.alm to *.fpt, and *.alb to *.dbf. Now you can use the 'traditional' methods to recover memo fields in a table setting. If you do a search on "corrupt memo fields", you will find quite a bit of info.

      Good luck,
      Jim

      Comment


        #4
        RE: Huge .alm file

        Or you can bring back the files from backup prior to the corruption. Usually a database compact shows this problem, and is why many do periodic backups and compacts.

        To test if a backup is OK, restore and then compact. If the .alm file doesn't grow to gigantic size, you're probably OK. Don't forget to delete the really large file, empty your trash and defrag your drive.
        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


          #5
          RE: Huge .alm file

          Jim -- I am new to Alpha Five, so I'm not understanding completely your suggestion. In order to recover from the expanded *.alm database, I copied the *.alm file from a backup copy into my current database. Seems to work fine, but if I compact it, it will again get big & bring the computer to a virtual halt.

          In my database, I had only one memo file, so I changed it to be a character file. I also deleted a table of Paste Errors which contained memo fields. I don't know what this table is, but the database seems to work fine without it. However, after these changes, I still had the same problem when I compacted the database. The *.alm file grows to over 1 gig, and the computer runs extremely slow, presumably because it is trying to read this file when the database starts up.

          I looked at the *.alm file using "type" in the DOS prompt, and aside from some data at the beginning, the file appears to be empty -- at least nothing displays.

          If you are suggesting copying the files to a different location, where do you propose I move them? If they have been moved to another location, then why rename them? What do you mean by 'traditional methods' to recover memo fields? Is there a database integrity checker akin to the repair database utility in Access?

          I appreciate any help you can offer.

          -- Dick James

          Comment


            #6
            RE: Huge .alm file

            Hello Dick,

            The *.alm, along with the *.alb, is the library file for the database. The library holds global scripts, functions, and some saved operations. The *.alm is the memo field file of the library. Something is corrupted or a pointer is invalid.

            There are several approaches to solving this problem. If your database is fairly simple, it might be easy to just create a new empty database of the same name in a different location. Now you have a new clean *.alb and *.alm. To transfer your scripts, on the code tab, under the 'Code' menu choice you will find the ability to export all your scirpts and functions into a text file. Now you can use this text file to import all the scripts and functions into the new empty database. Most of the operations are stored in the individual table data dictionaries, but you might have some that are stored in the library.

            Now that you have a new clean database, make a copy of your current database for safety, then copy the new *.alm and *.alb from your new database to the location of your old database, over writing the old files.

            The other approach is copy the *.alm and *.alb to a seperate location and rename the file something like this:
            *.alm to test.fpt, and *.alb to test.dbf. Now goto any working database in Alpha Five, from the tables/sets tab right click and choose to Add Table/Set, and add the newly renamed Test.dbf. There is a multitude of things you can do now, but the quick simple thing to try is to use Alpha's built-in memo_check method; "tbl".memo_check(), and let it try to fix your problem. After a successful fix, rename the copied files back to their origional name and copy them back over the working database.........

            Or....

            Just post the two files here and I or someone will fix them for you. It is quick to fix them than to try to write out all the different potential approaches.

            Good luck,
            Jim

            Comment


              #7
              RE: Huge .alm file

              Jim --

              Thank you! Thank you! I followed your instructions, and the *.alm file went from 16meg to less than 1K. The *.alb file was already less than 1K, and it remains that way. I suspect neither of these files contained much of anything, but there was evidently corruption in the *.alm file. I've compacted the database several times, and it seems to work just fine.

              Can I now just delete (using Windows Explorer) the folder that contained the new database?

              Again, thank you for your help.

              -- Dick

              Comment


                #8
                RE: Huge .alm file

                Hello Dick,

                Glad it worked for you.

                ""Can I now just delete (using Windows Explorer) the folder that contained the new database?""

                You have my permission, delete away :-)

                Jim

                Comment


                  #9
                  Re: Huge .alm file

                  I have tried both of your suggestions, but still have unstable global scripts, after having added a 100 or so over the past couple of weeks.
                  Are you still happy to have a look if I post them here (a request almost 14 years after you post I know!

                  Thanks
                  Terry

                  Comment


                    #10
                    Re: Huge .alm file

                    Terry,
                    I believe Jim has retired. Hope not speaking out of turn here.
                    Dave Mason
                    [email protected]
                    Skype is dave.mason46

                    Comment

                    Working...
                    X