Not sure what you mean by trick. Simply create an Unstored calculation and click the Globa storage check box.
So that stated, I was working on a DB the other day and created a Global calculation with a formula of 1. I put the field on a layout and it wasn't populated until I created a new record. Once a record was created the value was there.
The issue if there really is one, is that there was no dependancy. So nothing to get the calculation to evaluate. I could have created a dependancy by putting in a let statement with x = someotherfield and changed the value of someotherfield. This would have told FileMaker to evaluate the formula and produce the result in the field.
When I'm developing a solution stored on FMS, for all standard Global fields, I create a system table with a field/value for each Global. Then in the Open script I initialize all of the global fields. When working on FMS, Global fields don't retain the initial value. This only happens when the file is opened on the local computer.
What the other Bruce proposes is impossible.
The two storage options are mutually exclusive.
If "Unstored" is checked, and you then click "Global" , "Unstored" is turned off automatically.
An unstored calc = a LIVE calc; one that updates when needed.
A global calc CANNOT be an unstored (continuously refreshed) calc.
Thanks for the responses Bruce (s). We are getting somewhere here.
To Bruce Robertson, all I can say it does exist and it is purposeful (not a corruption). I will see if I can create a cut down copy of the file. It is a hack and has been around for long time but may not be possible any more.
Please give me a day.
You are correct. You can click either Unstored or Global.
When I need a Global calculation, I create the Calculation, enter the formula and then check global storeage. FileMaker retains the formula and marks the field as Global. The formula will work, but still has to be triggered either by creating a new record or changing the value of a field in the formula. I believe that it follows the same dependancy rules that a standard/stored calculation field does. Meaning that it updates when a field in the same table is updated. Changes to fields in other/related tables may not update the Global value.
So with that in mind, I created a simple DB with two tables. the tables are linked by standard ID fields relationship. In table 1 I created an Unstored Calc = to a numeric field in table 2 and Global field with the same formula.
I then created a set of linked records and opened 2 windows. first to the record in Table 1 and the second to the matching record in table 2. Changing the source field value in table 2 updates the unstrored calc. However it does not update the Global field.
If I put a copy of the source field in Table 2 on the layout for table 1 and update the value of the source field in either window both the Global field and the Unstored calc update. So putting the related field on the layout appears to trigger the global formula as well.
Oooh, I can't wait to see this!
How about just a screenshot of your field definitions?
If the field is unstored, it will be calced when need ( = accessed) .
What reason is there that should be global ( = same value on all records) ?
Global: same value in all records in all layouts in all files in all modes.
Doesn't seem like that corresponds very well to recalc when accessed (unstored)
Seems like a pretty unreconcilable difference.
1 of 1 people found this helpful
Andrew Markham wrote:
Does anybody know the trick to have Global Calcs become unstored. By this I mean that both the global and the unstored checkbox's are selected and the Fields Options/Comments say 'Global, Unstorted, = bla bla'
I seem to remember this is a trick from a long time ago but can't remember the process to achieve.
There WAS a short period of time (maybe six months) when you could click both 'unstored' and global at same time. It was a bug. I am not sure the version (possibly 9?). I could dig it up if you wish.
So yes, you did not imagine it but no, it is impossible and has been for several years.
In short - give me diffent results based on some other field data and the current layout that is available across the file. 1 TO - beautifully conscise and excellent for Navigation.
v_layout = Get ( LayoutName );
v_delimiter = Navigation::layout_delimiter_gt;
v_part1 = EvalAsValues (v_Layout; v_delimiter ; 1);
v_part2 = EvalAsValues (v_Layout; v_delimiter ; 2);
v_part2 = v_labels; 2;
Thanks for the response LaRetta - if it was indead a missuse of a known vulnerability then I will happily let it stay at that. However if it is a manipulation of known functionaliy I would love the recipe. Or the secret key sequence.
PS: needs to work in FM12+
What version of FileMaker was this DB created in? What version was use to make the screen shot?
Thanks for the screen shot.
I guess the real question, is do those calcs behave differently than a standard global calc (or a standard unstored one, I suppose)? Otherwise it's just a faulty indicator (checkbox). What does it *mean* to be global and unstored? I would assume you'd be able to use that field on any layout, even those based on a TO that don't related to the table of the field. Is that's what's actually going on?
No problems David (Screen shot)
It is functional and not a faulty indicator - which is the problem, it works really well. The global calc fields can be refferenced on any layout (like a global) but resolve based on the occurence (like and unstored calc). Each layout shows a different image (containers) or label (text).