Using Transactions

A transaction is a temporary window state during which record changes are held in a queue and then executed together as a single operation, either all committed or all reverted. By holding a batch of potential changes, a transaction avoids problems of rolling back actions performed earlier if an error occurs later in the process or if some other programmatic change of course is required. It can also increase the speed of certain actions since the work exists in a virtual space until committed. Implicitly, transactions have existed in FileMaker for some time. When a user begins editing a record, an implicit transaction opens and begins collecting field edits. Those changes are held until the record is closed by an action that either commits or reverts the record. This implicit transaction is limited in scope to changes made on a single record with no formal way to apply the concept to wider batches. Over the years, developers concocted methods to overcome this limitation, but they were still limited and difficult to implement. Recently, Claris introduced new functions and script steps that both simplify and broaden the scope of transactions. Now, a script can explicitly open a transaction and perform changes or pause while the user acts. The transaction will persist in an open state until it is either committed or reverted by the script, an error, or interface action. These expand transactions from an implicit record-based scope to an explicit window-based scope that is fully controlled by custom scripts. This chapter covers the following topics: