For any system with multiple users, transactional scripting is a must to ensure data integrity. One of the most exciting features of Claris FileMaker 19.6 is the addition of transaction script steps. These transaction script steps are easily one of the most important development features since cURL was introduced. This will allow developers who have already been writing transactional code to write it much faster. Transactional scripting helps ensure that your application is cleaner, more accurate, and free from technical debt. 

What are Transactions?

Transactional scripting in FileMaker means that you do not save any changes until all database record modifications have been completed for a given process. For example, let's say you wanted to submit an order in a system and have an invoice automatically created. Part of the process may include other tasks like updating inventory counts, sending emails, updating values in the order line item table, etc. 

Transactional scripting means that if everything goes through without error, you can commit the changes and move on. However, if any one thing fails or has an error, the entire process will be rolled back as if nothing ever happened. Previously, this required time-consuming development to create many relationships with huge scripts and specific developer layouts to allow for things like record deleting.

New & Improved Transactions

Let's introduce the new transaction script steps released in Claris FileMaker 19.6:

• Open Transaction: Starts the transaction process. All record changes are held in the transaction until a commit or revert transaction occurs. Script steps following the open transaction script will be indented in, similar to the Loop script step. This step has two options that are similar to the commit Records/Requests script step where you can state that when the transaction ends and commits, you have the option to skip data entry validation and/or override ESS locking conflicts.

• Revert Transaction: Ends the transaction process and returns all records that were modified to their original state. You must specify the condition that must be true in order for the revert to take place. Similar to an Exit Loop If script step setting the next step as the end loop, it will then set the next script step to the commit transaction step. You may also pass a custom error code (between 5000 and 5499) and a custom error message.

• Commit Transaction: This ends the transaction and commits any changes made, using the settings set in the open transaction script step. This also removes the indent created by the open transaction script step, similar to the End Loop step.

Why is Open Transaction awesome?

• Vastly speeds up development time. 

• Simplified and more readable code.

• Learning the right way to write transactional scripts is no longer a college-level course.

• Significantly cuts down on the number of TOs needed for an application. 

• Decreases the need to create global fields just for a relationship to create related records transactionally.

• No longer dependent on objects being on a layout in order to delete a record.

• Spend less time debugging relationships and scripts.

• Reduce application size from reduced layouts, TOs, and scripts.

More Important Information

Above is everything you need to know to get started, but here are a few tips and tricks about the specific behavior of the new functionality:

1. Changes are still only tracked within the TO where the change was made. This means if you make changes to a line item table from a line item layout, you will not see those changes on the parent layout through a relationship until the transaction is committed.

2. Finds will always search on record data prior to an open transaction. If you delete a record, and do a find on that record all within one open transaction, that record can be within the found set of records. 

3. Use Get ( LastError ) and Get ( LastErrorDetail ) to get the custom code and message from the Revert Transaction script step.

4. Some script step errors will automatically revert the transaction and set the next script step to the commit transaction step.

5. Every Open Transaction must have the corresponding Commit Transaction within the same script.

6. You can not have an Open Transaction within another Open Transaction. That includes subscripts. 

7. You can not have a Revert Transaction or a Commit Transaction on their own. That includes subscripts.

8. To optimize performance, make sure you have developer layouts for you to navigate to that do not have any slow-performing objects on them (unstored calculations, summary fields, etc).

9. Enter find mode before navigating to a layout to do a find. This will ensure you do not load any record data unnecessarily.

10. Use Get ( TransactionOpenState ) to programmatically determine if you are currently in a transaction or not.

11. The data layer in FileMaker is still king. If you have a process that needs to go through a lot of records or make a lot of CRUD (create, read, update, delete) events across many records/tables, relationship-based scripting will perform better. 

Conclusion

Transactional scriptwriting should be used to ensure the entire process completes with data integrity and trust in the data of your applications when managing inventory or any data that is updated as part of process completion. Your application needs to be prepared to handle when errors occur and roll back the process when they do occur. With the new transaction script steps, that is now faster and easier than ever to do. If you need help updating your system to use transactional scripting, contact our team at DB Services.