Informix Error -149: ISAM error: IBM Informix OnLine daemon is no longer running.

Reasons / Common Causes

-149 is the client-side view of the database server itself disappearing while a connection was active. This isn't a condition application code caused or can prevent from its side — it's a report that the server process the application was talking to is simply no longer running.

1. The database server crashed unexpectedly — a segfault, an out-of-memory kill, or another fatal condition terminating the engine process while clients were still connected.
2. The server was deliberately shut down (an administrator-initiated onmode shutdown or equivalent) while clients were still connected, without first draining or notifying active sessions.
3. A host-level failure — an OS crash, an unplanned reboot, a power loss — taking down the server process along with everything else on the machine.
4. OS-level resource exhaustion (out-of-memory conditions) causing the operating system to kill the server process to reclaim memory.
5. A planned maintenance restart that active client connections weren't given advance notice to disconnect from gracefully.

Solutions / Resolution

1. Terminate the application, per the official guidance — continuing to attempt operations against a server that's confirmed gone accomplishes nothing and risks confusing error handling further.
2. Contact the database server administrator to find out what happened and when the server will be restarted. This is explicitly an operational/communication step, not something to diagnose purely from the client side.
3. Understand that the in-flight transaction will be rolled back automatically during the server's fast recovery when it next starts up — no manual rollback action is needed, or possible, from the client at this point.
4. Once the server is confirmed healthy again, reconnect and resume or retry work as appropriate — avoid blind automatic reconnect-and-retry loops that don't confirm the server is actually back and stable, especially if the outage stemmed from a serious underlying issue.
5. Build graceful handling of a lost server connection into application design — detect this condition explicitly, log or alert clearly, and avoid silent retries that could mask a serious outage from whoever needs to respond to it.
6. For administrators, follow proper procedures to drain or notify active connections before a planned shutdown going forward, to reduce how many applications hit this abruptly next time.

Examples

Detecting and responding cleanly

if (iserrno == -149) {
    log_critical("Database server connection lost — server no longer running");
    notify_operations_team();
    terminate_application();
    /* Do not attempt to reconnect automatically here — confirm server
       health with an administrator first */
}

What NOT to do: silent blind retry

while (iserrno == -149) {
    sleep(1);
    reconnect();   /* risks hammering a server that's mid-crash-recovery,
                      or masking a serious outage behind quiet retries */
}

A brief, bounded retry with clear logging is reasonable; an unbounded silent loop is not — it delays anyone noticing there's a real outage to respond to.

Diagnostic Checks

1. Check server status directly:

   onstat -
   

   to confirm whether the server process is actually running again, before assuming it's safe to reconnect.
2. Check server and system logs for the failure's signature:

   grep -iE "abort|panic|shutdown|assert" $INFORMIXDIR/online.log
   dmesg -T | grep -iE "oom|killed process"
   

3. Check for a recent host-level issue — a reboot, a hardware alert — coincident with the disconnect.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -118 — "ISAM error: cannot read log record." Related through the recovery mechanism this error's own resolution depends on — the transaction log is what makes the automatic rollback during the server's fast recovery possible when it next starts.

Don't try to diagnose the server-side cause purely from the client — the administrator has visibility (server/system logs, process status) that the disconnected application simply doesn't.