5.9 C
Monday, December 4, 2023
HomeClaris FileMaker ProClaris FileMaker Transaction Scripts | DB Services

Claris FileMaker Transaction Scripts | DB Services

For any system with multiple users, transactional scripting is a must to avoid unnecessary bugs. 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.
  • 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:

  • 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.
  • 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. 
  • Use Get ( LastError ) and Get ( LastErrorDetail ) to get the custom code and message from the Revert Transaction script step.
  • Some script step errors will automatically revert the transaction and set the next script step to the commit transaction step.
  • Every Open Transaction must have the corresponding Commit Transaction within the same script.
  • You can not have an Open Transaction within another Open Transaction. That includes subscripts. 
  • You can not have a Revert Transaction or a Commit Transaction on their own. That includes subscripts.
  • 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).
  • Enter find more before navigating to a layout to do a find. This will ensure you do not load any record data unnecessarily.
  • Use Get ( TransactionOpenState ) to programmatically determine if you are currently in a transaction or not.
  • 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 is incredibly important and should be built into any system. Errors happen. All the time. Your application needs to be prepared to handle those errors 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.

    Filemaker Cloud Server
    MC Services

    explore more