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



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

Extreme problem adding fields to a table.

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Re: Extreme problem adding fields to a table.

    To be clear, and I may be wrong, but I only concern myself with compacts on the developer's side. Not routinely on the user's autoexec side.

    Other than perhaps packing the tables, my gut feeling is that the compact cleans the DDD, DDM, and DDX files, where development takes place. The sem, set, and sex files, too, as well as the adb, alb, alm, and alx files.

    So, I run the DC before I move the files onto the client (Give them an update).

    I have had odd issues, mostly in form design, that disappear after a DC.

    I do not believe a DC does anything on the data side of the files. Anyone have any thoughts on that belief?


    • #32
      Re: Extreme problem adding fields to a table.

      Tom, Craig.

      Here is the problem. If compacting does resolve my initial issue then I will have to add code to compact on the customers side this time. If compacting works and I do not have it do it on all my customers DB then I will either have to fix all of them manually or use that copy and rename thing this time.

      Anyway, about to test it on my install of the app. Will let you know.


      • #33
        Re: Extreme problem adding fields to a table.

        Ok, compacting the DB did not fix the problem. The table still blows up when adding fields.

        Looks like it will be the copy and rename method to get this fixed.


        • #34
          Re: Extreme problem adding fields to a table.

          Compacting updates the indexes as a necessary side effect of the packing. Many developed the habit of compacting the database as an easy way to keep the indexes refreshed.

          The table and set support files you mention are themselves table, index, and memo files where the information noted in ALPHA FIVE FILE TYPES is stored. Until a compact is performed those tables hold records for each change to field definitions, field rules, layouts, etc. The current state of affairs of each aspect is an "active" record. The prior stages are all in deleted records.

          Compacting the database removes those deleted records and rebuilds the support file indexes.
          There can be only one.


          • #35
            Re: Extreme problem adding fields to a table.

            Here is the thing Stan. On my development db I never delete any records in the first place. I have a couple of records in there for demo info only. If anyone adds and deletes a lot of records it would be my customers on their end.

            But as stated above, compacting the db did not fix the problem.


            • #36
              Re: Extreme problem adding fields to a table.

              Should you want to explore support files converted to tables, see attachment.

              Should you want to try it on your own

              Copy the .ddd, .ddx, and .ddm files for one of your tables to a new directory. Do not use your live database files.
              Rename the .ddd to .dbf, the .ddx to .cdx, and the .ddm to .fpt. Do not use your live database files.
              Open Alpha and create a new database in the directory where you renamed the files.
              Use Add table/set and add the table you find.
              You can explore this table like any other.

              Opening the table causes Alpha to create support files for it like any other. do not copy them back to your original database directory. Delete everything in the new directory as soon as you are through investigating so as not to confuse them with your actual database files. Use these instructions at your own risk.

              There can be only one.


              • #37
                Re: Extreme problem adding fields to a table.

                I understand your aversion to the issues which can arise with compacting a database with a corrupt memo file. There are discussions elsewhere about moving all memo fields to a table containing only a linking field and memo fields and then creating a set with a one to one link to the "parent" table where the memos were originally. I don't know if anyone still does that but the benefit is that should there be memo corruption only the child table is involved, not the other.
                There can be only one.


                • #38
                  Re: Extreme problem adding fields to a table.

                  Well the copy table will not work on the wo_header.dbf either. It is like it cannot see fields that are there.

                  Guess it manually fixing all the customers stuff time.


                  • #39
                    Re: Extreme problem adding fields to a table.

                    I compact about 3 times a day on average with a very large app. as soon as stuff starts going a bit goofy and a bunch of changes - compact.
                    Get a cup of coffee.
                    Dave Mason
                    [email protected]
                    Skype is dave.mason46


                    • #40
                      Re: Extreme problem adding fields to a table.

                      Originally posted by DaveM View Post
                      Get a cup of coffee.
                      Now that is some good advice. Off to make a new pot now.


                      • #41
                        Re: Extreme problem adding fields to a table.


                        Your function adds a list of "new" fields to the table in one step.

                        Most of us handle this differently.

                        We create a list of the "existing" fields in the table.
                        We create a list of the "new" fields we want to add, if they're not there already.

                        We do it one "new" field at a time, like this:
                        - step through the list of "new" fields and for each...
                        - check to see if the current "new" field is already in the table, if so do nothing
                        - if not, then add that one field to the table and loop back to the "next" entry in your "new" field list
                        - repeat until all the "new" fields have been checked and added or skipped.

                        Of course, this entire sequence must occur while the script has exclusive read/write access to the table, so checking if the table is in use first is a pre-requisite.

                        Adding new fields one at a time makes it much easier to figure out what happened if an error occurs.

                        Hope this helps.

                        -- tom
                        Last edited by Tom Cone Jr; 09-04-2015, 06:45 PM.


                        • #42
                          Re: Extreme problem adding fields to a table.

                          Tom, the function I use is based off the ones I got from Cal a few years back. I have never had a problem doing it this way.

                          I also did try just adding one field and it still did not work right.


                          • #43
                            Re: Extreme problem adding fields to a table.

                            I ran your script on my system and had no problem with it. There is/are other external factor(s), scripts before or after that is causing this to happen. Without seeing the entire scheme it would be impossible to figure out what is happening.
                            As an alternatives, you might try:
                            In which case, you gather the existing fields, add them to the new fields and restructure the table.
                            2-Duplicate the table structure. Just the structure. Then add the new fields to the new table, append all records to the new table, then rename it to the original table.
                            Of course, you need to backup first.


                            • #44
                              Re: Extreme problem adding fields to a table.

                              99% of the time with new fields in tables for a remote client:
                              I use my installer to:
                              backup the old application completely to another NEW folder.
                              clear the install folder
                              install the files - 1st adb/dbfs/fpt
                              run the 1st adb that will append all data from the backup and do any other needed
                              install the true adb and all support files for the tables and the sets. Basically everything but the dbf/fpt files

                              Client should be good to go at that point because I have fully tested the install on several computers before the send.

                              minor - one or 2 table updates can be handled similarly, but not such a big operation.
                              Dave Mason
                              [email protected]
                              Skype is dave.mason46


                              • #45
                                Re: Extreme problem adding fields to a table.

                                Tracked the problem down to at least 1 corrupt file out of 3. Rebuilt those files and all is well.

                                So it turns out nothing was wrong with the code at all.

                                And I am now compacting my dev database although I now keep extra backup copies instead of the normal 2 copies just in case.