The calculation field should be unstored unless that creates intolerable delays for any commonly performed finds or sorts. If you need the result stored, then the triggered script approach is probably your best option.
Thanks PhilModJunk, but by "unstored" do you mean we should be using it as a variable which we discard and recalc for the next client as compared to having a calculated field in the database?
- Open Manage | Database | Fields
- Find your calculation field, if it's a data field with an auto-entered calculation, change it to a calculation field.
- Double click the field definition to bring up the calculation expression
- Click the storage options... button
- Change storage to Unstored
To keep any calculation fields that refer to Get ( CurrentDate ) up to date, make them unstored calculations if at all possible.
I don't have an "unstored" option on the Storage tab ???
I do have the field currently set as "auto-entered calculated value" and if I deselect this and on the validation tab set the field as
validated by calculation and specify the calculation, which works fine and is
now =Get ( CurrentDate ) ;
thisBD= Date ( Month ( dob ) ; Day ( dob ) ; Year ( now ) ) ;
passed= now < thisBD
Year (now ) - Year ( dob ) - passed
There is still no "unstored" option on the storage tab. I only have Global Storage, Repeating and Indexing sections on this tab.
Can I trouble you to suggest what I am doing wrong?
Regular fields set to auto-entered calculations cannot update when based upon most Get() functions or on related fields. You must set up a CALCULATION type instead and specify it to be 'unstored' as explained.
Sorry, the bit I was forgetting was to change the field format from numeric to calculated. Doh!