Kbase P12226: Why does progress allow a record update after a NO-LOCK read?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
12/04/2010 |
|
Status: Verified
GOAL:
Why does progress allow a record update after a NO-LOCK read?
GOAL:
With the following code "program b" can update the record?
/* program a */
define buffer bcust for customer.
do transaction:
find first bcust EXCLUSIVE-LOCK.
end.
run program b.
/* eof */
/* program b */
find first customer NO-LOCK.
update customer.
/* eof */
But if you run "program b" on its own you get error 396.
GOAL:
** Customer record has NO-LOCK status, update to field not allowed. (396)
GOAL:
** <filename> record has NO-LOCK status, update to field not allowed. (396)
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
CAUSE:
The EXCLUSIVE-LOCK in "program a" is being downgraded to SHARE-LOCK at the end of the transaction. This SHARE-LOCK is being held into "program b", which is then upgraded to EXCLUSIVE-LOCK for the update.
Running "program b" on its own initially reads the record NO-LOCK and then requires an EXCLUSIVE read for the update, resulting in the error 396.
FIX:
To prevent the SHARE-LOCK being held into "program b" add a RELEASE statement in the transaction after the read in "program a".