I have never used a calculated TABLE field, thought I use calculated QUERY fields all of the time. I found this reference that relates to using this relatively new Microsoft abomination:
In depth discussion of calculated table fields in Microsoft Access, as well as a step by step how to to calculated the quarter of a date in an table field.
codekabinett.com
One of the issues I found when researching for this question is that many online articles blur the definition of a calculated field, apparently conflating them with query-based computed fields. They are NOT the same, as many limitations exist on a "true" calculated table field. One of them is you can't pull data from other tables for a table-computed field. You can only use data from your current table. Another issue is that for table fields, you cannot use the full library of functions that would be available for query fields. A LOT of the article-writers treat such fields as though they were in a query, but what they suggest you can do, you really can't unless you are working in a QUERY with a JOIN of some kind.
Which is why my recommendation is to IMMEDIATELY and FOREVER ditch the table-based computation and instead create a query based on the table but that contains your computed data fields as normal query-based computations. Queries work just FINE as record sources.
Based on what research I could find, your question also appears to not make perfect sense in another way. According to a couple of articles, a computed field in a table is a VIRTUAL construct. It doesn't exist unless the table is open, and thus the field contains no data unless that table is open. So when you imply that it does not update correctly, I think that cannot actually be the case, since it doesn't exist until you open it - at which time it should be able to draw the correct,
current data from its referenced data sources. Stated another way, if a calculated field isn't showing current data, then either its sources were not updated or it is malformed.