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!