GOAL: To reset the default value of a global (text) field in a FM13 file, remotely; while the target file is being served (FMS13).

Given that a global field's default value can not be changed unless it is changed locally and the file is then closed and reopened, locally;

my idea was to see if I could trigger a script from within one of the other files being served on the same FMS13 server i.e., to have that script reset the global (text) field in the target file then cause FMS13 to close + re-open (stop, then restart serving) the target file.

Could this or another strategy get the job done?

I thought perhaps "Run script on Server" might be an answer but don't understand that command's function or how to use it for this task.

I also read some FM posts that mentioned the use of "command lines" but that is outside my knowledge/skill.

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.

My solution

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 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.