Here is a copy of the script.
Thanks for the help in advance. You folks that help us here are great!
You need to turn on error capture instead of using the check you show for no records found. I am not a Filemaker Tech but I have found that the server flips out on errors and completes a script or fails entirely when errors occur. Any time your calculaiton or step can result in an error check for the error returned.
Since you do use set error capture in the script it should work find from a server schedule, but you will get a 401 error logged when no records are found.
Thanks for the answer PhilModJunk.
Can I assume that this is normal and the 401 error will not keep the script from it's full execution?
The other issue is that the script I've included here is showing a "FileMaker script error" in the Status area when I try to execute the Schedual. Any idea what is causing it to do that?
Thanks for the answer dbail.
I'm sorry but I'm not sure I understand your answer. Ser Error Capture (On) is set in the 4th line.
The documentation does state that the script can halt when it encounters an error. However, I have been told that some cause the script to stop and others are ignored. I haven't seen a list that tells us which is which. I have reason to believe that the 101 and 401 errors will not stop the script.
Have you seen such a list?
Set error capture should allow the script to run even when no records are found. I don't use server 11, I have server 10. It's my understanding that server 11 reports this status message where server 10 did not. I don't know what impact that has on the use of your database and the server admin console.
Can you check the data in your database to see if it ran correctly? You might add a utility table and set this script to create a new record and enter the current timestamp as the final steps of your script. If you check that table and see a new record with the expected date and time, you know the script ran to completion.
PhilMidjunk, thanks for the suggestion. I was out of town for a couple of days so I'm getting back to this,
While I did have something that would tell me whether it did it's job or not, it's better to have it do something else independent at the end of the script. Interestingly, the server ran the script this time without a "Filemaker script error" and the TimeStamp you suggested indicated that the script did rn to completion. I don't see how inserting a Clear and a Set Field would help the script run but!!!. I have a new error line in the log though, 102 which is Clear.
I'll contact FileMaker and ask them what we are supposed to do with these error messages and if they have a list of error messages that don't matter!
I communicated with FileMaker Tech Support regarding these errors and asked for a list of error codes that won't stop script ececution. I received the following response and a list of error codes:
"Any script which contains compatible script steps (from the place you are running the script) will execute. With set error capture on, it should also run however long as it can even if it does produce errors. I have provided all of the documentation that we have made public regarding error codes. We have no list of errors that are not errors. All of our error codes are documented publicly and state exactly what is causing the error.
For example, error 4 will stop the script because it does not know what the command is. The script will stop with error 101, if the record for the script is missing, 102, if the field the script calls for is missing, 401 if the record the script calls does not match the request. All of these errors have reasons for being there, and the reference guide I gave you will tell you that reason."
Not exactly the answer I was looking for. It sounds like the company line though. So, they are a warning?
Thanks for your help.
The script will stop with error 101,
True If the record for the script is missing, AND if it's not tripped by the Go to Record/Request with the "exit after last" option specified. In my personal opinion, this is very much an 'error' that is not an error and no error should be logged. The fact that you see the error warning in the server schedule status when this very common and normal response occurs is not what should happen here as it wastes our time analyzing logs only to discover that our script ran with no problems whatsoever..
401 if the record the script calls does not match the request.
No problem with that one in terms of script execution, but scripts that fail to find records is a common occurrence frequently handled via Set Error capture to keep the script from halting unecessarily. It'd be nice to be able to suppress logging 401 errors in specific cases where the script is designed to handle it.
All of these errors have reasons for being there, and the reference guide I gave you will tell you that reason."
Yeah, except for the Go to Next record 'error' as I've pointed out before...
In my opinion (and I've posted this in feedback and the Feature Suggestion Form ), FileMaker needs to implement better error handling.
All error conditions should be "true" errors. that means the case with Go to next record, exit after last, should NOT return an error code.
All error conditions should immediately halt script execution with a dialog that permits the user to halt the script. Currently some error codes are completely silent, you'll never know they occur unless you test for them with Get (lastError) or note an incorrect result returned by the scriptor an error code in the log or schedule status. Others pop up an error message that disaster is headed your way, but don't allow you to minimize the damage by halting the script! Once you click OK, you have to try to press keys to abort the script (if allow user abort isn't set to prevent it) before further damage is done by the script continuing to execute. These error messages should, at the very least, give the name of the file and script responsible and they do not curently do so.
All error messages and script halts should be suppressed when Set Error Capture is turned on. I know of one case, errors with save as PDF, where this does not happen.
It should be possible to create "error handling" scripts that are performed OnScriptError and enable you to identify the error code that tripped the handler and then provide a developer designed method for gracefully handling the error.