Kbase P80815: Error 396 is not generated where seemingly expected.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
17/05/2004 |
|
Status: Unverified
SYMPTOM(s):
Error 396 is not generated where seemingly expected.
** <filename> record has NO-LOCK status, update to field not allowed. (396)
Executing the code:
define buffer c for customer.
find first customer no-lock.
find first c where recid( c ) = recid( customer ) exclusive-lock.
customer.name = "test name".
No error messages are generated. Developer expects error 396 to be generated because the first find was done no-lock!
CAUSE:
When the second FIND statement executes, the NO-LOCK state of customer is upgraded to EXCLUSIVE-LOCK.
FIX:
This is expected behavior. The section entitled ?Locks and Multiple Buffers ? in the ?Progress Programming Handbook? states:
?...Progress also uses default behaviors to prevent the condition known as bleeding record locks when multiple buffers use the same record. A bleeding record lock occurs when a buffer with NO-LOCK inherits a SHARE-LOCK from another buffer during a record disconnect.
For example, examine this code:
p-lock12.p
DEFINE BUFFER acust FOR customer.
DEFINE BUFFER bcust FOR customer.
FIND acust WHERE acust.cust-num = 1 NO-LOCK.
FIND bcust WHERE bcust.cust-num = 1 SHARE-LOCK.
RELEASE bcust.
In this code example, two customer buffers contain copies of the same record. One has it with a NO-LOCK and the other has it with a SHARE-LOCK. When the second FIND statement executes, the NO-LOCK state of acust is upgraded to SHARE-LOCK..."