WebDirect Script Triggers That Don’t Trigger

Many solutions use Script Triggers like On Record Commit or On Object Exit to ensure that records are updated correctly.  This works great on FileMaker Pro. But if you are deploying with Web Direct, and relying on Script Triggers  to enforce business logic and database integrity, I suggest you stop, right now. It simply doesn’t work.

“But wait!”, you say. “I tested them. They work just fine”.  Sorry, there are couple of very common things that users do in web browser that will completely stop your Script Triggers from firing.

If the user refreshes the web page or closes the browser window none of the script triggers will fire. Thats right, none of them.  All scripts abort. No triggers are fired. What’s worse is that unless your layouts are set to not “Save Records Automatically” open records are committed, even if you tried to block record commit with the On Record Commit Trigger.

There is no way to stop the user from refreshing the browser window or just closing it. So what can you do? You need to use transactions.  Of course you new I was going to say that. 🙂

You need to kick of any important logic scripts with a Button, not a Script Trigger.  The logic script needs to go to a Layout that has “Save Records Automatically” un-checked.  And do all its processing there using transaction safe Techniques.  Basically do all your edits through relationships and commit everything in one go.

If you do it that way and a user happens to refresh the browser in the middle of your script, it will be as though nothing happened.  Any data changes that the script was making would be rolled back, unless of course the script gets all the way to the end and does the commit.  And that is exactly what you want!

3 responses to “WebDirect Script Triggers That Don’t Trigger”

  1. Fernando Yanes says:

    Hi Todd!, Thank’s for responding and sharing this article, Sorry if I’m making the wrong questions as I’m new to transactions and still trying to figure out the method, For what I have read here Transactions don’t depend on script triggers, but then how do you control the FM message? “Save changes to this Record?”. Again many thanks.

  2. alec gregory says:

    Hi Todd

    It looks like FileMaker 16 has reversed this behavior. See the “Closing Session with Unsaved Changes in WebDirect” and “Session Timeout Dialog Changes” rows in the FileMaker WebDirect table in the FM16 miscellaneous behavior changes document: http://help.filemaker.com/app/answers/detail/a_id/16316/~/miscellaneous-behavior-changes-in-filemaker-16-platform

    Obviously it’s still a good idea to be transactional in WebDirect (and everywhere) but at least it should now be possible to build a relatively robust system without needing a Save button on data-entry layouts.

    Cheers,

    Alec

Leave a Reply