The ABL UNDO action ensures pending changes to persistent data (database fields) are not committed to a database after an ERROR or STOP condition occurs. Because ABL is transaction-oriented, a set of pending changes is equivalent to an open (current) transaction or subtransaction. Undoing is essentially throwing away the current transaction or subtransaction.

ABL also extends UNDO protection to non persistent data like variables and temp-table fields. By default, ABL makes variables and temp-table fields undoable. If changes to undoable variable data occur in a block, the AVM undoes changes to these variables and fields, but only if this block is a transaction block.

A block is a transaction block if it contains one of the following statements with a reference to a database field:

  • CREATE
  • DELETE
  • ASSIGN (and the = operator)
  • INSERT
  • SET
  • UPDATE
  • Statements that fetch database records with EXCLUSIVE-LOCK

If the block statement uses the TRANSACTION option, it is also a transaction block. One use case for this option is to force ABL to create a transaction for undoable variables and temp-table fields when the block does not also update database fields. You can use the COMPILE statement listing options to see which blocks in your code are transaction blocks.

Since providing UNDO behavior for variable and temp-table data incurs additional overhead, it's best to define variables and temp-tables fields with the NO-UNDO option when possible. With the NO-UNDO option, the AVM does not allocate the resources needed to track changes, and any UNDO action ignores the NO-UNDO data items.

Actions other than changes to database fields, undoable variables, and temp-table fields are not affected. For example, if you opened a file or a query within the block, undoing the block does not return the file or query to its closed state.

Note: This introduction to UNDO touches on related transaction concepts. Understanding transactions is an important prerequisite to understanding default error handling. Transaction information in this section describes some default transaction behavior and presumes simple use cases. You should have a good understanding of how to define transactions and subtransactions to accurately model your business logic before continuing. For more information, see the section on managing transactions in Develop ABL Applications.