I wonder if you have thought about having a denormalized/cache fields tracking mechanism where one table (“CacheField”) joins the “original” field (table “Field”) to the cache field so that an Update script programmatically can go through records to know which cache fields to set?
If cache fields are updated transactionally they can’t get out of sync, so there’s no reason for an update script. That said, we do have one area that I’m aware of (Party Edit) that we do allow browse mode editing and update the cache fields when the card is closed. There is a small chance that an edited can be committed and the client disconnected before the cache script is run.
The mechanism would consist of two tables - FIELD and FIELDRELATION - where each original data field is connected to its cached fields. Then have an update sub-routine that can search in FIELDRELATION and programmatically get to know what are the cache fields that needs to be updated.