Global fields have to be set locally on your desktop to stay in the database. I know this sounds weird, but you can't set global fields on the server and expect them to stay after closing the connection.
So, you can
A) take the file off the server and set your global fields and then put the file back on the server or
B) Set the globals with a script when you open the database.
Sent from my iPad
Thanks for that Agnes.
Does that mean you also can't change or update the global fields (to new amounts) on the network... this can again only be done on the local drive after pausing or stopping the database on the FM server opening it directly via Fliemaker advanced changing the global setting and re-starting the database on the server.
Is that correct ?
If the file is served, any modifications of global fields are valid for the current session only. When the user logs in again, the globals will be restored to their default values (entered the last time the file was opened in single-user mode).
I like to have global and regular fields in a ONE RECORD table. The user can change the values in the regular fields. Use a script to populate the globals upon starting a new session. The globals are available to every table and no need to take the file off server to populate globals.
Sigh. I wish we could have an easier way to share this data with every table without the work-around, but there it is...
Think of it as if global values (other than calculated globals) reside on the local client machine if the file is being served, as if they don't become part of what is stored on the server at all. Thinking about like that makes it simpler to see what's going on.
One work around I like when I need a global for the system but need its value to persist in a served environment (rather than for session-specific things like dialogs) is to have a single-record table for "globals". In that table I use a single-record with both global and non-global fields. I can the set a calc to have global storage but use it to read the content of a non-global field with a value that will persist.
The non-global value will stick and be available via the calc which is set as a global. This is for use only with a single-record untility table within the file.
It really depends on the use or purpose of your global field, whether it should stay session specific or is part of a way to update stuff in the system.
A global field's value can only be set permanently when the file is open locally. It the field is created or modifed on the server. The next time the file is opened, it will have the value set the last time the file was opened locally. If the global field was created on the server the field will be empty.
I get around this by creating a table with one record in it. It has one field for each global field. Then use an on open script to set each global field to the correct value when the file opens.
If you want to get fancy, you can set up a layout that lets the administrator modify the initial values for the global fields. You can also use an on close script to store the current values of the global fields in the record. This way the user will get the same values next time.
You can go further and set up the table that stores the initial values to be tied to a user, by having 1 record for each user and default values for new users.
If you need more informarion on how to set this up please let me know.