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

Poised (or not) for recovery

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

    Poised (or not) for recovery

    Hi all,

    I hope adversity builds character.

    In my current project I am at build 27. Today I noticed a corruption. A form, hangs A5 when I try to save a change to a record. The form is based on a set. The set's default form displays the same behavior.

    To my dismay, I find that the corruption is present all the way back to build 12. That's pretty far. Had I noticed the problem earlier it would have been a simple fix. However I only saw the problem today.

    In my investigations I found that if I went back to build 11 and tried to copy the form to build 12 (after deleting the original) the form did not appear in the versuib 12 control panel (refreshed, compacted). And, as I said, I later found the problem in the default form.

    So I'm asking whether there is there a way to avoid going all the way back to ll and rebuilding. If I were to delete and rebuild the set and it worked would I still be on shaky ground regarding the other dictionaries. Should I just bite the bullet and recreate the whole thing?

    Build 1 of this project was converting the application from Version 4.5. (The project is a giant convert and upgrade.)

    Thanks to all as misery loves company,
    Bill
    Bill Hanigsberg

    #2
    RE: Poised (or not) for recovery

    Bill,

    Where was your problem? In the set? table? form?

    I would think you could salvage something, but not sure where your problem was or what you had to do to fix it.

    I do feel your pain .. been there done that!

    Scott

    Comment


      #3
      RE: Poised (or not) for recovery

      Bill, did you, by any chance, in the interim, make a custom stylesheet - I recently had doing so so mess things up I had to go back to an earlier build - a new form would no longer show up in the control panel, and the form would crash.

      Although I don't know this for a fact, it seemed as if Alpha changed some directory storage info. Anyway, right now, I don't like custom stylesheets - subject to change, of course.
      Cole Custom Programming - Terrell, Texas
      972 524 8714
      [email protected]

      ____________________
      "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

      Comment


        #4
        RE: Poised (or not) for recovery

        This is just a shot in the dark, but can you tell if is the table that is corrupted or an associated file. If it is the table perhaps you can fix it with a utility like Norton Utilities (dos) dbf repair or Dbfsalvage.
        Also I seem to recall that there was an import damaged dbf option in older builds but it doesn't seem to be there now or at least I can't find it.

        Also you could try removing all the field rules and any event code. (maybe on a copy) to see if it makes a difference.

        If it's beyond that it would get tougher. It would sure be nice if there were some sort of a repair utility as this seems to crop up from time to time. I guess the key is test, test, test and backup, backup, backup. And save all the old backups (I'm guilty on that one)

        Good luck (there's not much that's more frustrating- been there)

        Russ

        Comment


          #5
          RE: Poised (or not) for recovery

          Bill

          I do feel the pain. First, backup, backup, backup. But I assume you have done that. I would start with a copy of the database and check out each individual table that makes up the set. Verify that each opens correctly using the default form or browse. If they have any field rules, verify each works. Test each index to see if it is ok by selecting each one with a form open and fetching through records. You may want to delete any indexes created by the set definition.

          After they check out, build a new set just like the original, but with a new name. See if the new one works from the default form. If that works, copy each layout from the old set to the new set one at a time and see if they work. If that all works, resave the set with the original name and retest. If there are any problems, you should see a failure at one of the steps which should make troubleshooting easier.

          That is the careful method. The brute force method is to immediately build a new set with the same name as the original and save it. Since the name is the same, you all of the layouts should still exist. If you are working from a copy, it doesn't matter if it blows up or fails. You can always make another copy and start over.

          Jerry

          Comment


            #6
            RE: Poised (or not) for recovery

            Bill,

            After backing up I would make a new set with the same table relationships ( not using the duplication functionality )

            I would then try to copy the complete trouble form into the new set and see if the form works.

            If it doesn't I would erase it, compact, and then try to copy objects from the old form and see if you can get the new form working that way.

            Basically, I would not assume that corruption in one set meant that everything in the database was corrupted. I would make some serious efforts to salvage some work, but all of it on a newly defined set.

            Good luck

            Comment


              #7
              RE: Poised (or not) for recovery

              Hello to all of you,

              After posting I took an hour off and applied some medicinal alcohol (internally).

              The data is test data. I have real data but the development work is being done on a subset of the live data.

              All of my testing is being done on backups. Each version is backed up and in many cases there there are backups of intermediate builds. I have been unzipping and testing these builds. I am not messing with anything real.

              The problem, Scott, appeared in a form which would not save a change to a record. However, when the set's default form showed the same problem my suspicions moved to the set.

              Martin, I did make a custom stylesheet and I too found it problematic so I backed away from using it further. However, I fear that by that time damage may have been done.

              On my own I have been moving toward what John and Jerry suggest: leave the tables, delete the set, rebuild it and see if the rest of the application is intact. That would not be bad because very few of the changes are on this set or its forms. There are lots of new things added to the application which I would hate to lose.

              Russ, I do not think the problem is with the tables but it is worth checking out. I wouldn't have to repair them at all as I could drop in other copies of the same tables. No field structures have been changed in tables of the bad set. So this is probably the first thing to try even though it is probably not the issue as the fix would be so simple.

              I'll bear down on this tomorrow morning. Meanwhile if anyone has a brilliant thought I hope you won't keep it to yourself.

              Many thanks,
              Bill
              Bill Hanigsberg

              Comment


                #8
                RE: Poised (or not) for recovery

                Bill, just for the record - by the time I realized I had problems (form would not display on control panel, form crashes, etc.) it was too late. I worked and worked and worked.

                If this is the source of your problems, you may be able to fix it ALL by examining the default directory stuff, and maybe look in Alpha5 folder to see if any files are now in there that shouldn't be - ddx, etc. (If I'm correct in assuming that the custom stylesheet problem is that it changes where some things are stored.)

                I just finally gave up on it.
                Cole Custom Programming - Terrell, Texas
                972 524 8714
                [email protected]

                ____________________
                "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

                Comment


                  #9
                  RE: Progress report

                  Thanks, Martin, for the report on your experience. I will nose around looking for funny files; I wouldn't have known to do that.

                  Meanwhile, I seem to have had some success. I am still doing very very careful testing but the following seems to have worked.
                  -from the last good build (500.11) I copied all the files for the set and the two tables in it;

                  -paste them into the first bad build (500.12) and then into the latest build (500.21) with the same results. (Remember that the data was just test data.)

                  The results have been (incredible as it may seem) that everything works normally. Interestingly, replacing just the set files did nothing. The problem was in something about the tables. I didn't test the index files separately. Perhaps I should do that now.

                  Of course, I have lost changes made to the two tables and set but there were very few so I should be able to rebuild them in short order. The big changes and additions were elsewhere in the application.

                  The moral:
                  Even if you keep very closely-spaced backup files during development going back can be very costly in time unless you verify the functionality of each version. This also takes time but it worth it.

                  Second moral:
                  What a good thing Alpha5 maintains separate files for tables, dictionaries, and indexes. Had I been using Access my goose would have been well-cooked, I think.

                  Many thanks to my friends and colleagues on the board for suggestions and support.

                  Bill
                  Bill Hanigsberg

                  Comment


                    #10
                    RE: Progress report

                    Correction: my latest build was actually 500.27 so there really was lots to lose.

                    Bill
                    Bill Hanigsberg

                    Comment


                      #11
                      RE: Progress report

                      Bill

                      One possible problem that I managed to do once was to change a name of a field used in the set defintion. This will cause the set to lock up or crash.

                      Jerry

                      Comment


                        #12
                        RE: Progress report

                        Hi Jerry,

                        I could see how that would happen.

                        But all I did was make some cosmetic changes to one form based on the set. And I added something to the form's on_fetch. That's why I didn't think to test data entry into the form.

                        I've established that these changes are unrelated to the problem by adding them in to the earlier copy. They work fine and so does data entry.

                        I really have no idea how the whole thing happened.

                        Bill
                        Bill Hanigsberg

                        Comment

                        Working...
                        X