KI_REWRITE
| Argument | Enumeration | Purpose |
|---|---|---|
| handle | Handle | |
| rowid$ | Row ID as returned from a previous operation | |
| SYM(rowbuf$) | Symbol of row buffer | |
| eLockType | KCML_KDB_LOCK_ENUM | Optional lock type |
| status | KDB_ERROR_ENUM | Return status |
KI_REWRITE
This routine rewrites the row buffer in place of the previously held row at pointer position, unlocks it and updates the index if any key has changed. The row must already have been previously locked in a KI_READ_HOLD, KI_READ_HOLD_NEXT or KI_READ_HOLD_PTR operation in order to lock it and discover its rowid via ki_dataptr$. The separate KI_WRITE call is used to create new rows.
Because the rowid from the KI_READ_HOLD must be supplied, it is possible to hold more than one row at any time and rewrite in any order.
If the lock flag eLockType is _KDB_LOCK then the row will be rewritten and left locked. If omitted, or set to _KDB_NOLOCK, then it will be unlocked. In SQL databases transactional locks remain held until the transaction COMMIT or ROLLBACK
If an implicit transaction was started by taking a lock on a row with KI_READ_HOLD the implicit transaction will be committed when that row is updated with KI_REWRITE.
A rewrite of a row with a long term lock will free the long term lock. If done inside a transaction then the unlock will take place when the transaction is committed.
If lock tracking is enabled on the connection then it will be an error to rewrite a row that was not previously held.
If the call fails, then the index is not modified.