Well I am back on my soap box preaching about transactions. :-).  This time I was inspired by the Invoice starter solution that comes with FileMaker 11. I was pleased to see that it does not use an un-stored calculation to keep track of the quantity of inventory items on hand. Instead it uses a script to update inventory. This is great for scalability, but in all but the very lightest of use cases the method employed here will simply fail.

The crazy part is that it only takes about 8 extra script steps to make this method far more robust.  I created a short little movie that describes how I added transactional processing to the script to make it much less likely to fail.

But before the movie, a little more background.

The basic problem is that there are a number of very common scenarios that can stop a script step from working as you think it will. Chief among these is multi-user record locking, but there are many other issues that can stop your scripts cold.  To put it simply, if your business logic depends on a FileMaker script editing more than one record in one or more tables, and you don’t use transactional processing, your data is in trouble. It is only a matter of time before your data is all out of wack!

The good news is that this problem can be dealt with by using database transactions. Database transaction ensure that either all your edits occur or none of them do.  There are no in between states allowed. FileMaker has been able to do database transactions since FileMaker 7, and I have been giving devcon presos on the subject ever since :>).

In the movie I show the basics of getting your FileMaker Scripts to support database transactions.   If you have any questions post them to the comments and I will answer them ASAP.  Thanks!

Watch it BIG on an iPad or iPhone