KI_READ_HOLD
| Argument | Enumeration | Purpose |
|---|---|---|
| handle | Handle | |
| key$ | Key index to row | |
| path | Index path | |
| SYM(rowbuf$) | Symbol of row buffer | |
| eLockType | KCML_KDB_LOCK_ENUM | Optional lock type |
| bQuery | Force use of DEFQUERY | |
| status | KDB_ERROR_ENUM | Return status |
| rowid$ | Row ID |
KI_READ_HOLD
Reads a random row and locks it for later update or deletion.
Reads row with key key$ on path path into buffer whose SYM() index is sym. If the read was successful, then the rowid$ variable will contain the ROWID of the row. If the read failed, then rowid$ will be ALL(00) and the status will be KE_NOTFOUND if no such key is in the index, or KE_LOCKED if present but locked by another process.
In order to be able to later update or delete the row with KI_REWRITE or KI_DELETE, it must be held and locked by setting the optional eLockType argument to one of the enumerated constants. The lock can be either a short term transactional lock or a long term lock. As many rows as are required may be held at any time.
It is an error to take a long term lock inside a transaction except in the special case of a redundant lock on a row that was previously locked by the process outside the transaction.
Compatibility note:
On early versions of the KCML database the row was locked by setting the lock byte to binary #PART. From KCML 3.20 onwards the locking is done by locking the range of bytes that the row data occupies. From KCML 6.60, KDB distinguishes long term locks from transactional locks on some databases by using the eLockType enumeration.