Calculation field not using updated Custom Function

[madmac33]

Hi,

 

i'm not sure if this is the normal practice for Custom Functions. I have made a change to my CF and expected the change to be reflected in the calculation fields that use the CF.

However, all previously defined calculation fields remain stuck to the "older" version of the CF, although the CF may have been radically changed.

To force the newly updated CF to be used, I have to edit the calculation field (in define fields) and make a change to force a recalculation.

 

This seems to be wrong behaviour, it is as if the calculation field copies the CF available at time of field definition/creation (or changes to it).

 

Is there some way to force a recalculation to reflect the changed CF, either automatically or scripted?

 

Or could there be something screwed up in my settings or a version bug?

(using FMP 13.02 Advance)

 

thanks for any advice 

 

Wayne 

[Lee Smith]

It sounds like the calculation field is being stored?

[LaRetta]

i'm not sure if this is the normal practice for Custom Functions. I have made a change to my CF and expected the change to be reflected in the calculation fields that use the CF.

 

Hi Wayne,

 

If you change a CF, any stored calculations which use the CF will not change in response.  You will need to change the calculation to unstored in calculation Storage Options (check Do Not store calculation results).  Exit back to the layout then go back in and unchecking 'do not store'.  It will then adjust.

 

It is considered expected behaviour but it can catch folks off guard as you've discovered.  

I would suspect that the reason is simply because a stored calculation never re-calculates (unless a FIELD referenced within it changes)  It is no different than regular stored field data.  

[madmac33]

It sounds like the calculation field is being stored?

 

 

Hi Wayne,

 

If you change a CF, any stored calculations which use the CF will not change in response.  You will need to change the calculation to unstored in calculation Storage Options (check Do Not store calculation results).  Exit back to the layout then go back in and unchecking 'do not store'.  It will then adjust.

 

It is considered expected behaviour but it can catch folks off guard as you've discovered.  

I would suspect that the reason is simply because a stored calculation never re-calculates (unless a FIELD referenced within it changes)  It is no different than regular stored field data.  

 

Thanks so much - you guys are fantastic!!

 

Problem is now solved. However, i feel embarrassed that I overlooked the "Do Not store" attribute - I have been using Filemaker since version 1 (before Filemaker Plus even!).

I am new to using CFs, they work very well.

 

thanks again

 

Wayne

[bruceR]

Just be careful about what conclusions you draw about unstored calculations.

 

Mostly, you  DO always want the calculation to be stored, where possible.

And that is what LaRetta suggested: temporarily change the calc to unstored; then change it back to stored.

 

This is rarely something that you need to do.

Unstored calculations have an deleterious effect on performance, on find operations, etc.

 

In some calculations, the result cannot be stored, because it is dependent on data from related records.

[LaRetta]

Calculations which reference other unstored calculations, global fields or related fields must be unstored and FM automatically does that for you, checking 'Do not store calculation results'.  However, if you wish to create a calculation which compares and adjusts to the *current date then you must specifically set the calculation to unstored by checking 'Do not store'.  FM will let you make that mistake - it will not check it for you - I never assume it will handle it for me and always ask myself the following questions when in calculation dialogs:

1. Does this calculation really need to exist at all or can you instead use merge variables, conditional formatting, or layout data formatting (in Inspector).  You want to keep tables narrow (fewest fields to get the job done).
2. Do you want it to evaluate if all referenced fields are empty?  Note it says 'if ALL' referenced fields are empty.  Functions do not count and neither do global variables - fields are all that counts in this question.
3. If this calculation needs to exist, when does it need to update? 
4. Does it really need to be indexed?  Fields can be searched even without an index.  Don't index a field which is rarely if ever searched.  Instead set it to none and uncheck 'automatically index...'.  Set key fields to minimal.

So odds are, you've checked  the 'Do Not Store Calculation Results' before when wanting to reference the current date although it might have been called the Today function back then.

 

