Informix Error -291: Cannot change lock mode of table.
Cause and resolution
Cannot change lock mode of table.
The current LOCK TABLE statement cannot be executed because you have already locked the same table using a different mode (EXCLUSIVE or SHARE). To change the lock mode, arrange to unlock the table before you lock it again.
Oninit® Troubleshooting Guidance
Reasons / Common Causes
-291 is a clear, specific restriction: you can't switch a table's lock mode directly from one
LOCK TABLE call to another — the current session already holds a lock on the table in one mode
(SHARE or EXCLUSIVE), and a second LOCK TABLE in a different mode is rejected rather than
upgrading or downgrading it in place.
- The current session already holds the table locked in one mode, and attempts to
LOCK TABLEthe same table in a different mode without unlocking first. - Application logic attempting to "upgrade" or "downgrade" a lock mode directly via a second
LOCK TABLEcall, not realizing this requires an explicit unlock first.
Solutions / Resolution
UNLOCK TABLEfirst, thenLOCK TABLEagain with the new desired mode, per the official guidance — this is the only path to changing lock mode.
Examples
The disallowed direct mode change
LOCK TABLE inventory IN SHARE MODE;
-- ... later, wanting exclusive access instead ...
LOCK TABLE inventory IN EXCLUSIVE MODE;
-- -291: already locked in SHARE mode; can't change directly
Fix — unlock first:
LOCK TABLE inventory IN SHARE MODE;
UNLOCK TABLE inventory;
LOCK TABLE inventory IN EXCLUSIVE MODE;
Diagnostic Checks
- Review the sequence of
LOCK TABLEcalls for the same table without an interveningUNLOCK TABLEbetween different modes.
Related Errors / Related Topics
- -288 — "Table table-name not locked by current user." Related through the same general table-locking lifecycle — this error is about the reverse situation (unlocking something not locked).
- -289 — "Cannot lock table table-name in requested mode." The direct sibling in the same table-locking family, though about contention with another session rather than the current session's own already-held lock.
Unlock the table explicitly before re-locking it in a different mode — there's no direct mode-change operation.