# How to force a recalculation? **URL:** \ **Category:** Questions\ **Tags:** beginner, gotcha, newbie-error, field-definition, beginner-error, field-type\ **Created:** [January 31, 2023, 9:50pm UTC](https://the.fmsoup.org/t/how-to-force-a-recalculation/3352 "2023-01-31T21:50:34Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![Kirk](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/kirk/32/2197_2.png) [@Kirk](https://the.fmsoup.org/u/Kirk)\ **Post date:** [March 12, 2023, 9:40pm UTC](https://the.fmsoup.org/t/how-to-force-a-recalculation/3352/21 "2023-03-12T21:40:11Z")
@Malcolm Evaluate is field specific; using the LET statement is a just a completely independent field update, that, when it occurs, whatever the rest of the calculation does, executes. 15+ years ago, I use a 1/0 binary state field, but that required checking the content and "flipping the bit" to trigger a recalc; the advantage of using a timestamp field was the timestamp is always different, so the calc is guaranteed to be executed (could have used a UUID but less informative). RCC (Nick) was the impetus to swap over from the binary to timestamp, but the method is the same. ---
**Author:** ![Cecile](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/cecile/32/98_2.png) [@Cecile](https://the.fmsoup.org/u/Cecile)\ **Post date:** [March 12, 2023, 9:54pm UTC](https://the.fmsoup.org/t/how-to-force-a-recalculation/3352/22 "2023-03-12T21:54:16Z")
> [@Kirk](#): > > I update the z\_TriggerTS timestamp fields all at once i by all at once you mean your script does a replace field content? Like the command under the Records tab "Replace field content", but by script? > [@Kirk](#): > > BUT I also have that field set to update on a OnRecordCommit script trigger. That way, any update that would be impacted as individual records change, would have live updates of the calculation. OK for users manual changes ---
**Author:** ![rivet](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/rivet/32/1727_2.png) [@rivet](https://the.fmsoup.org/u/rivet)\ **Post date:** [March 12, 2023, 11:44pm UTC](https://the.fmsoup.org/t/how-to-force-a-recalculation/3352/23 "2023-03-12T23:44:48Z")
**side note** : in your status calc, here is a nice trick someone showed me; ```auto Case( Position ( "Closed|Complete|Cancelled" ; Status ; 1 ; 1 ) > 0 ; "final"; "temporary" ) ``` ---
**Author:** ![Kirk](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/kirk/32/2197_2.png) [@Kirk](https://the.fmsoup.org/u/Kirk)\ **Post date:** [March 13, 2023, 12:14am UTC](https://the.fmsoup.org/t/how-to-force-a-recalculation/3352/24 "2023-03-13T00:14:44Z")
I avoid RFC (lots in another thread on this) because of a myriad of issues around record locking and error trapping. Loop and set fields, but yes, the entire table(s) gets updated in the very early AM. There is also a obscure button on layouts for doing this "manually" with a PSoS - primarily a developer tool to deal with changes that are outside user normal operation, but require an update. At one time, I updated a TODAY field used in calcs, but found the LET based trigger calc to be far more modular and flexible, allowing things other than date based unstored calcs to become [auto-enter] "stored" calcs ---
**Author:** ![Kirk](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/kirk/32/2197_2.png) [@Kirk](https://the.fmsoup.org/u/Kirk)\ **Post date:** [October 13, 2026, 2:12pm UTC](https://the.fmsoup.org/t/how-to-force-a-recalculation/3352/25 "2026-10-13T14:12:12Z")
You'd think, after 20+ years of FM development, nothing new under the sun would show up (excluding new features of course.). But I learned something recently (TY David Head), that I did now know and it changes the long used way I've approached getting rid of unstored calculations. Note: Unstored calcs are, IMHO the bane of FM performance constraints. Honza @ 24U does a lot of these benchmarks like this one. ![Stored_vs_UnstoredCalcs](https://canada1.discourse-cdn.com/flex030/uploads/fmsoup/original/2X/5/5239bdd73a3406f7317c4ba46509722b08ab0ac2.png) An unstored calculation field ALWAYS evaluates every time it is referenced in either code, or display. The conditions that **force** a calculation to be unstored, is - References a field in a related table - References a global variable - References any field where the contents come directly or through reference that contains either of the 2 above The basic concept I use to eliminate unstored calculations remains unchanged; the trick is a LET statement in an auto-enter calc that typically has nothing to do with the actual field calculation. When this variable in the LET part of the calc gets changed, the calculation is forced to evaluate, updating the calculation. Originally I used a variable and reset it to another value (1/0), to force the calc. Later (TY Nick at RCC) I moved to a LET variable set with a Get ( CurrentHostTimeStamp), which ensured 1) that the value changed, and 2) the timestamp reflected when that change was made. This takes a timestamp field in each table to be written to that trigger field to force all the formerly-unstored, now-auto-enter-calc fields to re-evaluate. This also mean that every COMMIT needs to update that trigger field, and if your commit discipline is not perfect, then it is prudent for a nightly loop through all records to update that trigger field and force all auto-enters-replacing-unstored-calc-fields to be updated. Its a lot of work and a lot of discipline, but the performance gains are impressive in cases with unstored calcs. _ **THE REVELATION** _ In the LET statement, change the ...... **~trigger = the timestamp field here** to **~trigger = Getfield ( "" )** Now if any field in the table is modified (commits themselves don't trigger this unless 1 or more field contents have changed), then the LET statement gets updated, forcing the field calc IN THAT RECORD with a field content change to be updated. This field only recalculated if 1) the calculation dependencies get changed or 2) ANY field in that record gets updated. No trigger field, no commit discipline, no batch nightly loop updates.... Only triggers on a field having changed in the record on commit. So WHY does this work? I didn't know (probably a lot I've not heard of 🙂 ) SO Ask Claude and... GetField ( "" ) reads nothing, and ~trigger is never used in the result. Its only job is to put GetField into the formula so that FileMaker registers the dependency on every field. The calculation trigger updates on commit of a CHANGE in any field in that record, because that’s when the field changes are written to the record. Let ( ~trigger = GetField ( "" ) ; ) [Previous page](https://the.fmsoup.org/t/how-to-force-a-recalculation/3352.md?page=1)