Informix Error -439: Database server is currently processing an SQL task.

Reasons / Common Causes

-439 fires when a signal handler or the registered callback function/procedure itself attempts to call an SQL routine or execute a SQL statement while the server is already mid-task — the callback mechanism is meant to run alongside an in-progress SQL operation (e.g. to check for a user-requested interrupt), not to issue new SQL work of its own.

1. A callback function attempting to execute an arbitrary SQL statement from within its own body — not supported, since the server is already busy processing the original task.
2. Using a general SQL call inside the callback instead of the specific narrow functions designed for this context (sqldone()/sqlbreak() for ESQL/C, or ECO-SQD/ECO-SQB for ESQL/COBOL).
3. A signal handler calling into SQL routines directly, rather than using the supported narrow interface.

Solutions / Resolution

1. Use only the specific supported library functions within a callback, per the official guidance: sqldone() and sqlbreak() for ESQL/C callbacks, or the ECO-SQD and ECO-SQB routines for ESQL/COBOL callbacks.
2. To unregister a callback from within itself, use sqlbreakcallback() (ESQL/C) or ECO-SQBCB (ESQL/COBOL), per the official guidance — these are the specific supported mechanisms for that purpose.
3. Don't attempt arbitrary SQL execution inside a callback or signal handler — restructure the logic to only check/signal state, deferring any real SQL work until control returns to normal application flow.

Examples

Using sqldone()/sqlbreak() correctly within an ESQL/C callback

int my_callback(void) {
    if (sqldone()) {
        return 1;  /* signal the original SQL task should stop */
    }
    return 0;
}

The disallowed direct SQL call from within a callback

int my_callback(void) {
    EXEC SQL SELECT COUNT(*) INTO :cnt FROM orders;
    /* -439: arbitrary SQL execution isn't allowed here */
    return 0;
}

Diagnostic Checks

1. Check whether the callback/signal handler is calling an arbitrary SQL statement or routine, rather than the specific supported narrow functions.
2. Confirm which supported function is appropriate for the intended purpose (checking completion status, requesting a break, or unregistering the callback).

Related Errors / Related Topics

• -437 — "Connection must be established before registering callback function." A related restriction in the same callback-registration mechanism, about sequencing rather than what the callback itself is allowed to do.
• -398 — "Cursor manipulation must be within a transaction." Another restriction on where certain SQL operations are and aren't valid, in a different context.

Callbacks can only use the narrow supported functions (sqldone()/sqlbreak() or their ESQL/COBOL equivalents) — arbitrary SQL execution from within one is never supported.