4 Replies Latest reply on Feb 14, 2016 12:39 PM by Mike_Mitchell

    Auto-Enter calc philosophical / technical question.

    brsamuel

      First the situation:  I am supporting & continuing to develop in a solution that I did not originally create.  In order to give the user the opportunity to preserve a "snapshot" of data at a given point in time, a found set of record is being copied to another table.  My predecessor created the snapshot table with a great many Auto-Enter calculations based on the source table's fields.  Thus, once a record is created across the appropriate relationship, most of the work of copying data happens automatically.

       

      My question for the community is this: Would you consider this a good method, an ill-advised method, or simply another way to skin the proverbial feline?

       

      My inclination is to leave the schema as simple as possible, and script the process with multiple Set Field steps.  Some fields are already being modified from their source at the time of creation to provide for reporting and other purposes, such as a status field being converted from an ID number, to its english form.

       

      On the strictly technical side, is there a performance penalty using one method over another?  The user is typically creating 50-150 records, and I am using a PSOS script to do the real work.

       

       

      Thoughts?

        • 1. Re: Auto-Enter calc philosophical / technical question.
          Mike_Mitchell

          Auto-enter is going to be faster than Set Field. Of course, Set Field allows you to trap for errors. But if you're concerned about performance, use the auto-enter option.

          • 2. Re: Auto-Enter calc philosophical / technical question.
            brsamuel

            Thanks for your thoughts - It's always nice to get a little input from a Guru.

            • 3. Re: Auto-Enter calc philosophical / technical question.
              jbrown

              I've adopted, on the advice of some wise counsel, the practice of setting every field via scripting or data entry. The reasoning is that by using auto-enter calcs, the logic is embedded in the table-schema section of the database, and is unavailable for changing should the need arise while using an active, live system. Scripted logic is more controllable and accessible–you can easily open a script in a live system, edit its contents, and save the changes. You can also control when something is set, which you can do with an auto-enter calc only with some complex logic.

               

              I'm sure auto-enter calcs are faster, but it really depends on your needs. If you're creating a new record and things need to get set, would it really be much of a difference to a user in terms of speed whether or not you're using auto-enter calcs. I'm not sure; that sounds like a worthy test.

              • 4. Re: Auto-Enter calc philosophical / technical question.
                Mike_Mitchell

                Jeremy Brown wrote:

                 

                The reasoning is that by using auto-enter calcs, the logic is embedded in the table-schema section of the database...

                 

                Kinda the point. The auto-enter fires regardless of context, regardless of delivery vehicle (user entry, CWP, import - with appropriate options selected). And, it's considerably faster.

                 

                ...and is unavailable for changing should the need arise while using an active, live system.

                 

                Nonsense. You've been able to change the Manage Database dialog since, I believe, version 6.

                 

                Whether it's a good idea or not is a different question. There are some risks with changing database schema on a live system (read: you can break things). But then, changing your code on a live system is also fraught with risk - no testing, etc.

                 

                You can also control when something is set, which you can do with an auto-enter calc only with some complex logic.

                 

                Given the original use case, "when" is "when the record is created" - a perfect use of auto-enter. If the conditions change, or you don't always need to make the entry, then yes, you should consider other options.

                 

                Error trapping is another valid reason to consider scripting. This is probably its biggest advantage over the auto-enter. But then, since the auto-enter is set up to fire every time, your calculations should be set up to error-trap inherently.

                 

                And yes, it's much faster. I've tested it myself, and the looping Set Field method is so slow as to be unusable in certain situations (like when creating multiple records).