When you use the perform script on server, the server still runs whatever "OnFirstWindowOpen" script you have set to run. Is it possible that this start up script is in turn calling a script on the server and effecting a sort of loop?
Good point Chad, but I have an escape at the beginning of the startup script that kicks it out if Get ( applicationversion ) has "Server" in it.
I know that in FMS 13v1 I was having issues with any sort of error on the server ran script causing incorrect results (even an expected error like 101 after a Go to Next Record as part of a loop). I haven't seen this since upgrading to FMS 13v2.
If you are already upgraded then I'm out of suggestions :-) I found this thread which might be helpful: http://forums.filemaker.com/posts/e0d2ac5adc
The FMS version already is the 13v2 (e.g., 22.214.171.1245). I read your link that basically suggested the Plastic server plugin was the problem, and thanks for sending it, it reminded me to check the plugins. I've seen a number of times when a server acts strange with a poorly behaving plugin. But this setup has no plugins on the server, so that is not the problem. I'm pretty much resigned to a FMS reinstall tonight. We've scheduled taking it down at 6pm and hopefully all will be better after the reinstall. Always hoping such behavior is not the precursor to a hard drive crash. But we have lots of backups!
Well, tonight I did a complete reinstall of FMS 13.02.295 and the same script killed the fmse. It does it at the point of a "Perform on Server" script step and passes a parameter "SQL". The sub script performs two SQL calls and then exits with the results in the Exit Script step. I can substitute a "Perform Script" for the "Perform on Server" and it works just fine. I even did a recover of the file just to check it. I agree with Chad that this could indicate the startup script is doing something on the Server, but I confirmed that the Get ( ApplicationVersion ) exits if it has the pattern count for "Server" = 1. Its the same exit script routine I use for most all of my databases. Hmmmmmm. I guess I could reinstall the OS, but that would be a real pain and I have no reason to think the OS is the problem. But before doing that I'll try changing the ExecuteSQL calls even though they work fine as long as they are not in a Perform on Server script step.
This may seem a little weird, but I've "tested" how a script will actually function when "performed on the server" by doing the following:
- Create a new empty file
- Create a script that calls the script that you want to test in your main file (just using perform script, not perform script on server)
- Make sure your main file is closed
- Make sure the Get ( ApplicationVersion ) checks in your startup script are setting that value to a variable and then checking the variable
- this lets you change the variable while stepping through it in debugger
- Run the script from the new empty file and step through it in debugger
- Make changes to variables as needed to "pretend" to be the server