That's the way globals work on Server - they are sessio- based for each user. So if I was logged on I could have one vale in the globals and you have a different value while logged on at the same time.
This is normal and expected.
Steve, go to http://help.filemaker.com and enter 3604 into the search field. This gets you to the "Overview" for global fields in FileMaker. Follow the links at the bottom for more information about these gems amd how to use them.
-- sent from my iPhone4 --
To use this and be able to control/update the global fields, I create standards table with 1 record in it. It has one field for each global. Use the startup script to set the global fields from the stored value in the table.
I am also having an issue updating global fields on FileMaker Server Advanced 12.
I have successfully worked with global fields in FM11 for a few years. I am using global fields to display some button labels and graphics on the interface.
When I wanted to update these graphics/labels in FM11 I ran a Scheduled Script on the server to copy the new values into the global fields. These new values would be the "default" values for the global fields when the users logged in from FileMaker Pro again - as they have been updated on the server/host.
In FM12 I am using the same script (the file was converted) - but the new values are not being displayed when users login again. Has anybody else experienced similar issues?
I have created a simple script to test the functionality with the following steps:
Set Error Capture [ON]
Set Field [GLOBAL ; "New Text"]
And this doesn't work! I can't see anything complicated enough to cause a problem!
Default global values can't be reset in a hosted file. They can only be reset in single user mode.
Generally its not a good practice to rely on the default global settings. The best solution is to set all your globals in a script that runs when the user opens the file. That way, you're sure they've been set properly for the user's session.
Sent from my iPad
Actually, Bruce Robertson pointed out that Scheduled server scripts do indeed reset a global's value, just as if the file had been taken local.
So, perhaps this "quirk" is gone from FM12. I would agree with Jim, use a one record prefs table and set globals in an Open script.
Another option than setting the globals via script for each session has been mentioned, using a table to store 1 record (not globals) where all the graphics, and other values referenced by globals can be stored.
Then create global calculation fields which reference the fields of stored data in that one stored record. You can update the contents of the stored fields while the file is served, and the global calcs which reference them will use the updated data even in a served enviornment.
Another option, if you want to update a non-container global as a developer for use in all future sessions, is to make the global text/date/number a calculated result which you can redefine as needed. This is less flexible that the 1-stored-record and calculated references, but will work if you have the need to change a default for all future sessions while logged in as the developer.
Thanks for the replies, this has cleared things up for me - the Scheduled Scripts now run as a client on the server, rather than as the host/server itself (which also explains why the Open Script was being triggered when the schedule started).
I was hoping to avoid the overheads of running this "interface" script at login or having more calculations on the layouts... I guess I will have to pick one or the other!