Stored vs unstored calculations in FileMaker: performance impact

Intermediate

Stored 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.

1/2
1

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.

FileMaker Script
// 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
Summary fields in FileMaker: types, uses, and when to choose calculation insteadList() for gathering related values in FileMaker

Sign in to track your progress and pick up where you left off.

Sign in to FM Dojo