'content/result' of new calculation field not showing in existing record - ?field/record? refresh needed?

[yoyo-joe]

my issue - an existing table, fully populated with data, now has an additional/new (numeric) calculation field HOWEVER the new calculation field result (a simple multiplication) does not appear/is not displayed.

context - the existing table has 4 fields, a) item name, b) item qty, c) unit cost, d) item volume; new/added field is e) itemsValue (itemCost * itemQty)

request - any suggestions please on how to obtain a displayed calculation result/value in the new field?

fwiw - creating a new record displays the data as expected/required in all 5 fields.

background - using FMP 19 standalone on Win 11 clean install

regards, yoyojoe

[bcooney]

Is it a calculation field or a number field defined to auto enter ? Auto enters do not update until data is edited. 

[Søren Dyhr]

3 hours ago, yoyo-joe said:

new/added field is e) itemsValue (itemCost * itemQty)

Strictly speaking is should the field ItemCost be a lookup happening when the items Id is entered due to historic fluctuations in price ... It makes it a bit tricky if the population is made via an import if the price meanwhile had changed ever so slightly. But at import, can the auto enters be avoided initially, and then re-trigged later via a scripted replace touching only one of the components by setting it to it-self.... but be carefull here scripted replaces can easily wipe the entire base through in the field it's targeting. 

Auto enters are lightweight when kept up against genuine Calc-fields, but until you have a propper structure up and running, redefine the ItemsValue into an unstored calcfield ... before "clever-ing" it up.

--sd

Edited April 24, 2024 by Søren Dyhr

[comment]

3 minutes ago, Søren Dyhr said:

Auto enters are lightweight when kept up against genuine Calc-fields,

How so? Assuming the calculation field is stored, how exactly is it less "lightweight" than an auto-enter?

 

[Søren Dyhr]

Just now, comment said:

How so? Assuming the calculation field is stored, how exactly is it less "lightweight" than an auto-enter?

I meant unstored calc fields sometimes comes with an overhead, to evaluate backwards ... to me does it look like calc-fields haven't been tried yet?

--sd

[comment]

27 minutes ago, Søren Dyhr said:

calc-fields haven't been tried yet?

My impression is the same as Barbara's.

 

[Søren Dyhr]

12 hours ago, comment said:

My impression is the same as Barbara's.

Mine is the same, but only the later, by being an autoenter - here is a certain snag to it:

Because if you later introduce a new stored calc-field, will it evaluate - despite not being there in the first place when the record is made. Auto enters will only trigger if the components it's made off are modified ... if it's introduced later than the arrival of the components, just as Barbara said. 

More about this topic, here: https://community.claris.com/en/s/question/0D53w00005PKlx3CAD/difference-between-a-number-field-with-calculation-and-a-stored-calculated-field

 

--sd

Untitled.fmp12

Edited April 25, 2024 by Søren Dyhr

[comment]

Hm. When I saw you linked to a discussion on Claris Community, I  thought it would be to this:
https://community.claris.com/en/s/question/0D50H00006ezMr1SAE/calculation-vs-autoenter-calculation-best-practice

 

[Søren Dyhr]

21 minutes ago, comment said:

Hm. When I saw you linked to a discussion on Claris Community, I  thought it would be to this:
https://community.claris.com/en/s/question/0D50H00006ezMr1SAE/calculation-vs-autoenter-calculation-best-practice

 

It’s even better

 

[yoyo-joe]

wow! such a quick response; thank you all for your feedback and for sharing your discussion on this topic.

some of this needs time to digest to better get my head around the terms and principles involved and thereby appreciate the nuances involved; the posted 'example' file helps with that effort.

the remark by bcoony prompted me to review the 'definition' of my newly added field which I had set as type 'numeric' and then I applied a calculation expression to it that yielded the attendent behaviour that was problemmatic for me on this occassion.

I decided to change the field type to 'calculation' and for it to yield a 'numeric' result, this has now resulted in the record(s) updating and displaying their value(s) as I require.  It would seem that I had 'my horse and cart' configured contrary to my intended requirement/result.

in summary, setting a field as type 'numeric' then applying a calculation parameter to it leads to a behaviour that is different to a field set as type 'calculation' then defining its output as 'numeric'.

as my understanding and knowledge of this software deepens I feel I'll be able to take on-broad and better appreciate some its nuances discussed above, for now my issue is resolved.

your prompt feedback, comments and support are all gratefully appreciated.

regards & best wishes,

yoyojoe

[Søren Dyhr]

53 minutes ago, yoyo-joe said:

setting a field as type 'numeric' then applying a calculation parameter to it leads to a behaviour that is different to a field set as type 'calculation' then defining its output as 'numeric'.

In a nut shell - and when you get better could you encounter problems when scaling the solution, very well put in the article Comment linked to: 

Quote

I'd go with a calculation field in a heartbeat. Looking at the bigger/longer term picture I might reconsider...but I'd reconsider based on my own company's needs and how I might want to use the data later...it becomes a very personal and subjective call at that point which no one can make but me.

Calculation field flat-out works...other nuances may be available to you by the other methods.

 

--sd