Informix Error -233

Reasons / Common Causes

-233 is the SQL-layer wrapper around the entire lock-conflict family already covered extensively elsewhere in this catalogue. The official text explicitly names six accompanying ISAM error codes — -107, -113, -134, -143, -144, and -154 — each representing a distinct flavor of lock conflict, and says a program might need a different response to each.

1. An ordinary row lock held by another session — the direct, most common cause, reported alongside -107.
2. A table-level exclusivity conflict — accompanying -113.
3. Lock-table exhaustion — accompanying -134.
4. A genuine or suspected deadlock — accompanying -143 (deterministic) or -154 (timeout-based/ distributed).
5. A key-value-locked delete/insert race — accompanying -144.

Each of these has its own detailed causes and fixes already covered under its own code — -233 is simply the SQL-level signal that one of them occurred while trying to read a row.

Solutions / Resolution

For interactive use:

1. Wait a short time and reenter the statement, or
2. Execute SET LOCK MODE TO WAIT, after which this message becomes rare — the session waits for the lock instead of failing immediately.

For programmatic use:

3. Roll back the current transaction, wait a random interval, and rerun the transaction. Use a genuinely randomized delay, not a fixed one — multiple competing transactions all retrying after the same fixed delay tend to collide again in lockstep.
4. Use LOCK MODE WAIT to reduce frequency, understanding it can still arise in some cases (deadlock detection in particular doesn't go away just because the session is willing to wait).
5. Check the accompanying ISAM error code and respond accordingly — per the official guidance, a program might need a different response to each of the six named codes. An ordinary -107 conflict is purely transient and warrants a simple retry; a -143/-154 deadlock recurring on the same tables is a design signal worth reviewing resource-acquisition ordering for, not just retrying indefinitely.

Examples

Randomized retry-with-backoff

int attempts = 0;
while (iserrno == -233 && attempts < MAX_RETRIES) {
    rollback_transaction();
    sleep(random_delay_ms(100, 500));  /* randomized, not fixed */
    attempts++;
    retry_transaction();
}

Reducing frequency with LOCK MODE WAIT

SET LOCK MODE TO WAIT 5;
SELECT * FROM inventory WHERE sku = 'WIDGET-1';
-- waits up to 5 seconds for the lock instead of failing immediately

Responding differently based on the accompanying code

switch (iserrno) {
    case -107: case -113: case -134:
        /* ordinary transient conflict — retry with backoff */
        retry_with_backoff();
        break;
    case -143: case -154:
        /* deadlock — retry, but also log for pattern review */
        log_deadlock_occurrence();
        retry_with_backoff();
        break;
    case -144:
        /* key-value-locked race — retry; outcome depends on whether
           the other transaction committed or rolled back */
        retry_with_backoff();
        break;
}

Diagnostic Checks

1. Identify the specific accompanying ISAM error code to determine the exact cause and appropriate response.
2. Review whether the failure is occasional (a simple retry is sufficient) or a recurring pattern requiring a design change — consistent resource-acquisition ordering for recurring deadlocks, shorter transactions for ordinary lock contention.

Related Errors / Related Topics

• -107 — "ISAM error: record is locked." The most common accompanying code — an ordinary, transient row-level conflict.
• -143 — "ISAM error: deadlock detected." The accompanying code that most warrants a design review if it recurs, rather than just retrying indefinitely.

Check the accompanying ISAM error code before deciding on a response — -233 alone just says "a lock conflict happened," not which kind, and the right response genuinely differs between them.