8 Replies Latest reply on Jul 24, 2013 4:45 PM by deathrobot

    Getting rid of unstored calcs

    deathrobot

      Title

      Getting rid of unstored calcs

      Post

           I am trying to eliminate as many unstored calcs as possible. Is there a rule of thumb as to the best method to use based on the situation? For example, if there is a calulation that will not change very often (e.g. a field in a parent table that creates a comma delimited list of a field's contents from all child records) would an auto-enter calc be a good way to go? Or should I be setting field values with scripts? Or…?

           Thanks,

           Michael

        • 1. Re: Getting rid of unstored calcs
          philmodjunk

               I would not eliminate unstored calcs unless there is a specific reason to do so. Many unstored calcs need to be exactly that and replacing them with fields that are updated via other means can result in major delays in updating those values when a value used in the calculation changes.

               Auto-enter calcs do not update when a referenced value in another record, such as the fields in your List example, change.

          • 2. Re: Getting rid of unstored calcs
            deathrobot

                 Thanks for the reply, PhilModJunk. I will leave the fields as they are. I was curious about the ability to speed up layout redraws, searches, etc., mostly as a result of hearing Matt Navarre say he tried to use almost no unstored calculations, instead using scripts to manage everything. Sounds like I would only get myself into trouble. Thanks for the warning.

                 Michael

            • 3. Re: Getting rid of unstored calcs
              philmodjunk

                   I would test my layouts on the systems they will be run by temporarily removing unstored calcs from the layout. Some environments are much more sensitive than others to such delays--iOS devices (ipads, ipods andi phones). Also, unstored calculations will very greatly depending on the calculations so identifying the ones that signficantly impact screen redraw and figuring out an alternative approach just for those fields and only if the delays are unacceptable would make more sense to me.

                   Using scripts, not auto-entered calculations, to update data fields (number, text, date...) can be made to work, but great care must be taken in their implementation to make sure that you do not introduce errors in your scripts/triggers that result in the script managed data fields receiving an incorrect value due to an update being missed or accidentally applied twice. And some scripts used to update those values can carry their own performance penalties--especially if they must update large numbers of records.

              • 4. Re: Getting rid of unstored calcs
                deathrobot

                     Thanks, PhilModJunk. Sensible advice. Do unstored calcs affect speed at all if they are in the table but not on the layout?

                     Michael

                • 5. Re: Getting rid of unstored calcs
                  philmodjunk

                       They should not affect the speed unless some aspect of the current layout references them. That is more than just whether or not they are placed on the layout, however. Another calculation that is on the layout could reference such a field or that field might be the match field in a relationship and you have layout objects that use that relationship to display data or it's part of a portal filter expression or conditional format....

                       Note that conditional formats should also be used sparingly on iOS layouts or for layouts used by WAN clients (Wide area network).

                       I've been thinking about this a bit more....

                       The nature of the unstored calculation is key. Replacing  an unstored calculation that returns the value of a get ( function ) with a data field that is updated via a script that uses that same get function isn't likely to produce a noticeable difference in how the layout updates, it could even be slower to update in some cases.

                       On the other hand, a field that has to reference multiple values over multiple records, (summary fields, aggregate functions such as sum, count, max, list etc.) are the items most likely to impose a performance penalty on your layout updates and are your prime candiates for using a script to update a data field instead of using a calculation or summary field.

                  • 6. Re: Getting rid of unstored calcs
                    deathrobot

                         Okay, that's interesting. Ironically, the count, sum, list, etc. functions are the ones that would usually need to be updated a lot.

                         Michael

                    • 7. Re: Getting rid of unstored calcs
                      philmodjunk

                           Yes, but they are updated from a many to one perspective. In otherwords, when a change is made to one of the "many" records, a single record in a parent table has to be updated and that doesn't necessisarily require a lot of processing to do.

                           What you want to avoid are scripted upates to a field on the "one" side that require pulling up and updating large numbers of records on the "many" side.

                      • 8. Re: Getting rid of unstored calcs
                        deathrobot

                             That's a great way of thinking about it. Thanks!

                             Michael