Transactions in FileMaker

The reason for this is in the Pro release notes and it is a HUGE change:


  • You can use the following new script steps to commit or revert all changes in a transaction together. A transaction consists of changes to one or more records in the current window. Transactions support creating new records, editing records, and deleting records.
  • Open Transaction: Starts a transaction; subsequent record changes are held in the transaction until a Commit Transaction or Revert Transaction script step is performed.
  • Commit Transaction: Saves all record changes and ends the current transaction.
  • Revert Transaction: Returns all records changed in the transaction to their original state and ends the current transaction.


  • The new Get(TransactionOpenState) function returns 1 (true) if called within an open transaction; otherwise, it returns 0 (false).

This was one of the missing pieces in FileMaker.

There are a few interesting behaviours in Transactions. I've described a few of the more important features of the transaction commands in an article on my website.


Part of the announcement:

  • FileMaker 19.6.1 supports the latest Apple operating systems: macOS Ventura, iOS 16, and iPadOS 16.

Quite important for those using the latest OS.

1 Like

Trying to click that link gives an error: "Sorry, you're not allowed to preview drafts."

Some useful links regarding transactions:

Unfortunately, it doesn’t look as if Transactions will overcome our need for an OnRecordExit or OnRecordUnload script trigger😩



The URL included all the editing parameters . :roll_eyes:

All fixed.


Record Editing has been transformed

Have you ever pressed the Cancel button in other applications and thought, "I wish I could do that in FileMaker."

Well, you always could do that in FileMaker but it required a lot of effort and very good coding skills. It wasn't simple, it wasn't easy.

That has all changed.

Transactions allow you to undo multiple changes in a record

Using transactions you will be able to cancel all the changes that you have made without having to use complex coding.

This is such a game changer for us all. The magic lies in transactions, and the new script step Revert Transaction. I'm preparing an example file which I'll post shortly. It will demonstrate a few different uses for transactions, including the ability to undo multiple edits in a record.

As promised: (197.0 KB)

This file contains two examples.
1. Create records with ability to cancel
2. Edit records with the ability to cancel


undoing multiple changes in a record (the current) has been possible since fm7 ..Since script triggers introduced in fm10 this could be majorly enhanced.

the new feature undoing multiple changes in multiple records works within a running script only if you want to undo multiple record changes without connection thru portals or related records of current context.

I don't believe this to be correct. Maybe we perceive the edits differently. Truncate table cannot be reverted. Everything else that happens within the transaction block, even subscript edits, can be reverted.

Do you have a sample file that demonstrate what you said?

my emphasis was on running script - yes of course only within one window. you can change the scope of that window but cannot open a new one ..

nineteen6.fmp12 (292 KB)

flabbergasted that get ( RecordOpenCount ) works consistent with everything open within Transaction Block

1 Like

Yes, you could implement similar functionality with the toolkit from earlier versions.
Previously it was difficult. The implementation was complicated. It was easy to get things wrong. It was hard to maintain.

Now it is very easy.

It depends. You still have to stick with the established transactional mechanics if live data entry is key. The new feature is only relevant during run-time of a script. It comes very much in handy in combination with script triggers to implement 2-Phase Commit Protocols or update dependencies to other related data (even without spanning TOG of current context) ..

Am I missing something? Why can’t new records be entered via a transaction? A “new record” button targeting a script that creates new records within a transaction seems easy to implement.

I’m not sure what you mean by “live data” so I need that explained.

[added] I've just uploaded the example file that I promised. It's attached to my earlier post.

In the example I prevent the user from accessing the fields except in Find mode. An "edit" button displays a card window to allow changes.

I love the fact that it is now so easy to manage data changes.

sorry wasn't clear. I am trying to explain that the new transaction script step is implementing transactional behavior only during execution of a script. By live data entry I am referring to interacting with the database where/when no script is running. In other words the transactional model we had before 19.6 and still have works during interacting with the database opening and committing or reverting records. So editing multiple records manually and transactionally is as before.


Absolutely @FileKraft, hence my comment about OnRecordExit script trigger above. There is still no way of enforcing business rules other than either having a web type layout for data entry or editing and a submit button, or using the OnRecordCommit trigger, which is too intrusive for for the user. All we need is the ability to run scripts to check certain data has been entered, based on business rules and corresponding data entered before leaving each record.


The Claris Engineering blog has been update to include an article on transactions. It provides a few good examples of common usage.

Updating records as a unit with transactions in FileMaker scripts