Thank you for your post.
I also get the same result. I have sent your post to our Development and Testing departments for review. When I receive any feedback, I will let you know.
Development says this is by design. In essence, you could change the related field's name without the calculation being updated by using external files and not having the calculation field open.
Another workaround may be
Evaluate ( "GetFieldName ( Table2::DATA )" )
Thanks to you and to Dev dept.
From my point of vue this argument is not valid since generally the goal is to use the field name to finally get data, in my case, it was within an ExecuteSQL calc.
So in these cases, the change of a field name won't change the data themselves.
Thanks to you user19752 !
Generally i use this function when i want a formula not to be broken by a change in table or field name.
1 of 1 people found this helpful
happy new year to you + all!
First up, the only reason to use GetFieldName is to make it possible to rename your fields and relationships later without breaking your DB. The expression Evaluate ( "GetFieldName ( Table2::DATA )" ) however loses this benefit as the field name is embedded in a string -> so you might as well just simplify it to "Table2::DATA". :-)
HOWEVER, I really recommend you to:
- avoid the entire practice of storing calculated values which are dependent on related content.
We used this technique for a while in our price fields, referencing a global field of the company's standard currency.
The problem we had occurred in our update process: When we imported the old data all of the stored calculated fields changed their value - because the global field had not been set first!
From this unpleasant experience we (re-)learned the basic principles:
- Stored calculated fields should ONLY reference data stored in the current record.
- Stored calculated fields should NEVER reference data stored elsewhere.
- Add other fields as necessary to the table and look up the related values, and then reference these stored value.
Hope this helps!
Happy new year to you too !!!
I agree with your best practice and fully understand your points.
But i came in a specific situation and found this restriction which was not so logical to me, so i came here to report it. I thought it was a mistake, since GetFieldName have specific usage allowing to refer unrelated Fields.
All the best !