Oninit
Talk to an expert →

Informix Error -378

-378 Record currently locked by another user.

A row of a table that this statement needs is not accessible because it has been locked. Check the accompanying ISAM error code for more detailed information. It will probably be -107, -113, -134, -143, -144, or -154. Each notes a slightly different relationship between your program and the other user's program. You can prevent most, but not all, occurrences of this error with SET LOCK MODE TO WAIT.

For database servers prior to Version 4.1, this error message is produced in conjunction with the UPDATE and the DELETE WHERE CURRENT OF statements only. In Version 6.0, this error message is no longer used.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-378 is a straightforward lock-contention error: a row needed by the current statement is currently locked by another session. It's also a version-history-sensitive code — historically (before Version 4.1) it appeared specifically with UPDATE/DELETE ... WHERE CURRENT OF statements, and it was discontinued starting in Version 6.0, so its practical relevance depends heavily on the server version in use.

  1. Another session holds a lock on the target row, and the current session's default lock mode doesn't wait for it to release.
  2. A long-running transaction elsewhere holding row locks longer than expected, causing frequent contention for other sessions.
  3. SET LOCK MODE TO WAIT not configured, leaving the session to fail immediately on contention rather than waiting for the lock to clear.
  4. On a genuinely old server version (pre-6.0), this appearing specifically on UPDATE/ DELETE ... WHERE CURRENT OF per its original, narrower historical scope.
Solutions / Resolution
  1. Use SET LOCK MODE TO WAIT, per the official guidance, to have the session wait for conflicting locks to clear instead of failing immediately — this prevents most occurrences.
  2. Check the accompanying ISAM error code (commonly one of -107, -113, -134, -143, -144, or -154) for more detail on the specific relationship between the conflicting programs/sessions.
  3. Investigate long-held locks from other sessions if contention is frequent, rather than just retrying indefinitely.
  4. Confirm the server version in use — this specific error code was discontinued as of Version 6.0, so its presence (or absence) is itself a signal about which version is running.
Examples
Setting the session to wait for locks
SET LOCK MODE TO WAIT;
UPDATE orders SET status = 'shipped' WHERE order_id = 1001;
-- waits for a conflicting lock to clear instead of failing
-- immediately with -378
Setting a bounded wait instead of an indefinite one
SET LOCK MODE TO WAIT 30;
-- waits up to 30 seconds before giving up
Diagnostic Checks
  1. Check the accompanying ISAM error code for the specific lock-conflict detail.
  2. Check sysmaster:syslocks for the session currently holding the conflicting lock.
  3. Confirm the current session's lock mode (SET LOCK MODE) and whether waiting is configured.
Related Errors / Related Topics
  • -346 — "Could not update a row in the table." Another lock-contention-related failure, at a more general storage-engine level.
  • -347 — "Could not open table for exclusive access." A related lock-contention failure, at the table-exclusive-access level rather than a single row.

SET LOCK MODE TO WAIT resolves most occurrences by having the session wait rather than fail immediately — check for long-held locks from other sessions if contention keeps recurring.