Stored vs unstored calculations in FileMaker: performance impact
IntermediateStored calculations write their result to disk and are fast to read; unstored calculations are recomputed every time they are accessed. Learn which to choose and how unstored calculations affect performance in large solutions.
What you'll learn
- The difference between stored and unstored calculation storage types
- Which factors force a calculation to be unstored
- How to use indexing and storage settings to control performance
A stored calculation saves its value in the database and only recomputes when its dependencies change; an unstored calculation recomputes every time it is displayed or used in a find — the right choice depends on data size, volatility, and search requirements.
Stuck is a valid status
Need a second brain on this one?
If this lesson just collided with your real schema, script stack, or deadline, book consulting and turn the confusion into a concrete plan.
Understand when a calculation must be unstored
FileMaker automatically makes a calculation unstored if it references fields from related tables, uses context-dependent Get() functions, or references summary or global fields.
// STORED — safe to store, depends only on fields in the same record: FirstName & " " & LastName Subtotal * TaxRate // UNSTORED — cannot be stored (references related table): Sum ( LineItems::lineTotal ) // UNSTORED — cannot be stored (context-dependent Get function): Get ( CurrentDate ) - BirthDate // changes every day // UNSTORED — cannot be stored (references global): gGlobalRate * Price
Sign in to track your progress and pick up where you left off.
Sign in to FM Dojo