8 Replies Latest reply on Jan 25, 2016 12:52 AM by bigtom

    Global Fields won't commit and save changes.

    bigtom

      I have a table that holds credentials for various web services. It is setup as global fields with only one record in the table.

       

      I recently had to change the credentials for one service and the changes are not being saved. They seem to live only as long as the client is open but when the client restarts the old value are in the record. Sometimes they stay, but if another client opens the solution it resets the data back to the old data. How is this possible.

       

      I have tried a scripted commit while on the record. I have deleted the record and made a new one. Still the old data keeps coming back. This is pretty annoying. Any ideas why this is happening? Never had this happen before.

        • 1. Re: Global Fields won't commit and save changes.
          jbrown

          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.

          • 2. Re: Global Fields won't commit and save changes.
            bigtom

            I will give that a try.

            • 3. Re: Global Fields won't commit and save changes.
              krheinlander

              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.

              • 4. Re: Global Fields won't commit and save changes.
                krheinlander

                Also this may be pertinent as well.

                 

                FM7 Global Calculation Field

                • 5. Re: Global Fields won't commit and save changes.
                  bigtom

                  Not dealing with a Global calculation. Just a field. Some of the info still applies though I guess.

                  • 6. Re: Global Fields won't commit and save changes.
                    BruceRobertson

                    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.

                    • 7. Re: Global Fields won't commit and save changes.
                      TorstenBernhard

                      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.

                      • 8. Re: Global Fields won't commit and save changes.
                        bigtom

                        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.