Progress V11 is writing a second message as an addition to the error # 435:
(435) SYSTEM ERROR: lkrels record 14338435633 not locked.
(-----) lkrelsy ERROR: (91, 0, 14338435633) not locked
What is the meaning of the fields in this message?
Is it 1) table number, 2) lock flag (always zero), 3) recid ?
Knowledgebase: "The error is indicating that the code attempted to release a lock that was already released at transaction commit. The error can be considered harmless". Should we try to find out the source of these errors or should we just ignore them? There are the thousands errors written to db log per a day. I guess we can suppress the message # 435 using the -omitLgMsgs parameter but not the second one.
Thanks, Richard!
this error is generated internally by the database lock manager because something has requested a lock release but there is no such entry in the lock table.
probably cause is a code path that releases the lock twice. possibly in the client code.
regards,
gus
The question remains: is it worth to debug the error? It's rather hard to do in production environment.
Anyway it would be nice to have db startup parameter similar to the -omitLgMsgs for the list of the errors to generate the protrace files. Like Progress does for the messages with "%G" tag but not to terminate a session. It could be called the -protraceMsgs. ;-)
It looks like Progress already (since V10.2B) has the option to debug this kind of the errors:
promon/R&D/4/6. Restricted Options
restricted option key:j8r3ss4cw3
Turning on inservice check
Then in db log we can get the message:
SYSTEM ERROR: Routine lklocky detected invalid inservice %l. Producing stacktrace. (14826)
This message is produced when the database engine detects a specific error condition after tech support has set a restricted promon option for turning on the inservice check.