The reason for this is in the Pro release notes and it is a HUGE change:
Transactions
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.
Functions
The new Get(TransactionOpenState) function returns 1 (true) if called within an open transaction; otherwise, it returns 0 (false).
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.
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?
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.
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.
