Informix Error -524: Lock table can only be used within a transaction.

Reasons / Common Causes

-524 fires when LOCK TABLE is issued against a database that has a transaction log, outside of an active transaction — locks in a logged database are transaction-scoped, so there must be a transaction for the lock to belong to.

1. LOCK TABLE issued before BEGIN WORK, per the official guidance — the direct, only cause.
2. A database created WITH LOG (or WITH BUFFERED LOG/WITH LOG MODE ANSI), where transactions are mandatory for locking, versus an unlogged database where this restriction doesn't apply.
3. Application code that assumes autocommit-style locking, issuing a LOCK TABLE as a standalone statement the way it might against a non-transactional resource.

Solutions / Resolution

1. Issue BEGIN WORK before the LOCK TABLE statement, per the official guidance:

   BEGIN WORK;
   LOCK TABLE orders IN EXCLUSIVE MODE;
   

2. Review the program's transaction structure, per the official guidance, to confirm a transaction is actually open at the point the lock is requested — not just somewhere earlier in the program.
3. Commit or roll back the transaction once the locked work is done, since the lock is held only for the transaction's duration:

   COMMIT WORK;
   

Examples

The disallowed attempt

LOCK TABLE orders IN EXCLUSIVE MODE;
-- -524: no transaction is open (database has a transaction log)

Corrected

BEGIN WORK;
LOCK TABLE orders IN EXCLUSIVE MODE;
-- ... locked work ...
COMMIT WORK;

Diagnostic Checks

1. Confirm the database was created with logging (WITH LOG, buffered or ANSI mode) — this restriction only applies to logged databases.
2. Trace the program's transaction boundaries to confirm BEGIN WORK actually precedes the LOCK TABLE call in the executed path, not just in the source order.

Related Errors / Related Topics

No closely related error codes are cross-referenced for -524 in this set yet.

A logged database requires an open transaction for LOCK TABLE to attach to — add BEGIN WORK before it.