4 Replies Latest reply on Jan 12, 2015 10:03 PM by philmodjunk

    Working with Global Fields when using sharing

    VassilisM

      Title

      Working with Global Fields when using sharing

      Post

      As i discovered global fields don't retain data when the database is opened via sharing option.

      User of this forum suggested me that there is numerous tricks to address this issue.

      So how can i workaround this problem?

      Also the calculation fields behave strange via sharing but i'm not sure for this one need to test more.

      Thanks

       

        • 1. Re: Working with Global Fields when using sharing
          Mark_M

          >

          Could you add clarity on what you want to do?

           

          Actually Global fields do retain data from the last time the instance was open.  Which can be a little tricky in terms of how you think about them.  For example if I'm working on my laptop and create a global field and populate that field with "Dog".  If I close the database and comeback the next day the field will still contain "Dog".  Of course if I clear the global field using a Script on closing to set it to empty, the next time I open the DB it will be empty.

          It acts a little different when the file is being shared because the last condition of the global field is retained from the last time the DB was shut down.  So let's say my global field is on a server based solution or I'm doing IWP,  If I enter "Dog" into the global field then shutdown the DB and restart it, "Dog" is retained in the field.  50 different people can access the DB through network sharing or IWP and they will all see the global field as "Dog".  If they do an action that changes the global field value to "Cat" it will remain Cat for their session and is only available to their session.  If they log off and then come back in, the global field represents "Dog" again because that value is coming from the server when the instance is started.

          So if the server instance has the global field blank when it is closed and restarted, then all child connections will have that field blank when it opens.  If the server instance has the global field has a value when it is closed and restarted, then all child connections will have that same value in the field.

           

          ***************************************************************

          Now nothing says that you can't start with a blank global, then when the instance is open have an opening script that populates that one field (or multiple globals) and setup certain conditional factors.

           

          Hope that helps.

          >>>>

          • 2. Re: Working with Global Fields when using sharing
            philmodjunk

            Just to Add a bit of Clarity to Mark_M's post. The current value of a global field will only be retained if the change made to that field was made on the host computer, from a perform script on server script or from a server scheduled script. If you change the value of the field while linked as a client of the hosted database and then the database is closed, the change is not retained.

            There are several different issues you might encounter here:

            You may want to be able to change the value of the field while editing the data as a client. Here's how: Set up a table with a non global field corresponding to each global field. When you want to edit the value of the global field and make that change "stick", edit the local field. Then set up an "OnFirstWindowOpen" script that copies the current value of the local field to its corresponding global field. It's a common practice to have such a script load a whole suite of global "preference setting" type fields. These values can even be different for every user if you set up a table for storing the values by user.

            Such changes do not automatically become visible to other users who have the DB open at the same time. They'll see the new value the next time that they open this file.

            If you need the value changes to be instantly visible to all users, don't use a global field. Put the field in a related table of just one record. Link that multiple occurrences of that table to every other table occurrence that is a layout context where you need access to this field using the Cartesian join operator (X) instead of the default = operator. (Double click the relationship line to open a dialog where you can specify the operator.)

            If you are using FileMaker 13, another way to make a permanent change to the value of a global field is to use Perform Script On Server to perform a script where the value to be set to that global field is passed as a script parameter to that script. Like the "onFirstWindowOpen" method, this change will only appear for other users when they next open the file.

            • 3. Re: Working with Global Fields when using sharing
              VassilisM

              Thank you for replaying. My initial idea was to share one database file across many users and every user to have its own configuration settings. So i thought global fields are a good option. Using global field is neat because you can address  this field in any table without caring about table relationships. Yes we are using FileMaker 13 will see which option is best for us.

              • 4. Re: Working with Global Fields when using sharing
                philmodjunk

                To repeat from my last post:

                Set up a table with a non global field corresponding to each global field. When you want to edit the value of the global field and make that change "stick", edit the local field. Then set up an "OnFirstWindowOpen" script that copies the current value of the local field to its corresponding global field. It's a common practice to have such a script load a whole suite of global "preference setting" type fields. These values can even be different for every user if you set up a table for storing the values by user.

                essentially, you save these values to a table where you have one record for every user (You can use account names to identify each user) and a start up script that loads all the global fields from their user record when the user first opens the file.