Yes, they do - there is an explanation of the different ways they work on server, guest, hosted, single-user files in the Help section under Global Fields.
I suggest removing the "global" storage option and just making it an Unstored calculation.
Global field values are global to the user, not to the database. Each guest maintains values in their global fields separate from other guests.
When a guest opens a file, the global field values are copied from the values for the host into the guest. If the guest's global field values are then changed, such as by running a script, they are changed just for that guest. They are not changed for the host or any other guests.
This is intended behavior to facilitate using global fields with scripts. The only way to reset the default value for a global field is to reset it from the host computer. Changes are saved only when the file is closed.
§ User settings that must be retained from session to session cannot be stored in global fields as mentioned above. If you know your database(s) will have multiple users, or if you have the slightest suspicion that it might one day have more than one user, always build a preferences table into your solution! It is far, far easier to put a preferences table in from the beginning than it is to add one later. At the beginning, you may not be sure exactly why you need it or how you will use it, but this preferences table will almost certainly become a vital part of your solution. It may help to think of the users of your database as being simply another kind of data you need to track, therefore requiring its own table. There is no other place to put this kind of information. Each user will have a permanent record in the preferences table and his particular settings are stored there in standard, not global fields. This way the data is always available and you needn’t worry about volatility.
Thank you all for your replies!!
For my FM solution I wanted to create a script to check automatically (on file open) if the last record of a table have the current month.
I would prefer if the script to don't go to the table layout and check the last record. The global was more sleek, fast and secure by using GetNthRecord.
If I use unstored calculation as PhilModJunk suggested, how can i check this field on "file Open" without going to the specific table?
I hear your stated preference, but don't see a reason for it. Many FileMaker DB's go to a specific layout during startup in order to access the needed data, often this is a process that loads a set of global field and/or variables with oft referenced "preferences" type data. This can be done invisibly to the user by freezing the window before changing layouts and the last step of the process can be a go to layout step that returns the focus to the original layout.
If you look up global fields in Help, you'll find that calcualtions with global storage have very unusual rules for how they update. Those rules can make them uniquely useful, but they also, in my experience, make them not useful except for very specific situations.
I was just worried to make the opening step to slow if connected remotely from internet. My solution have an opening script that "visits" already few layouts in order to gather other data and load value lists, I didn't want to add one more layout to pass by.
Anyway the Help File helped me to understand more about globals and now I have a better general view of the situation.
I attach the scrip steps I've added to my script. I will make it open a dedicated layout with only that "last date" field (unstored calculation with the date of the last record).
The test script is working fine and I will apply it to my file.
Thank you all for your help and suggestions!!!
Have a great day!