9 Replies Latest reply on Mar 2, 2012 9:48 AM by Stephen Huston

    Note About Server-Side FM Scripts


      So I encountered an interesting issue while working on a server-side FM script yesterday. It was a script to import some data from a text file in the Documents directory on the server, and then do a bunch of processing. I'm running FMSA 11, so importing is supported. I had some error-checking code that would add a log entry into a logging table if the import failed for any reason. Anyway, the first attempt at running the script resulted in it apparently hanging. No data was imported. I went to the Server Admin tool, went to disconnect the script connection, and went back to work troubleshooting the script. I made a few changes, ran it, and received an error in the log table. Okay I think, do a little more work, run the script again, and receive the same error. Getting curious, I disabled the error logging routine, ran the script again, and received a different error (code 0). All of these attempts, however, did actually import data from the file. It just seemed that the script would exit immediately after importing the data and report an error condition.

      To make a long story short, it turns out that the original run of the script in question did not actually disconnect when I told it to via the server admin. I'm not sure if it was variables retaining values from that first run of the script, error states staying in place, or maybe some sort of script caching issue. I ended up having to shut down the FileMaker Server service in order to get the first script run to disconnect. As soon as I restarted the service and re-ran my modified script, everything worked exactly as planned.

      I thought describing my experience might be helpful to another developer encounting a similar issue.

        • 1. Re: Note About Server-Side FM Scripts

          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

          • 2. Re: Note About Server-Side FM Scripts

            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.

            • 3. Re: Note About Server-Side FM 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.

              • 4. Re: Note About Server-Side FM Scripts

                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.

                • 5. Re: Note About Server-Side FM Scripts

                  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.

                  • 6. Re: Note About Server-Side FM Scripts

                    Dear Byte--


                    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

                    • 7. Re: Note About Server-Side FM Scripts
                      Stephen Huston

                      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:



                      • 8. Re: Note About Server-Side FM Scripts

                        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.

                        • 9. Re: Note About Server-Side FM Scripts
                          Stephen Huston

                          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.