Deep Dive
Who Darren Terry Is and Why This Matters
Darren Terry opens by establishing 26 years of FileMaker expertise—starting at ClariS in technical support, moving through FileMaker Inc., and now leading FileMaker development at Pacific Data Management in San Jose. He's spoken at dozens of DevCons, Pause on Error events, user groups across the country, and published extensively in FileMaker Advisor Magazine and other publications. His credibility matters because the session tackles the calculation dependency tree, a concept that separates confident developers from those who get caught with unexpected behavior. Terry emphasizes that understanding these rules lets you build dependable, predictable systems rather than stumbling through mysterious recalculation triggers. He runs the session interactively, encouraging interruptions and shouting out questions, and admits to being a fast talker—so he invites the room to stop him if he needs to slow down. This isn't abstract theory; it's hard-won battle scars from working on systems ranging from Fortune 500 companies to mom-and-pop shops.
The Four Triggers for Stored Calculation Fields
Terry begins with stored calculation fields, the workhorse of FileMaker development. A stored calc updates in exactly four situations, no more, no less. First, when you define the field—FileMaker calculates and saves the value for every record. Second, when you redefine the field, triggering a recalculation across the entire table. Third, when you create a new record, FileMaker automatically calculates and stores all stored calc values at that moment. Fourth, and critically, when local data in the same record changes. He demonstrates by modifying a local field from 'Darren Terry' to 'Darren Carrie'—the stored calc updates immediately upon commit, not because of the commit itself, but because the referenced local data changed. Terry stresses this distinction repeatedly: the trigger is data change, not the act of committing. When you tab out of the field without committing, the calc still updates because the local value changed. Revert that change, and the calc reverts with it. This four-prong rule is absolute and understanding it prevents the mysterious behavior that catches inexperienced developers.
Unstored Calcs and the Window Refresh Dependency
Unstored calculation fields follow a radically different rule: they update in one and only one way—when the window refreshes. Terry demonstrates by creating an unstored calc referencing a child record value. He changes the child value from 'Apple' to 'Kiwi' and the unstored calc updates immediately when he clicks out. But here's the counterintuitive part: it's not the commit that triggered the update; it's the window refresh that happened because he edited data in a related record displayed on the layout. To prove it, he removes the portal from the layout entirely and repeats the change. When he edits the child record and commits, the unstored calc on the background window does not update—because there's no reason for the background window to refresh. Then he puts the portal off to the side in 'no man's land' and the calc updates again, proving that merely having the portal on the layout (even if not visible) triggers the refresh. Even portals on hidden tab panels, inside popovers, or with conditional visibility set to hide them still cause window refreshes. The rule is simple: FileMaker knows the portal exists on the layout, so it refreshes the window when related data changes, and that refresh recalculates all unstored fields in view.
Why Global Variables Don't Belong in Calculations
Terry addresses a common pitfall: using global variables in calculation fields. He sets up two fields—a stored calc based on a global variable and an unstored calc based on the same variable. He creates a button that increments the global variable without triggering a refresh. When he clicks the button, neither field updates, because global variables are completely outside the FileMaker dependency tree for both stored and unstored calculations. To hammer home the point, he clicks the button several times—nothing changes. Even when the global variable itself is displayed on the layout as a merge field, it doesn't update without a refresh. Then he clicks a second button that does the same increment but includes a refresh. The unstored calc updates because the window refreshed. The stored calc still doesn't update because variables aren't in its dependency tree at all. When he makes a new record, the stored calc shows the current variable value, but that's only because creating a record triggers a recalculation, not because the variable changed. Terry concludes that a stored calculation referencing nothing but a global variable is essentially useless—it won't update on variable changes under normal circumstances. If you need a calculation to reflect a variable's current state, use an unstored calc with a refresh, or better yet, use a global field instead, which is visible in the dependency tree.
Auto-Enter Calculations and When They Don't Fire
A developer asks about auto-enter calculations on text fields versus calculation field types. Terry opens Manage Database and demonstrates. An auto-enter calculation can optionally be set to 'do not replace existing value if any,' which limits it to one evaluation only. If unchecked, it tries to re-evaluate, but the rules of re-evaluation follow stored calculation logic—it updates when local data changes in that record, but not globally. He creates a test field that concatenates a global field and a local field, setting it to auto-enter with the checkbox unchecked. When he changes the global field, the auto-enter updates. But here's the nuance: changing the global field on one record only affects that one record's auto-enter field, not all records. Another developer asks about the 'do not evaluate if all reference fields are empty' checkbox. Terry tests this by clearing both the global and local fields. The auto-enter field goes empty, suggesting the checkbox doesn't prevent re-evaluation when all sources are empty—it simply respects the logic that if everything feeding the formula is null, the result should be null. The takeaway: auto-enter calcs are tempting because they're editable (unlike calculation field types), but they only update in the current record and only under the same four conditions as stored calcs plus whatever local data they reference.
Network Behavior and Multi-Client Scenarios
A developer asks whether changes made by other users on other computers trigger updates. Terry clarifies that when two windows are open to the same file on the same computer, FileMaker treats them as two separate clients, so you can lock yourself out of a record. In a true network scenario, when a user commits a change to a child record, the server sends out a signal. But Clay Maeckel (a Claris engineer in the room) interjects with a crucial clarification: the server doesn't push all the data to all clients. It sends only the row ID of the changed record to all clients. Each client then decides if it needs to request that row's data from the server. If the client has that record displayed anywhere on its current layout, it requests the full row and refreshes. This is why hidden portals still cause updates—the client knows the portal is on the layout and requests the data. If a record ID is way down in a list view outside the visible bounds, the client won't request the data until that record scrolls into view. Terry also notes that while the server optimizes by not pushing container data proactively, it does send the entire row (all fields, not just the changed field) to any client displaying any part of that row. This explains performance implications: if you have a portal on a hidden tab, you're still pulling down all that data on every change, even though users can't see it.
Layout Calculations and Why They're Superior
Moving into part two, Terry introduces layout calculations—text objects on a layout with embedded formulas. Some developers knew about this feature, but not all. Before layout calculations existed, the only real way to embed dynamic content on a layout was through web viewers, which don't work the same way. You could also use button controls or hide conditions to define variables, but layout calculations are more straightforward. They follow the rules of unstored calculation fields but with better behavior: they update on window refresh and don't require a commit. Terry demonstrates by placing a formula directly in a text object: 'This is the related value: [formulaicon] child::value'. When he edits the child record in another window and clicks out, the layout calculation updates. He then removes the portal from the layout, leaving only the layout calculation. When he changes the related data and clicks out, the layout calc still updates—unlike unstored field calcs, which would fail without a refresh. This suggests layout calculations have special knowledge of their dependencies; they work exactly how a developer expects without relying on portal visibility or window refresh quirks. Terry calls them 'bosanova'—they just work. This makes layout calculations ideal for displaying dynamic content without the overhead of calculation fields or the brittleness of unstored calcs tied to visibility.