It should resolve.
Actually what calculation do you use?
I dont' think the concern is this calc function. It do works correctly for calculation with global storage.
Its goal is to return the number of the repetition in the formula. For instance this formula : 50 * Get(CalculationRepetitionNumber) will result : 50 | 100 | 150 | etc… for each repetition.
But maybe you know that perfectly and encounter another problem.
If this is the case, my guess is that you are maybe trying to use it in a regular repeating field (Text, Number, etc…) with global storage defining the formula into an auto-enter calculation.
Here, global or not, an auto-enter calculation will only start on the first repetition if there isn't any repeating field on the formula. For instance, my example above will not work in that kind of field.
Tell me if i am wrong.
Thanks for the responses.
It was a refresh issue. The file was hosted by FMS13. If you change the global calc formula it doesn't refresh until the file reopen. I guess when the globals for the session are re created. Or that is the way it seems.
Good to know and get the desired result. Have created a test file and screen shot.
I guess un stored global calcs are actually stored for the session. Sorry to bore everyone who already knew this as it is probably legacy knowledge. It's sometimes nice to learn something I probably knew before.
GlobalGetRepSample.fmp12.zip 65.7 K
As i said previously :
"an auto-enter calculation will only start on the first repetition if there isn't any repeating field on the formula."
But i was not accurate enough. When you put a field in the formula of a stored calc, the field must have been changed to "trip" the calc. Generally by the user or possibly by a script...
So you are right, that for what you need, if i see correctly, an auto-enter cannot work.
Autoentering a global is nonsense anyway, one should always have a Startup script firing on firstWindowOpen and set the global(s) starting values in there.
Autoentering a non-global multiple field upon record creation could be a necessity, and it's only possible through autoenter - lookup, not through autoenter - calc.
Our posts are not contradictory, they are complementary.
Given the fact that periodically this question arises on the forum I didn't mind specifying how to do it, shall the need be.
I believe you can't trigger a change in a global without changing a referenced non-global in the same table. Or maybe a referenced global in the same table would work. Now I can't remember how I resolved this.
Or maybe a referenced global in the same table would work.
At least, this one is absolutely true. If the global is on the same table : yes, else : no.
A bit more for future readers,
I re triggered the Global Calc to refresh the storage by setting the storage back to a unstored calc, saving this and exiting Manage DB, then re entering Manage DB, resetting back to Global storage and then restarting FMP.
You would need to do this if you modify the underlying calc formula.
PS: this is again most likely Legacy Knowledge but I had a need with no quick answer.
But first of all : you said the file was hosted, right ?
Be aware that global storage (calc or regular) will not be saved by a connected client when disconnecting.
It may surely contribute your issue… A rapid overview here.
Can you confirm ?
Yes, file is hosted. But was working bottom up, so had initially not considered this in the scenario.
My misdirection came from the assumption that resetting the calc function ( as the field was a calc data type - Not text with auto enter calc ) would reset the storage on the server. When in fact it only sets it when first defined global.
Hence switching back and forth the field storage works. I accept there may be other triggers for this as well but this full fills my needs.
My english is very far as perfect. Hope i understood you. But i can add following :
Yes there is a trick to force the storage from the client to the server and it is precisely what you have done here :
"I re triggered the Global Calc to refresh the storage by setting the storage back to a unstored calc, saving this and exiting Manage DB, then re entering Manage DB, resetting back to Global storage and then restarting FMP."
But that works as an occasional solution.
What i would say is that maybe you could temporarily think your calcs correctly triggered and then quit and reopen FileMaker and then, my gosh : the value false one more time. But it was a supposition, assuming you didn't know this behavior .
And precisely, i wanted to warn you about this behavior, very important to know, when dealing with global fields.
Thanks for sticking with me Fred but we may be talking in "swings and round abouts".
Your point "Be aware that global storage (calc or regular) will not be saved by a connected client when disconnecting."
is not entirely correct - it does when you first define the calc field with global storage on a client. It is stored on the server and supplied to subsequent FMP clients.
Subsequent adjustments to the calc then make no difference at a client or server storage level. It acts like a global set in a local file and then hosted.
This was actually what my need derived from - it was a navigation system where previously I would need to unhost the file to add logic to the global. This has been rectified by the Global Calc which I can trigger by the method I have described above.
But he only exception to this "fundamental" rule is when you change the type of the field when the file is still being hosted and only at this precise moment when you close the manage dialog.
As a side note, it is not really a good practice to make structural design changes on hosted file...
With that said, ok ok, i will not sticking with you because i would not ennoy you.