Database Reference
In-Depth Information
But you can also require a calculation to evaluate whenever it's displayed; for example, when
you switch to a layout that contains the calculation field. Such calculations are considered
unstored , and they have some special uses, as well as some drawbacks.
Figure 16-2. In the Specify Calculation window, when you click the Storage Options button, you
can set global storage and indexing options, just like any other field type. You also get a choice you
haven't seen before: “Do not store calculation results.” This example shows the storage options for
the Invoice::Total Due field, which isn't stored because you want FileMaker to update if you add,
delete, or edit any line item on the invoice. Notice, though, that you can't index unstored calcula-
tions and you can't use an unstored calculation as a key field (page 187).
Whenever the data in a field changes, FileMaker also works behind the scenes, finding all the
stored calculation fields that depend on the changed field, and recalculates them (even if
they aren't on your current layout), storing the new value in the field. Whether it's stored or
unstored, a calculation field usually changes because a field used in the calculation has
changed, as you'll see next. Understanding when fields recalculate and how dependencies
work can help you decide whether it's appropriate to make a calculation field's value un-
stored.
NOTE
When you use a field in a calculation, you can say the calculation depends on the field (or, in other
words, it has a dependency on the field).
Search WWH ::




Custom Search