Informix Error -187: ISAM error: User Defined Routine execution failed.

Reasons / Common Causes

-187 is a generic wrapper around a user-defined routine (UDR) raising an error during its own execution — the official text is direct that the message log, not this code itself, carries the specific detail.

1. The UDR raised an error during its own execution — the most direct and common cause, per the official text.
2. A bug in the UDR's own logic — an unhandled exception, a failed assertion, or a runtime error specific to whatever language the UDR is implemented in (SPL, C, Java, or another supported UDR language).
3. Resource issues within the UDR's execution context — memory pressure, or trouble accessing an external resource the UDR calls out to.
4. Invalid input passed to the UDR that its own logic doesn't handle gracefully, causing it to raise an error rather than a cleaner, more specific SQL-level failure.
5. An external dependency the UDR relies on (a file, a network service, another database object) being unavailable at execution time.
6. Version or compatibility issues after a UDR language runtime upgrade — a Java JVM version change affecting Java UDRs, for example — not reflected in re-registration or configuration.

Solutions / Resolution

1. Check the message log for specific information first, per the official guidance — this is a generic wrapper, and the actual failure detail lives there.
2. Review the UDR's own source code or logic for the specific failure condition identified in the message log.
3. Test the UDR in isolation with the specific input that triggered the failure, to reproduce and debug it directly rather than through the calling SQL statement.
4. Confirm the availability of any external dependency the UDR relies on, if one is involved.
5. Verify UDR registration and configuration compatibility if a recent language-runtime upgrade correlates with when this started appearing.
6. Add proper error handling within the UDR itself, if the goal is a cleaner failure mode for callers, rather than letting an unhandled exception propagate up as this generic error.

Examples

Checking the message log first

grep -A 10 "User Defined Routine" $INFORMIXDIR/online.log

This is the first step, always — -187 by itself doesn't say which UDR failed or why.

Reproducing in isolation

-- Rather than debugging through the full application query,
-- call the UDR directly with the specific input that triggered the failure
EXECUTE FUNCTION my_udr(:the_specific_input);

Isolating the call makes it much easier to attach a debugger or add targeted logging than trying to reproduce the failure through the original, more complex application query.

Diagnostic Checks

1. Check the message log for the specific UDR failure detail.
2. Identify which specific UDR and invocation triggered the failure.
3. Test or reproduce the UDR call in isolation, outside the original application context.
4. Check for recent changes to the UDR itself, its dependencies, or its runtime environment.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -172 — "ISAM error: Unexpected internal error." Similar in that the message log is the real source of diagnostic detail, though -172 is a general engine-internal catch-all while -187 is specifically about UDR execution.

Check the message log before debugging application code — it's where the actual reason the UDR failed will be recorded.