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:
Thank you TSFalcon for the clarity. I really appreciate it!
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.
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.
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".
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.
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...