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. Undoing is essentially throwing away the current transaction.
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 undoable variable data occurs in block, the AVM undoes changes to these variables and fields, whether or not the block is a transaction block. Since providing undo behavior for variable and temp-table data incurs additional overhead, define variables and temp-tables fields with the NO-UNDO option when possible. With NO-UNDO in effect, the AVM will not allocate the resources needed to track changes, and any undo action ignores the NO-UNDO data items.
Transactions are scoped to blocks. Default error handling is also scoped to blocks, and the first step in default error handling is to undo. Thus, undoing a transaction might seem to be synonymous with undoing a block. Actually, the only work being undone is changes to database fields, undoable variables, and temp-table fields. Other actions caused by statements and routines are not effected.
A block is a transaction block if the block 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.
Note: This introduction to undo touched on related transaction concepts. Understanding transactions is an important prerequisite to understanding default error handling. Transaction information in this chapter describes some default transaction behavior and always 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 example, is an iteration of a nested block a complete transaction, or is it merely a subtransaction of the transaction defined by the enclosing block? The answer to questions like these will help you understand which error handling options will be most useful for your applications. For more information, see the chapter on transactions in OpenEdge Getting Started: ABL Essentials.
CREATE