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

back up field rules

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

    back up field rules

    just wondering is there any way to store/backup the calculated field rules/entire field rules of a table.

    I am hoping to be able to remove all field rules for a table, so that my manual update/append operation can run faster (this I can do). Once I have completed the operation I would then like to somehow automatically restore the field rules rather than type them back in manually.

    Is it possible to do this by storing all the field rules in a table and then using xbasic script?? Looking for clues.

    #2
    RE: back up field rules

    Since the field rules are stored in a table's dictionary files removing or renaming these files removes the rules. Alpha5 will automatically create new ones but they will contain no rules.

    To reload an application, I backup the dictionary files, delete or rename the dictionary files, run the process and then restore the dictionary files.

    Be sure to verify that the backup is good before deleting anything.

    Bill
    Bill Hanigsberg

    Comment


      #3
      RE: back up field rules

      just to confirm... the dictionary files are the CDX/DDX files aren't they

      Comment


        #4
        RE: back up field rules

        NO! They are the 3 .DD* files only. The .CDX file is the index file. See the Help file for more details.

        You should probably leave the index file in - even if you remove it to speed up the append, you will still have to take the time to update the index later so it really doesn't save any time in the long run. (However, make sure there are no other sessions running with that table open - even in view mode - or the indexes will get updated as each record is appended and that can really take a long time on a large table.)

        By the way, you can also rename the original .dd* files with xbasic, run your update/append, delete the new .dd* files created by A5, and rename the originals back to their original names.

        One thing I'm not absolutely sure of is what this whole process (manual or automated) will do to long field names and index names. I think they will be OK but, since I don't use long names, I can't be positive.

        Cal Locklin
        www.aimsdc.net

        Comment


          #5
          RE: back up field rules

          thanks... now I have plenty of info to play with and sure to come up with the goods (touch wood).

          These forums make learning a breeze

          Comment


            #6
            RE: back up field rules

            Long field names are in the dictionary files; yet another reason to avoid them (long names, that is).

            Bill
            Bill Hanigsberg

            Comment


              #7
              RE: back up field rules

              I have long names (over 10 characters) for my field names.
              and I don't seem to have noticed any problems with my tables or forms afterwards and everything is fine. I did notice that once I deleted the dictionary files, the field names became truncated. However when you copy the dictionary files back, they are restored to their full names.

              What I did I was:

              1. close application
              3. copy/backup application directory to another location
              2. delete table dictionary files (dd*) from original directory
              3. open application (and notice truncated field names)
              4. performed an update operation using the truncated field names (which was very fast for my 50,000+ record table).
              5. closed application
              6. restored/copied dictionary files (dd*) from copy/backup directory
              7. open application (and notice field names restored to original name - no longer truncated)
              8. open relevant form/s to check everything is working fine (all table field rules/calculations work exactly how they should)
              9. Be extremely happy because the whole process is extremely quick and semi-effecient (only an automated process to cover all steps would be more efficient).

              Note: It took me longer to write this message than to perform all the above steps. Eventually i'll look at writing a script to do all the above steps automatically so all i have to do is press a button. For now the above "manual" process is more than sufficient and i don't think the time researching/developing the "automatic" scenario is justified

              A special Thanks guys for pointing me in the right direction !!!!

              Comment


                #8
                RE: back up field rules

                You can use the attached as a starting point provided you send back any nice enhancements!

                This was written originally in 4.6 so it doesn't use any of the data dictionary manipulation functions that came along with V5.

                The function takes five arguments:

                (1) full path to the master table (the table to which records are being appended.
                (2) full path to the "transaction" table
                (both must include the .dbf suffix)
                (3) Empty the the master table or not
                (4) Drop and restore the field rules or not
                (5) Filter the transaction table?

                This was the first "must have" script we wrote when we started trying to auto-update our application. We'd be lost without it.

                Finian
                Finian

                Comment


                  #9
                  RE: back up field rules

                  Hi Finian,

                  Thanks for the script, it will give me something to play with. When I have a little free time I'll go through it in detail and see what I come up with. Any enhancements / modifications made will surely be posted here.

                  I very much appreciate the use of your "starting point".

                  Matt

                  Comment

                  Working...
                  X