Each user, including server side scripts--whether by Perform Script on Server or Scheduled, gets their own virtual set of global fields. The changes made to the value of a global field by one is not visible to others nor is the value retained once the session has ended.
Could that explain the trouble you are having?
If not, please describe the trouble in more detail.
global fields are "local to the machine" - so you can't set anything that all users can see. That is, you can't without closing the db and opening it in single-user mode. Then, when you change globals, they become default values. If I remember right, I've used a "public" table with a single record and an X - type join to the main table. This public table had one non-global field for each public need (e.g. LastBackupTimeStamp, or CurrentBatchCode).
Context is everything with FM and this is no exception.
Their is no guarantee that what is in my globals are in yours.
When a script that sets globals runs on server thru perform script on server or server scheduled script only the server knows whats in the globals.
And how do you know that this isn't working?
You won't be able to see the changes to these global fields as two of us have now explained. The only way that you can confirm whether or not they got a value is if this then produces other results in your script that aren't stored in global fields.
Oh, sorry, when I first read your response, I thought you said "Could YOU explain the trouble you are having?" ... that is why I responded with so much detail.
I am moving the fields into a single-record table. making them stored, and will try working with them that way.
Thanks for the help! Obviously, I've been viewing global fields wrong for a LONG time! I always knew variables were local, but I thought once you set a global-storage field, it was set for everyone. Learn something new every day! I guess I will have to go back and look at other scripts/fields now!
If you need to store a value that is accessible to all users across all records, you can set a field in table that is linked via the Cartesian Join operator (x instead of =) to all of the table occurrences where this access is needed.
It also possible to combine local and global storage strategies via a start up script that copies a value from a non-global field into a global field when the file opens. In such case, you edit the local field to make a lasting change to the value and all other users get that changed value the next time that they open the file.
This method is best if you want to preset global values. It has the significant advantage that you don't need to give regular users access to the standard fields that hold the preset values—they only get those values via the global fields—whereas if you use a cartesian join they can access the stored presets directly.