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

db compact and recalc field rules

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

    db compact and recalc field rules

    I want to create a button that recalcs the field rules and compacts the db.

    Does it matter which function I run first?

    In other words, should I run a5_databasecompact(.F.) before or after a5_recalc_calc_fields()?
    Cheryl
    #1 Designs By Pagecrazy
    http://pagecrazy.com/

    #2
    Re: db compact and recalc field rules

    Hi Cheryl,

    As Compacting a database is usually used in a development scenario where you have changed various structures, code, calc formulas, etc., I would say that it would be no problem doing it either way...but if something has changed in your calc fields that a database compact would possibly enter into in eliminating old code, calcs, etc then use the recalc second---may as well do it this way just to be sure I guess.

    Is this button to be used on your development copy to aid your own programming or on an actual application (which I believe a database compact is not usually used)?? Just curious as to what you're doing is all! :)
    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


      #3
      Re: db compact and recalc field rules

      Hi Mike,

      This is for a client's use. He is frequently updating indexes, packing tables, and recalculating field rules. I currently have 3 different buttons on a maintenance menu where he performs these tasks.

      We decided that it would be most beneficial to him if the recalculation of field rules was done on a daily basis and he wanted to be able to automate this process.

      Since he does the index updating and packing tables almost daily as well, I figured it would be just as easy to use the compact database since it performs both of these tasks as well as reclaiming unused space in all dictionaries and memo field files.

      Since all of these require exclusive access to the tables/sets and database, I am creating a function that I will automate to run at a specific time every night. His users have been known to leave work without closing down there Alpha applications so we have to build in automatic closing of all Alpha instances as well.

      In addition to the automated process, the client has requested a button that he can manually press anytime when he runs into problems so that he does not have to click the three different buttons that we currently have.

      I am not real familiar with table calculated fields (we have very few in this particular app, but they seem to be critical, someday I will look further into them to see if there is a way we can pull them out of the tables), but in the meantime, they do exist.

      Since I do not normally find myself in a situation where I have personally needed to recalculate field rules, I am not aware if there is anything that is done during that process that would have any effect or interfere with the functions that compacting a db performs (or vica versa).
      Cheryl
      #1 Designs By Pagecrazy
      http://pagecrazy.com/

      Comment


        #4
        Re: db compact and recalc field rules

        Cheryl,

        Anytime two or more "significant" scripts have to be played I would make sure only one of them are being carried out at a time---do believe that if each script you are using are converted to a function then the first function has to finish before the next is started whereas scripts can be carried out at the same time which can cause problems...

        And I still would compact first--You could run just the packing function as I do believe this also reindexes--the compact will do nothing for your user unless they are allowed to change the database itself--forms, objects, etc. ;Then run the recalc.
        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


          #5
          Re: db compact and recalc field rules

          Thanks for the input Mike. I am only using functions, not scripts. And in this particular case, YES, the client does make his own development modifications in addition to modifications that I make for him.
          Cheryl
          #1 Designs By Pagecrazy
          http://pagecrazy.com/

          Comment


            #6
            Re: db compact and recalc field rules

            I think depending upon the situation you may want to re-calc first then compact.

            The only concern I can see at this moment is the re-indexing of the tables. If your calc fields are used in the indexes, then you want them to have the appropriate values re-calculated prior to re-doing the indexes via the database compact.
            Andrew

            Comment


              #7
              Re: db compact and recalc field rules

              Thanks Andrew, I had not thought about that :)
              Cheryl
              #1 Designs By Pagecrazy
              http://pagecrazy.com/

              Comment


                #8
                Re: db compact and recalc field rules

                Cheryl,

                I'll try to explain later tonight when I return, but doing field rule recalc's are a bad idea for any production (operational) environment.
                Regards,

                Ira J. Perlow
                Computer Systems Design


                CSDA A5 Products
                New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
                CSDA Barcode Functions

                CSDA Code Utility
                CSDA Screen Capture


                Comment


                  #9
                  Re: db compact and recalc field rules

                  Hi Ira,

                  That is a very scary comment, because if it is true, I hope that in addition to your explanation later, that you also have an alternative method to accomplish the same task.
                  Cheryl
                  #1 Designs By Pagecrazy
                  http://pagecrazy.com/

                  Comment


                    #10
                    Re: db compact and recalc field rules

                    Hi Cheryl,

                    Let me give you a simple example. Remember, the recalc of field rules applies to all field rules, not just specific ones of interest. It's an all or nothing proposition (for the most part).

                    Suppose you have a field rule with a field with a default value of DATE() holding the record create date. Another field has a calculated field of DATE() holding the date record was last modified (by a human, not a program).

                    If you do a recalc of the field rules, both dates will be changed to the current date, not what was intended.

                    The field rules are intended as a set of rules to be applied while entering and changing data by human input (exception probably being auto-increment). The rules are applied to the record based upon the current values of the database at the time of entry or change.

                    If you have any field rule that depends upon date or time, or the current state of other records at the time, then a recalc of field rules totally invalidates the conditions that they were intended.

                    If you must perform an operation like the field rules, then run a global update or other operations that take in consideration of what must be done to get the correct results.

                    In the above example you, would not update the create date, and may or may not update the last modified date, depending upon intended results.

                    So, to sum up,
                    • Field rules are primarily for human input to tables/sets only
                    • Do not use field rule recalc except to test development copies
                    • Use update operation or other code for other changes similar to field rules
                    Regards,

                    Ira J. Perlow
                    Computer Systems Design


                    CSDA A5 Products
                    New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
                    CSDA Barcode Functions

                    CSDA Code Utility
                    CSDA Screen Capture


                    Comment


                      #11
                      Re: db compact and recalc field rules

                      Thanks Ira. What you are saying makes sense and I can understand the example. Fortunately for me, in this particular application, none of those types of issues apply. The table field rules are limited to things like transformations in most cases. But your example is definitely something that I had not considered.

                      In this case, all we really want to do is recalculate the calculated fields. There is actually only one calc field in one table, which I am currently working on trying to eliminate completely. With any luck, this won't even be an issue any longer.

                      By practice, I do not use calc fields at table level, have never found the need to store something that is calc at the table level. I did not create the original db so I am having to work within some constraints to keep things functioning until I am able to complete the re-design.

                      NOTE: I am using a5_recalc_calc_fields(). Doesn't this only recalc the calculated fields?
                      Last edited by Cheryl Lemire; 12-22-2007, 11:53 PM. Reason: NOTE:
                      Cheryl
                      #1 Designs By Pagecrazy
                      http://pagecrazy.com/

                      Comment


                        #12
                        Re: db compact and recalc field rules

                        Originally posted by csda1 View Post
                        Suppose you have a field rule with a field with a default value of DATE() holding the record create date. Another field has a calculated field of DATE() holding the date record was last modified (by a human, not a program).

                        If you do a recalc of the field rules, both dates will be changed to the current date, not what was intended.
                        Ira, I just did a test on a table that has field that is 'User Entered' with a default date set to Date() and it did not change on a recalc.

                        Originally posted by Cheryl Lemire View Post
                        NOTE: I am using a5_recalc_calc_fields(). Doesn't this only recalc the calculated fields?
                        Cheryl, you may want to take note of this from the help on a5_recalc_calc_fields()
                        Important: If you need to recalculate calculated fields as part of an application, you should use the table.Recalc_CalcFields() method. The a5_recalc_calc_fields() function closes any sessions that are bound to the table whose calculated fields you are recalculating, and this could cause instability in a running application.
                        Tim Kiebert
                        Eagle Creek Citrus
                        A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.

                        Comment


                          #13
                          Re: db compact and recalc field rules

                          Thanks Tim. I did read that in the help files already. In this instance, all instances of Alpha will be force closed so it should not matter. Although, I probably should just change to the other method as a just in case measure :)

                          I am actually hoping to eliminate the need for either of these functions by removing the table level calculated field.

                          later:

                          It is my understanding that default values in field rules are ONLY enforced when a new record is updated?
                          Last edited by Cheryl Lemire; 12-23-2007, 12:39 AM. Reason: add
                          Cheryl
                          #1 Designs By Pagecrazy
                          http://pagecrazy.com/

                          Comment


                            #14
                            Re: db compact and recalc field rules

                            Hi Tim,

                            Originally posted by Tim Kiebert View Post
                            Ira, I just did a test on a table that has field that is 'User Entered' with a default date set to Date() and it did not change on a recalc.
                            I can't check tonight, perhaps you can.

                            Create a bunch of records without the field rule (in other words, a blank date). Then add the field rule for a default date, and create a few more records. I suspect the ones with blanks will be set to the default date. If so, this could be wrong.

                            E.g. imagine those records came from an earlier time before the field existed. If you do a recalc and they are updated, then their "create date" will be current, instead of indicating an unspecified create date by the blank date field.

                            As to the a5_recalc_calc_fields(), I read into that documentation that it updates more than just calculated rules based upon the table and other references on the same page. Not being sure, I would always caution to use the way that is clear cut, not problematical.

                            But if the calc field is based upon the current state of other records of the database at save time, doing a recalc invalidates the whole process, even if the default happens to be OK.
                            Regards,

                            Ira J. Perlow
                            Computer Systems Design


                            CSDA A5 Products
                            New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
                            CSDA Barcode Functions

                            CSDA Code Utility
                            CSDA Screen Capture


                            Comment


                              #15
                              Re: db compact and recalc field rules

                              Hmmm, do you know of documentation that we do not know of Ira? The only thing that I see the function doing is recalculating the calculated fields in a table? I do not see any reference to anything else being updated based on a table or other references on the same page?
                              Cheryl
                              #1 Designs By Pagecrazy
                              http://pagecrazy.com/

                              Comment

                              Working...
                              X