2 Replies Latest reply on Feb 21, 2013 6:50 AM by BowdenData

    Server Side Script Best Practices


      Is there a doc or thread out there that covers best practices for server side scripting?


      I've created a user and a script to run to import data via an ODBC connection. I mainly want to avoid the onOpen and onClose scripts. I added a step that if the user is the one I created to run the import it skips the rest which works, but I'm just wondering if there are best practices out there to make thing efficient.


      Maybe a future FM Academy webinar!

        • 1. Re: Server Side Script Best Practices

          I've written a blog post on this topic awhile back: http://www.zerobluetech.com/filemaker-server-side-scripting/ 


          Hope you find it useful. 


          Best regards,


          agnes b. riley

          filemaker and web development




          FileMaker Certified in 10 and 11

          Member, FileMaker Business Alliance

          T: 877 917-9079 . C: 917-660-7221

          1 of 1 people found this helpful
          • 2. Re: Server Side Script Best Practices



            You have the basics correct. You should read the FM server help docs/pdf. There is a section in there that discusses how the script steps of Allow User Abort and Set Error Capture work when running on the FM server. There are some subtle differences that are important to know. It also discusses about the onOpen and onClose scripts, windowing, restrictions on what folders on disk that servers scripts have access to and so on.


            • Create a special user account for running server based scripts. Assign it to a privilege set that is appropriate for what it needs to do. Typically, this is not full access. I find that the built-in [Data Entry Only] priv set is a good fit in a lot of cases.
            • I strongly suggest that you create separate scripts where at all possible. One that runs on the FM server and then if needed, an equivilent one to be run by a user. Avoids a lot of If User, do this, if server, do that.
            • You do need to put in trapping in your onOpen and onClose scripts as you have found out. In many cases, you can just say "if server then exit script" or maybe "if server, set some specific values/variables, then exit script".
            • Remember that you can't interactively see what is going on when the script runs on the server, so it is often helpful to have your script write values to a log table when debugging (or even afterwards).


            In one system I have, I too am importing data via ODBC from a SQL Server solution. It has a lot of steps, so I write various values with a timestamp to a log table each time it runs. Things like "224 Invoices Imported", "512 Invoice Line Items imported", and so on. Makes it much easier to spot problems.





            1 of 1 people found this helpful