3 Replies Latest reply on Sep 24, 2012 2:25 PM by philmodjunk

    Global fields -- Clarification

    TKnTexas

      Title

      Global fields -- Clarification

      Post

           My understanding of global fields are they are available to every table.  In a multi-user setting though each user gets his/her own copy of them that when changed are changed in their session only.  Is this correct?

           I have used global to hold the tax rates for the application.  Is there a better practice?  I keep these fields under control through controlled access, will this work?
            

        • 1. Re: Global fields -- Clarification
          davidanders

          http://help.filemaker.com/app/answers/detail/a_id/3604/~/global-fields%3A-an-overview
          Global Fields: An Overview   
               Answer ID: 3604
          Last Updated: Dec 03, 2011

               Global field values are global to the user, not to the database. Each guest maintains values in their global fields separate from other guests.

               When a guest opens a file, the global field values are copied from the values for the host into the guest. If the guest's global field values are then changed, such as by running a script, they are changed just for that guest. They are not changed for the host or any other guests.

               This is intended behavior to facilitate using global fields with scripts. The only way to reset the default value for a global field is to reset it from the host computer. Changes are saved only when the file is closed.

               For more information on global fields see Working with global fields..

               To accurately evaluate these calculations on the host, FileMaker Pro transfers all the global field values in the current table from the client to the host. If you know that certain global fields will never be used in unstored calculations or record access calculations, you can improve database performance by creating these global fields in a separate table. This will prevent unneeded global field data from being repeatedly transferred to the host.

          http://dwaynewright.squarespace.com/filemaker-calculations/2007/5/12/filemaker-storage-global-field-storage-options.html

               Some examples of data that could be in a global field

               Field Name: Local Tax Rate
               Data: 8.25%

               Field Name: Company Logo (picture)
               Data: The graphic of your company logo for letterheads and such

                

          • 2. Re: Global fields -- Clarification
            Sorbsbuster

                 My understanding of global fields are they are available to every table. - Yes

                 I n a multi-user setting though each user gets his/her own copy of them that when changed are changed in their session only.  Is this correct? - Yes

                 I have used global to hold the tax rates for the application.  Is there a better practice? - Probably

                 When a user logs out they will lose all their global filed values, so their tax rates will have to be re-populated when they next log in.  Also, if you check the details in David's link you will see that a global field will persist if entered at the host, in certain circumstances.  This may not be what you want, and may behave apparently unreliably (not actually true, but the behaviour just catches you out some time.)

                 For standing data like tax rates we have a section of our Preferences Table that holds such values. All tables link with the cartesian 'X' operator, and the privilege settings are such that no-one can create or delete records, so it only ever has one record.

            • 3. Re: Global fields -- Clarification
              philmodjunk
                   

                        For standing data like tax rates we have a section of our Preferences Table that holds such values. All tables link with the cartesian 'X' operator, and the privilege settings are such that no-one can create or delete records, so it only ever has one record.

                   Another frequently used option is to keep your global field, but use a script performed automatically each time the file opens to copy the value from the preferences table to global fields. This keeps your values universally accessible without cluttering up your relationship graph with a lot of cartesian links to the preferences table.

                   And now that we have ExecuteSQL in FileMaker 12, we could also use that function to access preferences data instead of using a relationship with X to access the data in the privileges table.

                   It's also possible to use a script run from a schedule in FileMaker server to change the value of a global field and have that change persist as the new initial value users will see when they open the file.