7 Replies Latest reply on May 7, 2015 8:45 AM by philmodjunk

    PSOS and globals

    gethappy@happypc.com

      Title

      PSOS and globals

      Your post

      I am wondering how globals are treated when running a Perform Script On Server.  I know the user that 'starts' the script is the logged in user / account when running the script, so the security permissions are used but are globals independent for each PSOS 'session' or do they carry forward for multiple PSOS scripts?

      An example might be better to illustrate my questions ...

      1) a user runs a script that runs on server 'PSOS' that is set to NOT wait for completion, and in that script some globals are set, then various functions are run

      2) the same user immediately runs a different script PSOS that is again not set to wait for completion and this script works with the same global fields.

       

      When the second script is run, will the global fields still have the values from the first script OR will the second PSOS start with a blank slate where the globals need to be set fresh?

        • 1. Re: PSOS and globals

          Mauro:

           

          Thank you for the post.

           

          “When the second script is run, will the global fields still have the values from the first script OR will the second PSOS start with a blank slate where the globals need to be set fresh?”

           

          The second script will be its own user session with its own global values and unless those values are set by the second script, then the values will be null (empty).

           

          Additionally, here are some useful knowledge base articles:

           

          Global Fields: An Overview

           

          Working with Global Fields

           

          TSFalcon

          FileMaker, Inc.

          • 2. Re: PSOS and globals
            gethappy@happypc.com

            Thank you TSFalcon for the clarity.  I really appreciate it!

            • 3. Re: PSOS and globals
              philmodjunk

              A key different which hopefully is covered in those knowledgebase articles is that if a PSOS alters the value of a global field, the change in value persists. The next user to open the file will find that the value of the global field is now what the PSOS set it to be. This can be a useful way to manage global field values that are expected to have specific values in them when a user first opens the database.

              • 4. Re: PSOS and globals
                DavidJondreau

                Phil,

                I hate to break it to you, but that's not true. A server-side script (PSOS or scheduled or CWP, whatever) setting global field doesn't change the "on open" default value.

                • 5. Re: PSOS and globals
                  philmodjunk

                  But it does. I've used this method a number of times to reset global values when I uploaded them and forgot to reset values changed during development/testing. Instead of kicking everyone out, pulling the file down off the server, modifying the values and putting the file back, I just created a script to set the values and used a server scheduled script to change the data. This works because the script runs in the context of a host environment rather than a client side session. The same should be true for PSOS as this also runs from a "host context".

                  • 6. Re: PSOS and globals
                    DavidJondreau

                    Perhaps it worked in previous versions, but it doesn't work in FMP 13 on FMS 13.

                    I'd be happy to post a test file if you'd like.

                    There is a way of setting a default global field without pulling it down from the server, but it involves changing the field to a calculation, then changing it back again.

                    • 7. Re: PSOS and globals
                      philmodjunk

                      Thanks David,

                      I am able to run my own tests and was surprised to find that you are correct. PSOS is new to 13 so I can't complain about it, but was distressed to discover that a scheduled script with server 13 also cannot make a lasting change to a global as was an SOP for me in an older version. I used to keep a disabled "fix globals" script in place on an older system that I used to manage precisely to clear test data from globals should I find that I had accidentally left such data in a global after upload.

                      I hate it when FileMaker changes functionality without telling us that there was a change--unless I missed a release note somewheres. This is particularly irritating given that the alternative you mention still requires locking users out of the file--or at least that one table while the field's value is updated to the desired default value so this removes a valued tool from my "tool box".

                      And I've discussed this feature and suggested this as a useful way to use PSOS both here in the forum and in conversations with Filemaker engineers. You are the first to point out that my understanding was incorrect...