Refreshing / Updating Calculations

[Steve T Cunliffes]

Hi All,

 

Hoping somebody can help please or just point me in the right direction.  Is there a way to refresh / update calculated fields on a layout.

I have tried a 'Refresh Window' script, 'Refresh Object' script but neither appear to work.

 

At present I am leaving the field's browse mode on in Inspector, as I have discovered through trial and error that when I change/add data then click in the calculated field it activates a refresh..... well in most cases it does. 

 

This isn't ideal as on one particular layout I have 2 calculated fields, plus two portals each with a calculated field (Four calculated fields in total). The alternative is to come out of the layout and go back into it.

 

In trying to find out the answer, I did read a post about using a 'cartesian join' to refresh calculated fields but there were a few negative replies to that post so guessing it wasn't the best method and if i'm honest I was struggling to understand it.

 

Regards

Steve

[comment]

Is there a way to refresh / update calculated fields on a layout.

 

It depends on the type of the calculation:

 

If the calculated field is stored, it will update when one of the referenced fields is modified.  Otherwise it will update on window refresh (scripted or otherwise).  However, if the (unstored) calculation depends on data derived from related records, you might need to flush the cached join results (this is an option of the Refresh Widow[] step) in order to get the calculation to reflect changes made to related records since the last refresh.

[Steve T Cunliffes]

Hi Comment, yes my unstored calculation fields depend on changes made to data in related fields.  Some of the related fields can be more than one level deep however. I'm unsure if more than one level deep you would still class them as related but if the tables are joined in one way or another I suppose you would.

 

I forgot to mention, my database is being developed for use via WebDirect and one article I read suggested not using a flush cached join.

[comment]

one article I read suggested not using a flush cached join.

 

I don't know about that. If the calculation looks at the cache in order to get the result, and that cache no longer represents the actual related records, I don't see that you have a choice but to flush the cache and generate a new one. And yes, this issue is most often encountered when one relationship depends on the results of another - including relationships that are more than one level deep.