KI_LOCK_OWNER
| Argument | Enumeration | Purpose |
|---|---|---|
| handle | Handle of locked file | |
| SYM(info$) | Symbol of an info structure | |
| status | KDB_ERROR_ENUM | Return status |
| nId | Identifier for the locking process |
KI_LOCK_OWNER
This function will return an identifier for the KCML process which prevented a previous call on the handle acquiring a lock on a row in the table. It should be issued immediately after the call which failed with a status set to KE_LOCKED. If there was no lock then it will return zero (but see below for compatibility issues).
It can also be used to discover the process that has a KDB table opened in W mode that is blocking your attempt to open in X mode. In this case call with a negative handle number just after the failed KI_OPEN call. This usage can only be relied upon for KDB6 tables if less than 1280 partitions are in use.
The identifier for a KDB database is the partition number. This can be used with the $PSTAT() function to get details of the process including the logged in user.
This function is not useful for KDB databases on Windows servers as Windows does not track locks by process and does not make lock status available to applications. Consequently calling this function in Windows will always return a value for an unlocked row, 0 or #PART, whatever the lock status. This implies the lock status cannot be determined and it specifically does not mean that the row is locked by this process, though that is a valid possibility under Windows.
For an Oracle database the identifier returned is the connection ID for the process. This can be used in a call to KI_SESSIONS to lookup the process details.
Compatibility
From KCML5 the function now returns an optional status as it is possible that the handle number may be invalid.
If the partition cannot be determined, KCML5 and later versions (up to KCML 6.90) return #PART rather than zero as KCML4 would have done. This is in the interests of compability with widely used application code which foolishly assumes a non-zero result in all cases. Under Unix a value of #PART could not legitimately occur as the lock owner can always relock a row.
As of KCML 6.90 the function will return zero as the value on all platforms if there is no lock.