Database Reference
In-Depth Information
Happily, FileMaker keeps track of these dependencies internally, so when you use
unstored
calculations, it pulls the necessary data down through the hierarchy of dependencies when
your edits call for it. But if you understand how dependencies work, you can make good de-
cisions about when to store data.
Deciding when to Store
When you first create a calculation field, FileMaker makes it a stored field automatically,
if
possible
. Some field values aren't eligible for storage:
▪ If a field depends on any other unstored fields
▪ If a field depends on any global fields
▪ If a field depends on any related fields
▪ If a field depends on any summary fields
If your calculation meets any of these criteria, then FileMaker automatically turns on the “Do
not store calculation results—recalculate when needed” option for you, and it doesn't let you
turn it off. Otherwise, FileMaker automatically stores the field.
▪ An unstored field has to be recalculated every time it appears onscreen or in a report. All
that recalculation can slow your database down, especially if the unstored field is part of
a summary field or a calculation that aggregates many records. So it's best to store a field
unless you need a freshly calculated value every time you see that data.
▪ If you perform a find based on an unstored calculation field, then FileMaker has to go
through all your records one by one, calculating each one as it goes. The result is a slow
search process. If you plan on searching a field, then store it. (For more detail, see the
box below.)
