Kbase 13974: Why an EXCLUSIVE-LOCK does not always start a TRANSACTION
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
Why an EXCLUSIVE-LOCK does not always start a TRANSACTION
In the following three examples, the first will show that no
transaction is active, whereas the second two examples will show an
active transaction. Why?
Example 1:
FIND FIRST customer NO-LOCK.
FOR EACH customer EXCLUSIVE-LOCK:
MESSAGE TRANSACTION.
END.
Example 2:
FOR EACH customer EXCLUSIVE-LOCK:
MESSAGE TRANSACTION.
END.
Example 3:
FIND FIRST customer NO-LOCK.
FOR EACH customer EXCLUSIVE-LOCK:
MESSAGE TRANSACTION.
UPDATE customer.
END.
Example 3:
FIND FIRST customer NO-LOCK.
FOR EACH customer EXCLUSIVE-LOCK:
MESSAGE TRANSACTION.
UPDATE customer.
END.
The answer is:
If you want a FOR EACH to be a transaction, the rule is to put the
TRANSACTION keyword there. If there is no transaction keyword, but
the FOR EACH block contains a FIND... EXCLUSIVE-LOCK on a buffer other
than one in the FOR EACH itself, or an UPDATE/CREATE/DELETE on a
database file (not a workfile, worktable or temptable) then it
defaults to TRANSACTION. If there is an EXCLUSIVE-LOCK on one of the
buffers in the FOR EACH statement, and that buffer is scoped to the
FOR EACH block, then it will also default to TRANSACTION. In the
first example, the CUSTOMER buffer is not scoped to the FOR EACH block
and the keyword TRANSACTION was not used on the FOR EACH statement,
and there were no UPDATE/DELETE/CREATE statements within the block, so
so it does not default to TRANSACTION. The second example has
EXCLUSIVE-LOCK on a buffer that is scoped to the FOR EACH block, so it
does default to TRANSACTION, and the third example has an UPDATE
statement, so it also defaults to TRANSACTION.
Progress Software Technical Support Note # 13974