Have you tried debugging the script locally?
Also note that script triggers such as "OnFirstWindowOpen" fire when a server schedule script is run so changed there may be effecting your script results.
As CarlSchwarz proposed you should look at what changed in the system to cause it to stop working.
It is not very likely that the scheduled script went from working to not working with no change to the file(s).
Rule out programming and file configuration error first.
Definitely consider any script triggers and changes to the security model.
Perhaps a good test would be to restore the file from the last backup where the scheduled script worked and manually fire the scheduled script from the server to see if it works?
The server's log file can be a big help in these cases. We've run into problems like this when the login credentials or datasource names get changed. The server will log all the errors, even if the script finishes normally.
CarlSchwarz & coherentkris, Thanks for the replies. The script in question is part of a bought function that pushes records out to Xero, I have gone over it and it looks fine, nothing would have changed there.
As I said above, I created a very basic script to test if it was something in the script or something with the actual FileMaker Server that was having the issue. The script I made simply went to a layout and sets a field.
When scheduled and run in FMS, it runs, gives the OK status and last run at date but when I open the file to check the field, it's not set.
So something with FMS is trying to run the scripts but for what ever reason it can't, but as far as FMS is concerned they run fine.
This is where I don't know what else I can check, I am happy to post the log if you guys can let me know which one you want to see and where to find it.
is the field your trying to set a global field?
If yes then that is why your not seeing the change because global fields, when invoked on the server, are isolated to the server session.
If not then post the script
No, it's just a normal field, no reason for it to be set to Global.
The script is attached, as I said, I don't think it's an issue with the script, it's more so that FMS doesn't seem to be running the script at all, even though it thinks it does. This script works just fine if I open the file and manually run it.
That script will run fine locally so test it locally!
Do you have Filemaker Pro Advanced? If so then run the script in Filemaker Pro Advanced with the script debugger and see what happens.
If you only have Filemaker Pro then still run the script in Filemaker Pro, to see what happens add a number of "Show Custom Dialog" script steps so that you can see where the script gets up to.
Running it locally will tell you if there is a problem with the script. If running it locally works fine then the problem is with a trigger or similar that is being/not being triggered on the server.
As a side note that script has a number of exit scenarios that could be happening!!
e.g. if xero_con_status is not okay.
Some other reason could be stopping your test field from being set also, e.g. not on the right layout/not using the right relationship/not the correct record found.
Thanks for the replay but I think you guys are missing the point a bit, I made a simple, 3 line script to set a field and it doesn't even work.
The issue is not the script, it's with FMS itself and the way it actions the scripts to run. I don't understand this part well enough so I am asking here how that works and what could go wrong to end up with the server thinking the scripts are running but them not actually running.
You posted the script you want to run; but not the startup script for the file.
As mentioned earlier - the script designated by script trigger "on first window open" will run first.
It might be helpful to post that script.
I may have this wrong, but when you run a Server Side script, does that mean any script set to run on file startup will also run?
I thought it was just the specific script you select in the schedule that runs?
The files has a start up script, it's fairly large but I can post it.
Yes (speaking of missing the point) that is the very important point made by Carl Schwarz in reply #1.
You can go ahead and post it; or take a quick look at it and see if it has any server-incompatible script steps.
Another thing you *might* try is just starting it with these statements at the very top of the startup script.
If [ patternCount( get( applicationVersion); "server")]
Yes the startup script, and any other triggers will run. The server schedule is essentially a Filemaker user, it creates a new user on the server and logs into the file with the user details given in the server schedule setup. As you say the perception is often that only the script will get run and it catches people out often. But that is not the case.
If you really want to test the FMS script scheduler then create a new file with one table and one record (not global) and ask the server to set a value in that field. Don't check the FMS scheduler with your current file as there are too many variables, your file is complicated.
Ok, thanks for explaining that. I'll check out the start up script and see if something in there is causing an issue and report back.