The Support Group Blog

Claris released a new version of FileMaker, and it’s pretty exciting. Of course, the usual list of bug fixes and minor enhancements to the platform accompanied the update. Nonetheless, there's at least one outstanding new feature: Transactions.  

In the database world, a transaction is any operation on an entity. In FileMaker world, it represents any change made to a record. Previously, we made most of our changes to our records, one record and one field at a time. And, when we clicked out of the field in FileMaker, it committed the record, thereby completing an operation for that entity - in other words, performing a transaction. This function helps keep all our data in sync with other users who concurrently access the database. But it can impede the performance of our system, especially in a wide area network (WAN) environment with poor network speed or high latency.  

Transaction Efficiency

A better model would be to group a batch of changes into a single transaction. For example, let's say someone wants to reserve a series of books. Instead of creating a checkout record for each book one at a time, we could record a list of the call numbers for the books and the name of the person reserving them. Then, create a checkout record for all the books for that borrower in a script in one transaction. This approach provides one call back and forth to the server to save all that information at one time. In addition, it improves performance and data integrity in that if something goes wrong during the checkout process, we can revert the whole thing. It's usually more complicated when we've already saved parts of the operation. 

Until now, developers could control transactions only from a single record context. This technique required staying on a single record and creating and modifying records from portals or global relationships. This methodology was practical but has limited us to making edits one record at a time. FileMaker’s new feature set allows developers to change multiple records with one transaction. This change should enhance the performance and scalability of any FileMaker solution significantly.  

Claris accomplished this by adding three new script commands to our toolbox:  

• Open Transaction - opens the transaction and creates a transaction state. 
• Revert Transaction - reverts all changes made during the transaction
• Commit Transaction - closes the transaction and exits the transaction state. 

The idea is that we go into an open transaction state within a script. Then, we make a bunch of changes within the script. When we're done making changes, we commit the transaction by sending the changes from our client to the server in one bundle. However, if we encounter an error or unintended condition while running the script, we can revert the entire transaction, which undoes all the changes we made.  

Transaction Notes

We've discovered a few nuances in our testing and discussion of this new feature.

Revert by Default

If we don’t expressly commit the transaction before the end of the script, it will revert by default. So, we will lose all of our changes unless we commit the transaction. 

Transaction States and Scripts

The transaction state we create during a script will only stay open while the script is running. We can’t exit a script when a transaction state is open. Every time a script ends, the transaction state will commit and exit. 

One of the first use cases we thought of using this new feature was to control user entry of a new record and allow them to exit and revert the new record if they decide to cancel the whole operation. However, this is only possible if we create a way of enabling them to do this while the script is running. If we want to allow users to make changes to a record in a batch, we’ll still have to use the old method to keep them from committing a record until they're ready. So, this new transaction methodology is meant mainly for executing large-scale changes via a script.  

Transactions and Windows

Transactions are tied to the window that hosts them. Transactions that happen in other windows will be committed or reverted separately.  

Exiting the Transaction State

The rules for when we exit a transaction state and how different script steps affect the transaction state are both simple and complex. Generally, we commit the transaction state using the Commit Transaction command or exiting the script. That said, we need to review the rules for when a transaction state is automatically committed or reverted. There are a handful of exceptions that, as developers, we should know. For example, if we change windows by opening a new window, it will commit and end the transaction. 

Like many things, the devil is in the details with transactions in FileMaker. It is a whole new feature set for FileMaker. There are many things to consider, like managing multiple transaction states, running a subscript while in a transaction state, resolving validation errors when attempting to commit, etc. We suspect the developer community will be teasing out the various ways to use this new tool for months to come.

Stay tuned for our next blog post, exploring the opportunities above and outlining a FileMaker Transaction use case and sample script for this new tool.

This article is also published on FileMakerProGurus.com.