AnsweredAssumed Answered

Summary field doesn't update when it should.

Question asked by njem on Mar 4, 2011
Latest reply on Mar 4, 2011 by njem


Summary field doesn't update when it should.


 This is a data entry form in browse mode. A form based on the "Recipes" table (this is for a bakery to track costs). See the attached screenshot of relationships. This has a front end and back end and all tables are in the back end, and the relationships are defined in both the front and back end the same.

 "Cost" is an unstored calculation defined as Amount * (Ingredient price::price per bulk unit / Ingredient price::divider to min unit / Recipes::Yield). The Divider is to reduce the bulk cost down to the unit cost, so 5lb of flour costs $x and your going to use it in units of 1lb so the divider is 5. The Yield is how many loaves the recipe makes so we can get down to a cost per loaf. Finally, the field that doesn't update automatically, is "Total Cost" which is a summary total of "Cost", not checked as a running summary, summarize repetitions altogether (don't think that applies anyway).

 If I change the amount or the yield the cost of the item on the portal line updates correctly but the total cost doesn't until I move to another record and back. Even clicking outside the fields to force it to commit doesn't do it.

 I could probably make a script trigger for "on commit" but I'd rather understand when I should and shouldn't expect it to update and how to make it happen without having to script if I can. I saw references here to a window refresh script step so I made a button to execute that and it does it, but that's not a good solution. 

A quirk of this thing is that if I'm on the amount or yield field and change it and immediately click outside fields then all updates as expected. If I change one of those fields and then tab to the next field, or even on to the next line in the portal, the line will change but the Total field doesn't. Even clicking outside fields won't do it then. Then I have to step to another record and back. Not sure if this should be considered a bug or not, but FM is behaving differently depending on the operator's sequence of steps, which doesn't seem right.

 FM 11.0v3 on Win7.