Informix Error -288

Reasons / Common Causes

-288 means an UNLOCK TABLE statement named a table the current session hasn't locked — worth knowing the specific ways that happens, since tables unlock automatically under conditions that are easy to forget about.

1. The table was already unlocked automatically. Tables unlock automatically when a transaction ends (commit or rollback) or when the database is closed — a later explicit UNLOCK TABLE call finds nothing left to unlock.
2. Another user or session locked the table, not the current one. You can't unlock a table someone else locked — only the locking session (or an automatic unlock) can release it.
3. A redundant UNLOCK TABLE call in program logic that doesn't track whether the lock was already released automatically by an earlier COMMIT/ROLLBACK.

Solutions / Resolution

1. Review program logic for redundant UNLOCK TABLE calls — since tables unlock automatically at transaction end or database close, an explicit unlock afterward is unnecessary and will fail with this error.
2. Confirm which session actually holds the lock if attempting to unlock a table locked by someone else — this isn't something the current session can do; only the locking session (or automatic unlock) releases it.
3. Remove unnecessary UNLOCK TABLE calls from code paths that already rely on automatic unlocking at commit/rollback.

Examples

A redundant unlock after automatic release

LOCK TABLE orders IN EXCLUSIVE MODE;
-- ... perform maintenance ...
COMMIT WORK;   -- automatically unlocks orders

UNLOCK TABLE orders;
-- -288: orders was already unlocked by the COMMIT above

Fix — remove the redundant call:

LOCK TABLE orders IN EXCLUSIVE MODE;
-- ... perform maintenance ...
COMMIT WORK;   -- unlocks automatically; no further action needed

Attempting to unlock another session's lock

-- Session A holds the lock
LOCK TABLE orders IN EXCLUSIVE MODE;

-- Session B, unrelated:
UNLOCK TABLE orders;
-- -288: session B never held this lock and can't release it

Diagnostic Checks

1. Review recent transaction history to see if the lock was already auto-released by a commit or rollback.
2. Check current lock holders directly:

   onstat -k
   

Related Errors / Related Topics

• -113 — "ISAM error: the file is locked." The table-level lock-conflict sibling — worth reviewing together for the broader table-locking picture.
• -107 — "ISAM error: record is locked." The row-level sibling in the same general locking family.

Remember that tables unlock automatically at transaction end or database close — a redundant explicit UNLOCK TABLE afterward is the most common cause of this error.