Global field values are initially set based on whatever they were when you last opened the file locally by FileMaker Pro app (which is before you uploaded it to the server). If you added these global fields after you began hosting them on FMS, they will be empty (which is what I prefer). Each time you log on, each user can change these values from the initially set local value. The global fields are unique to a given session. If you change it for one user, it does not change it for any other users nor does it reset the original value from the local file. And when that user logs off and then back on, it will be reset to the value it was when last opened locally. So you want to be careful of the values of global fields on the local database before uploading to a server and make sure those values are what you want (e.g., ususally it is preferable that they all be empty).
It sure would be nice if there was a way to change the locally set global field values once hosted, but that is not possible. If you must do that, you have to stop the database on the server, download it, make the changes to the global fields, and upload it to the server to have new standard global values every time someone logs on.
Thnaks Talyor for the detail explanation of the behaviour of Global fields.
This is exactly what my understanding. What I have encountered is two users from two different machines using the Guest account logon a database and have their global fields overwritten by one of another. I supposed they will have two independence sessions even though they both have used the Guest account. I am not sure this is the behaviour of Custom Web Publishing XML as the session instance is running on the server side engine.
Much appreciated if you have any insights for this.
Interesting, I was not thinking of the problem of using the same account to log in at the same time, the [Guest] account. You did explain it in your original question, I just did not understand. You would think having separate sessions would make the global fields behave as expected, but apparently not from what you are saying. I can't explain why the behavior acts as it does. Alternatively, could you try $$Global variables instead? I'll have to keep this in mind when creating anonymous log on sessions to realize that global fields may not be what I expect if multiple people are logged on using the same [Guest] user name. Hopefully someone else will have an explanation of how global fields are handled with simultaneous users. Sorry I wasn't of much help.