I'm not familiar with using globals in web services, but is this a case where globals retain the last value of the fields when the file was local?
Try taking the file offline, clearing out the globals, then putting it back on the server.
As I understand globals doesn't need any commit to change the data. You would have to script the change. Not sure why it isn't saving that way. You don't even need any records in a table with globals. An all-global table can have 0 records and the globals still be in use.
I will give that a try.
Global fields in FM, only exist per session, per account.
The inimitable Ray Cologon (http://www.nightwing.com.au/FileMaker/) offered the following analysis some time ago.
1. A global calc will update automatically if it references a global field that is located in the same table and that field is edited by the current user.
2. A global calc will update automatically if it references a regular field that is located in the same table (and referenced directly) when that field is edited on any record by the current user. In this instance, the value of the global calc will depend on the value of the referenced field in the record in which that field has most recently been edited. When the global calc references multiple regular fields, its value will depend on the values in the instances of those fields located on the particular record where the most recently edited (by the current user) of any of those fields resides.
3. A global calc will NOT update if it references a global field that is located in another table, if that field is edited by the current user.
4. A global calc will NOT update if it references a global field (in the same table and referenced directly, or in another table) that is edited by different user (users see their own separate global values...).
5. A global calc will NOT update automatically if it references a regular field that is located in the same table (and referenced directly) when that field is edited on any record by another user.
6. A global calc will NOT update automatically if it references a regular field that is located in a related table (even if a self-relation) if that field is edited on any record by the current user or by another user.
7. If a global calc references one or more related fields (as per 3 and 6 above) and ALSO directly references a local field, either global or regular, the value of the global calc will depend on the related values which are current (for the current user) at the time when the local (to the table in which the global calc resides) value/s are edited.
8. The value of a global calc when a solution is opened remotely will be the value that it had on the host when last closed (sound familiar?!).
9. The values of global calcs in a hosted solution can be 'tickled' at login by changing a local field which they reference. Eg if there are several dozen global calcs with formulae constructed along the lines of:
If(not IsEmpty(GlobalsTable::RegularTriggerField); RelatedTable::dataField)
then they will all update to reflect the current (related) values at start-up if the start-up script includes the command:
Set Field [GlobalsTable::RegularTriggerField; "1"]
10. Changes made to referenced regular fields on another workstation will not appear in global calc results until a refresh event (eg as per 9 above) has occurred on the current workstation - eg the next time the start-up script runs. If there is no triggering mechanism (as per point 9) then the changes will not appear at all until the solution is taken offline, updated in a client session, closed and reopened on the server, as is the case with non-calc globals.As usual, you can take information like this from Dr. Ray to the bank.
Not dealing with a Global calculation. Just a field. Some of the info still applies though I guess.
I would think that anybody who has been around FileMaker development at all knows that your original method guarantees failure.
PUT THE DATA in standard stored, not-global fields.
Then use a startup script other methods to put the data into global fields.
At session start, a global field will have the value it held when it was last opened in a local, single user session. This said, it will not store any changes made during a multi-user session (on server) beyond the end of the session. BruceRobertson hinted to the right method: store values in normal per-record fields in order to assure data persistency.
Bruce, Thanks. I set this up in a stored field and script the transfer to the global field now. This is the only table I had ever setup this way and will avoid this in the future. None of the credentials have changed for years so it kinda went unnoticed.