To get scripts to run that the server could not do (such as save to pdf) I had to set up a 'robot' file with 'on timer ' scripts to periodically check for conditions in the served file and then run the scripts I wanted to happen. However, this robot file has to be independently run (i.e. not on the server) using a filemaker pro license to properly trigger the client side scripts the server can not do. Trying to do this from a served file may not solve your problem.
If you use a client robot file as your solution consider adding it to startup items so it is always running and the
on timer script steps use the last used time period so I set up a script and a button and field on the robot layout to easily set the time period.
I am using an old FM12 license (which Filemaker kindly helped me reinstall) so it cost me no extra to host the robot file and it does not give a license conflict when i am using FM 13 and FM14 on the network.
In your case of wanting to restart your file you my have a hassle with the timer script as the robot file will keep posting errors saying it cannot find the file when the served file is restarting and your scripts may unintentionally loop and you get the whirling ball of frustration.
In my case the server script creates a new record in my served file with the values I am interested in . The robot script periodically checks if any records exist in the served file. If no records, exit script. If records exist it uses the record values (Client ID and recordID) to call up the appropriate record, print to pdf and email the user. It then deletes the record and loops to next record until all have been dealt with.
In development stage I set the timer script to every 10 minutes. When live I set it to 60 seconds and the user does not really notice any delay from triggering the script though the php web page and the time it ends up in their inbox.
To sort this out took about 1 1/2days trolling through the forums. I hope it is quicker for you.
Do you just need to reset those global fields once, or is it something you would want to do at other times as well?
For a one time change, you could download the file from the server and set the global fields on a local copy before re-uploading to Server, as you have suggested.
Otherwise, it might be better to set the global fields to your desired default values by using a 'startup' script that runs on the clients when they first open the file, i.e. a 'OnFirstWindowOpen' script trigger on the file.
The file would have to be taken off the server open in FM then change the value and then put the file back on the server.
You can use a non global field and a global field, then make changes to the non global field and then use a script / startup script to set the value of global field from the non global field.
The usual method for ensuring globals open up with preset values is to store the required values in a parallel set of standard, non-global fields, and use a script which runs whenever the file opens, to populate the global fields with the matching stored values. This is fairly simple to set up, and much more reliable than trying to trick the default global values.
Like keywords said. If you find yourself having to preset your globals, it's a good indicator that you're down a bad path.
If you think of globals as more like variables than fields, you might find it a better starting point.
If there are values that need to be set in your solution, and those values may change at some point, then that's persistent data, and probably something a user/administrator should be able to adjust without being a developer or server admin.
Oh, I just noticed the original post was way back in June... For some reason it reappeared a the top of the 'Recent discussions list'.....