You can always trigger a script on OnLayoutLoad/OnRecordLoad to do a ExecuteSQL that store data in a $$Variable that you have on your layout
When you open up the calculation dialog. Notice that you have a "context" drop down at the top of the dialog. This drop down controls what table occurrence you specify for the calculation to use as its "starting point" for evaluating the calculation that you then specify in the calculation dialog.
This context stays the same, and does not change even though you might reference the field from the context of different layouts.
Good morning Frank,
I hope your day is going well. If I understand your question and schema correctly, you said that A was related to B1 and that the calculation field in Table A referenced B1::example_field. This calculation will be resolved based on the relationship, but I think it will only show you the value of the first related record. Hope this is helpful.
Given that a field in table B is the same field regardless of the TO it is referred from it will show the same data no matter which TO you look at it from. The only way I see it would be wrong is if you changed something using layout 1 and you need to be on layout 2 to trigger a script trigger to update.
say your calculation field uses fields A,B & C. you change field D on layout 2 which has a Script trigger on it which then modifies C. So changing D on layout 1 without the script trigger would not update field C.
Thank you for the suggestion Johan. I had considered the ExecuteSQL route, although without the script-trigger and variable option. The thing is that I am planning to use this construct of relations and TOs a lot and downside is that it will cost more calculation time then referring to a 'hard-wired' relationship. At least that is what I assume.
Thank you for the reminder, Bill!
philmodjunk and greatgrey, thank you for your replies. So, what I get is not a coincidence: the context that is set in the field definition rather than the context set for the layout, is the one that will taken.