In correct those errors by setting globals in a startup script. So when a user opens the file it gets set to what I want, instead of he last single-user value..., which wouldn't work in your case, cause of the calculation.
For some reason I try to avoid Global Calculations... I either use globals or unstored calculations. But global calculations seem to give me results I don't expect. Hope that helps.
Thanks Richie - glad I'm not alone. Would still like to understand where I went wrong though!
Yes, maybe it's time I figured out why global calcs give me issues as well. I use globals or unstored calcs in all sorts of hosted files and that works fine.
Please elaborate the issue you have. What does your TO's for this look like and what doesn't work. It this for some a "main" menu?
it's not a good idea to use global calculations, for they are (always!) not working properly in hosted mode, as you found out by yourself. If you change your field in a unstored calculation, you will have, what you wanted.
Yep I concur. I don't get the reason for global unstored calculations. Unless you base the calculation on global fields? In any I case I just avoid them.
Was googling a bit and found this...
To accurately evaluate these calculations on the host, FileMaker Pro transfers all the global field values in the current table from the client to the host. If you know that certain global fields will never be used in unstored calculations or record access calculations, you can improve database performance by creating these global fields in a separate table. This will prevent unneeded global field data from being repeatedly transferred to the host.
And the tidbit about global calcs is in here actually...
In short a global calculation really only gets evaluated at record creation and unstored calcs as we know on layout/field changes etc.
Just FYI: Global calculations are stored, not unstored. Weird, I know, but it's true. That's why they evaluate only at record creation or when you change their definition.
Yes, I realize that now :-) Great insight. Guess that the Global and the Global are not the same Globals :-) The one is a static var and the other dynamic :-)
Therein lies the confusion.
Yes, I guess I have never truly grokked the difference… I just know that a (stored) calc field set to the desired value works, and setting it to global does not. Seems like a waste, since we want 1 value for all records, so global would make sense… but it just doesn't work.
Just like in your screen shot, use the same approach that you used for the matchOne field. Our solutions employ a similar c1 (constant = 1) field in nearly every table, for use in relationship matches.