Informix Error -157: ISAM error: Interrupted ISAM call.

Reasons / Common Causes

-157 is usually the expected result of something interrupting the client process during an in-flight ISAM operation — not a defect, and often not even unexpected once the interrupt's source is identified.

1. A signal (such as SIGINT/Ctrl-C) received by the client process while an ISAM call was in progress, aborting the operation.
2. A user manually interrupting a long-running query from an interactive tool — pressing Ctrl-C in an interactive SQL client while a statement is executing is the most direct, everyday cause.
3. Application-level timeout or cancellation logic deliberately sending an interrupt to abort a query that's taking too long — this is the intended outcome of that cancellation policy, not a failure of it.
4. A supervisory process — a watchdog, a job scheduler enforcing a time limit — sending a termination or interrupt signal to a client process that exceeded its allotted time.
5. Unintentional signal delivery, such as a shell or process manager propagating SIGINT/ SIGTERM across an entire process group when only one process in that group was actually meant to receive it (a classic terminal Ctrl-C-hits-everything scenario).
6. A client library's own cancellation feature invoked programmatically — a "cancel query" API call intentionally interrupting an in-flight operation.

Solutions / Resolution

1. Restart the operation, per the official guidance — if the interrupt was unintentional (an accidental Ctrl-C, unintended signal propagation), simply retrying resolves it.
2. If the interrupt was deliberate (a user cancellation, a timeout policy), no further action is needed beyond recognizing this as the expected outcome of that cancellation — don't treat it as an unexpected failure to investigate.
3. If signals are being delivered unintentionally, review process and signal-handling architecture to isolate the client process appropriately, so unrelated signals (process-group propagation, for example) don't inadvertently interrupt in-flight database operations.
4. For automated jobs enforcing timeouts via interrupt signals, consider whether a cleaner, application-level cancellation mechanism is more appropriate than an OS-level signal, and ensure retry or resumption logic exists for operations that are legitimately time-limited but still need to complete eventually.
5. If this occurs unexpectedly and frequently without an obvious intentional cause, investigate what's actually sending interrupts to the client process — a monitoring tool, a supervisor process, or a misconfigured job scheduler.

Examples

Deliberate user cancellation

-- Interactive session running a long query
SELECT * FROM huge_table ORDER BY unindexed_column;
-- user presses Ctrl-C partway through
-- -157: expected — the operation was intentionally interrupted

Nothing to fix here — this is the interactive tool correctly honoring the cancellation.

Unintended process-group signal propagation

#!/bin/bash
# Launches a long-running client process as part of a larger script
run_report_client &
CHILD_PID=$!
# ... later, an unrelated Ctrl-C at the terminal propagates to the
# entire process group, including $CHILD_PID, interrupting its
# in-flight database operation even though only the parent script
# was meant to stop

Isolating the child process into its own process group (or handling signals explicitly rather than relying on default propagation) prevents this class of unintended interruption.

A job scheduler enforcing a time limit

A scheduled batch job configured with a hard time limit sends a termination signal to the client process once that limit is reached, interrupting whatever ISAM operation was in progress at that moment — expected behavior of the time-limit policy, though worth reviewing whether the limit itself is appropriately sized for the job's actual typical duration.

Diagnostic Checks

1. Determine whether the interrupt was deliberate (a user cancellation, a timeout policy) or unexpected — this is the key branch point for what to do next.
2. Review process and signal-handling architecture if unintended signal propagation is suspected, particularly for processes launched from shell scripts or process managers.
3. Review job scheduler or watchdog configuration if an automated system might be sending interrupts as part of a time-limit or monitoring policy.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family, though unrelated in cause — grouped here as background on how this error class is organized.

Confirm whether the interrupt was intentional before treating -157 as a problem to fix — a large share of occurrences are simply cancellations working as designed.