Informix Error -213: Statement interrupted by user.

Reasons / Common Causes

-213 is the SQL-layer counterpart to -157's ISAM-level interrupt — a normal, expected condition rather than a defect. The database server received an interrupt signal, most likely because someone pressed the interrupt key (Delete or Control-C) during a running statement.

1. A user pressing the interrupt key during a long-running statement — the direct, everyday cause.
2. Application-level cancellation logic deliberately sending an interrupt to abort a query that's taking too long — the intended outcome of that cancellation policy.
3. A supervisory or watchdog process enforcing a time limit, sending an interrupt signal to a client exceeding its allotted time.
4. Unintended signal propagation — a process-group Ctrl-C hitting more processes than intended, the same theme as -157.

Solutions / Resolution

1. Roll back the current transaction and terminate gracefully, per the official guidance — this is the correct, expected response to a deliberate interrupt, not a bug to work around.
2. If the statement could modify a table, explicitly execute ROLLBACK WORK. This matters specifically for DML — an interrupted INSERT/UPDATE/DELETE can leave partial modifications if not explicitly rolled back, and an interactive user needs to do this themselves rather than assuming the interrupt alone cleaned everything up.
3. Build graceful interrupt handling into application code — catch -213, roll back cleanly, and exit or resume as appropriate, rather than crashing or leaving a transaction hanging.
4. If unintended signal propagation is suspected, review process and signal-handling architecture, the same investigation as -157.

Examples

The expected interactive case

-- Interactive session running a long DML statement
UPDATE huge_table SET status = 'processed' WHERE batch_id = 42;
-- user presses Ctrl-C partway through
-- -213: expected — but partial modifications may exist

ROLLBACK WORK;
-- explicitly clean up any partial modifications from the
-- interrupted UPDATE

Graceful handling in application code

if (iserrno == -213) {
    rollback_transaction();
    log_info("Statement interrupted by user — transaction rolled back");
    /* exit or resume cleanly, rather than propagating an unhandled error */
}

Diagnostic Checks

1. Confirm whether the interrupt was deliberate (a user action, a timeout policy) or unexpected signal propagation.
2. Check whether the interrupted statement was DML — if so, confirm ROLLBACK WORK was actually executed to clean up any partial modifications.

Related Errors / Related Topics

• -157 — "ISAM error: Interrupted ISAM call." The direct ISAM-level counterpart to this same interrupt concept — same underlying cause, different layer of the engine reporting it.

If the interrupted statement could have modified data, always follow up with an explicit ROLLBACK WORK — don't assume the interrupt alone left the database in a clean state.