Oninit
Talk to an expert →

Informix Error -291

-291 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.

  1. The current session already holds the table locked in one mode, and attempts to LOCK TABLE the same table in a different mode without unlocking first.
  2. Application logic attempting to "upgrade" or "downgrade" a lock mode directly via a second LOCK TABLE call, not realizing this requires an explicit unlock first.
Solutions / Resolution
  1. UNLOCK TABLE first, then LOCK TABLE again 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
  1. Review the sequence of LOCK TABLE calls for the same table without an intervening UNLOCK TABLE between 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.