Long calculation at start-up

[obesefeline]

Hi. I have a system with many related files. A number of the files have a field that calculates whether records have been modified in a given period of time based on the current date. This field is unstored but does appear on the main layout. Each day when I first start up the system, I get a message saying that a date calculation is being performed. This process is long-winded due to the large number of records.

The only time that the modification date calculation field is used is when a script is run (infreguently) that does a find on this field. Is the reason that the unstored field seems to be calculated every day at start-up is because the field appears on the active screen?

Several related files also appear as portals on the initial layout and their mod date calc field also gets updated at start-up. Is this because their main layouts also has include their calc field?

If the above is true, would changing the script to use a different layout and removing this particular field from all other layouts stop the daily updating I'm seeing, i.e., relegating the calculation to being performed only when the script is run?

Thanks for any help.

Doug

[spb]

If the only time you need to use the mod date is during a script operation, then perhaps you should look at letting the script do some or all of the functions of the calculation field and ditch the field altogether. You could have a regular date field in the portal records and have you scripts set this field as part of its operation, for example.

Steve Brown

[CobaltSky]

Hi Doug,

The delay you're experiencing at start-up is due to automatic recalculation of the 'Today' function, which is designed specifically to allow calculations to be *stored*, yet still update when the date changes (but only if/when the solution is closed and re-opened). If all the calcs you have which use the Today function are unstored, then you will be getting no benefit from this (but still experiencing the pain!).

For unstored calculations, you would be better off using the Status(CurrentDate) function, which will return the current date just as the Today function does, but without prompting a recalc every time the database is re-opened (ie it will calculate only on the records that are actually displayed, and only when and as they are displayed).

It goes without saying that any finds performed on these fields will be slow (because they are unstored and therefore cannot be indexed) - but no more so with unstored fields that use the Today function than unstored fields that use the Status(CurrentDate) function in its place.

[obesefeline]

Thanks, Ray. I've made the recommended change and all logic for producing transaction files based on this field work fine. I'll confirm tomorrow if the start-up calc of Today is gone. This system is used by 15 people across North America (on autonomous laptops) and they've suffered this start-up lag each day. They run the script only weekly and during the week work with only several hundred records each. BTW the slowdown of the script is minor.

Doug

[SassyTexan]

A way to check that is close the file and then change the date on your computer to tomorrow, then reopen the database. Oh yeah, make sure youfix your calendar afterwards!