Just a note Error Code 0 means that the script executed successfully, more specifically each script step returns an error code when executed. Error Code 0 is a successfully executed script step. It’s a good thing.
Timothy R Whisenant
Plastic Fusion Fabricators, Inc.
(256) 852-0378 x. 244
Fax: (256) 852-0388
Do you have error trapping in the original import script. I believe without it when the success code (0) is returned your script errors out... I add SetErrorCature (ON) at the beginning of most of my scripts.
I understand that error code 0 means "no error". However, the logging table should only have a record created if an error state existing. Specifically, I had some logic in place such as if ($error ≠ 0), where $error was set by Set Variable ($error ; Value:get(lasterror) ) immediately after the import step.
The import occurred, but the script would log an error and then stop (the expected behavior if a real error existed).
I then removed the entire error logging routine altogether, including the Set Variable step for assigning the error code to the $error variable, yet was still getting records created in my error log table. This is what leads me to believe that a server-side script that is "hung" can cause some unexpected behaviors if the script is modified and then run again.
Yes, I have Set Error Capture [On]. I make a point to do that by default for all of my scripts, as I find very cases where I *don't* want to capture an error code.
I believe that FileMaker will ALWAYS report errors, it's just a matter of how vocal or intrusive it is about them to the user. Looking at the FIleMaker help, the Set Error Capture [On/Off] lists the following options:
On suppresses FileMaker Pro alert messages and some dialog boxes. If the error result is 100 or 803, then certain standard file dialog boxes are suppressed, such as the Open dialog box
Off re-enables the alert messages
As for the server side scripting issues, One of the options you can set is for your script to time out after x minutes. You could try setting that, it might have a different exit/cleanup routine than disconnecting the script connection. I wonder if you also might try clearing your $error variable yourself at the beginning of the script, or check for $error >= 0 instead of $error ≠ 0, just in case there is some residual stuff left over from the last time you ran your script.
Another odd thing to keep in mind with Server-Side scripts:
If I recall correctly, these scripts run essentially as though they were an IWP user (I know that's a bit rough, and you now specify a privilege set, and don't need the IWP privilege bit enabled, etc. etc.). Thus, it is useful to know that Allow User Abort (OFF) will enable the script to run to completion, even if it hits an error. This is regardless of the Set Error Capture() state.
I've forgotten when/where I learned this, but basically if an IWP/Server-Side client is running a script that encounters an error code for any step (other than 0), the script is supposed to be aborted, regardless of Set Error Capture() state. Only the Allow User Abort() state can permit the script to continue.
You should see an error in the FMServer log every time your script hits an error code (other than 0), regardless of the user, and I frequently see IWP/Server-Side users getting 401 errors, which I've accounted for in the scripting. (I have some nightly cleanup routines that may not have anything to do.) I always have Allow User Abort (OFF) as well as the Set Error Capture (ON) in these scripts.
Of course, this is pretty stale knowledge, and might no longer be true. But if this is true, then it is quite puzzling indeed that you seem to see your Server-Side script was 'hung', and unable to integrate the changes you made via another client machine. Can you think of any other reason why the script was 'still running' even after encountering the error in the import?
-- Drew Tenenholz
Does your source file reside in a location to which FM Server has full access permissions? If not, the import will fail but error capture will keep it from reporting an error. Most of a Server computer does not have FM Server permissions by default.
Often a client computer can read and use data from serer directories which FM Server process itself cannot read.
Also check your script steps for Server Compatability in the Edit Script controls:
Yes, the files reside in a location that the FM Server has full access permissions. Specifically, in c:/Program Files/FileMaker/FIleMaker Server/Data/Documents. And all of the steps are server compatible.
As I've mentioned, it's not a permissions or server compatibility issue. And it actually boils down to more than one issue, I believe. The first is that the script hung. Even though it has a time limit set. The script was still running, at least theoretically, well after the time limit should have aborted it. Then, I could not disconnect the script from the database via any method other than restarting the server. Finally, while the script was hung, changes made to the script did not apparently take affect. I removed the code that created an entry in a logging table, re-ran the script manually, and yet still ended up with a new entry on the logging table. Which seems to indicated that since the script was hung, further attempts to execute it ignored the edited code and just re-ran the verison that was already running. My guess is that a script that is executing is cached, and if called to execute again, FMS just runs the cached code instead of going back to the file.
The script is running fine now, and has been for a couple of weeks.
Yes, once the script is being executed, changes to the script won't affect what's cached for that run. I base this supposition on having seen instances where a user who has executed a script recently doesn't get the new script code on execution until they do something to force that file to recache.
Did you ever identify the actual cause of if hanging?
If there is a loop of any kind, be careful that there is an Exit Loop IF statement inside the loop to cause it to stop under any unusual conditions that might be created by the loop itself. For instance, I had a loop hang the other day that was intended to remove records lacking a value in a certain field, leaving only those with field entries for the printout. (A loop was a lot faster than a realted field find). It hit a group of records where the found count dropped to zero while in the loop, and before executing the Go To Next record (Exit after Last) step in that instance, and the looop lacked any test for a Zero found count, so it hung -- unable to either omit a record or go to the next record.
Let us know if you figure out why it hung up in the first place.