added blue sentence and following footnote.

 

* this is just one of the many Get() functions which can trip you up and must be manually set to unstored.

Edited January 2, 2015 by LaRetta

[LaRetta]

I just wanted to make sure we were clear, Wayne.  Checking 'do not store' is only the fix to force the custom function to update.  The stored status of a calculation is not dependent upon the custom function (or any function).  A calculation's storage options should be set according to the answers from the points we've listed above.

 

Custom functions can be overused.  If a custom function is required because of recursive need or if it simplifies the developer's life by storing a calculation which is used frequently in a single location then custom functions are valuable.  But when neither of those points are true, they add abstraction and an external location one must review to determine how a calculation is being evaluated ... and that adds unnecessary complexity.

[comment]

It is considered expected behaviour

 

Well, it is the behavior that we've come to expect - but nevertheless, it is either a bug or bad user interface, IMHO. The custom function that a formula references is just as much a part of the schema as the formula itself. If modifying the formula triggers a re-evaluation, then so should modifying the custom function.

[LaRetta]

Good point.  It is a function however, and if we could change how Substitute() worked, would we really expect all DATA which uses it to change through all records in all tables? Does it not take being in a calculation dialog or an edit to a specific record for FM to identify a change and force reevaluation?  How, if we change a custom function, is the data or stored calculation supposed to know to reevaluate?

 

This, to me, is similar to the question of why doesn't a record recognize a change in a related table ... how are the calculations supposed to know the custom function was changed?  Thank you for making me question again.  :-)

[comment]

 if we could change how Substitute() worked, would we really expect all DATA which uses it to change through all records in all tables?

 

 

I would. If I didn't want that to happen, I would have used a Text field, with auto-entered calculation.

[LaRetta]

You are correct ... I should expect it to adjust too; I became complacent.   This was originally reported 4 1/2 years ago http://forums.filemaker.com/posts/c13d0dbd64?commentId=315445#315445.  After all this time, I had just accepted it and I should not have.  It IS a bug as you've explained and I've brought that thread to the front again (hopefully) although I hold out little hope unless more Users push FMI on these issues by posting there otherwise FMI figures if we don't complain further, it is not important to fix.

 

Thank you for hanging with me until I was clear, Michael.  And Wayne, thank you for bringing it up again.  My apology for saying it was expected behavior ... it is NOT expected behavior at all ... it is resigned behavior which is NOT the same thing at all.

[The Shadow]

 

 

Well, it is the behavior that we've come to expect - but nevertheless, it is either a bug or bad user interface, IMHO. The custom function that a formula references is just as much a part of the schema as the formula itself. If modifying the formula triggers a re-evaluation, then so should modifying the custom function.

 

 

You can blame me.  I wrote the first pass of Custom Functions, and there wasn't a good way to make a field dependent on an external item, so I just didn't.

So, the choice eventually became ship what we had, or wait and rewrite the dependency system to allow this.

 

Still, its been years and it hasn't been fixed yet - I would suggest people complain more about it.  It is not like its impossible for them to do.

[LaRetta]

Thank you, Shawn. If it wasn't for you, we wouldn't have custom functions at all!!

 

If we all bring it up again over on that thread where bugs are reported (and specifically in this case http://forums.filemaker.com/posts/c13d0dbd64?commentId=315445#315445) then possibly it could be fixed for FM14 although probably not - it seems a bit too close to next release but at least there is hope for FM15.

 

The problem is ... because we've lived with bugs for years (that FMI knows about and most never get fixed), we assume it does no good to speak up again once FMI knows about it.  I do not believe that is the case.  Telling FMI we are very dissatisfied with their lack of action or policy of silence does not mean we lack loyalty to FileMaker.  

 

Too many FM developers say nothing ... http://en.wikipedia.org/wiki/First_they_came_... and I confess that I've gotten lax (resigned) on it as well.

[rob]

This caused me a problem just today.  I plan to report it also.