This Article does not apply to OpenEdge 11.4 and later.
The behavior of the _Lock VST changed starting with OpenEdge 11.4: Performance of the _Lock VST now directly scales with total size of lock table instead of active locks, and will show much better performance in most cases. Refer to Article 000056304, Entries in _Lock no longer appear at top of resultset from OpenEdge 11.4 onward for further details.Prior to OpenEge 11.4:
- When a record with an unknown value for a lock status field such as _Lock-Usr or _Lock-Recid is reached, exit the query. Records with unknown values in these fields are unused records; they do not represent current locks.
- Queries on _Lock can be sped up by aborting the loop if a field other than _lock-id becomes unknown. This will ensure that data is read only for the locks that are actually in use, not for unused records.
- Specifying the check for unknown values in the WHERE clause is less effective due to how the query mechanisms work in this particular instance. The difference will be smaller if large numbers of records are being locked.
- As of this writing there are no plans to index the _Lock table.
FOR EACH _Lock NO-LOCK:
IF _Lock._Lock-Usr = ? THEN LEAVE.
/* other code here */
Sample _Lock Table code:
In some cases, the _Userlock VST will suffice. It shows the first 512 locks associated with a particular user and is very fast since it does it in one request and stores the entries in an array. Article 000021994, What is the Record locking table _UserLock