Informix Error -258
-258 System error - invalid statement id received by the sqlexec
process.The current statement (EXECUTE or OPEN) refers to a prepared SQL statement or a cursor that does not exist. Possibly the statement id is invalid, or possibly the statement was prepared and then released with the FREE statement. Review the program logic to make sure that the statement or cursor that is named in this statement is valid, has been properly prepared or declared, and has not been freed prior to this point.
If the program executes a prepared DATABASE statement successfully, the database server automatically frees the prepared statement. As a result, if you free a prepared DATABASE statement, you will receive this error on the FREE statement. You can ignore it in this case.
Oninit® Troubleshooting Guidance
Reasons / Common Causes
-258 is the opposite-direction sibling of -257's statement-lifecycle theme: instead of too many prepared statements accumulating, this is a reference to a prepared statement or cursor that doesn't exist — usually a "use after free" bug, though the official text names one specific, harmless exception worth knowing before treating every occurrence as a bug.
- A genuinely invalid statement id —
EXECUTEorOPENreferring to something that was never successfully prepared or declared. - The statement was already released with
FREEbefore being referenced again — a use-after-free bug in program logic. - A specific, documented harmless case: executing a prepared
DATABASEstatement. The engine automatically frees a preparedDATABASEstatement once it executes successfully. If application code then also explicitly callsFREEon it — not knowing the engine already did — this error results on thatFREEcall specifically, and per the official guidance, it can be safely ignored in this one case.
Solutions / Resolution
- Review program logic to confirm the statement or cursor named is valid — properly prepared or declared, and not already freed before this point.
- For the
DATABASE-statement-specific case, recognize this as expected and harmless. Per the official guidance, ignore the error when it occurs on aFREEcall against a preparedDATABASEstatement that already executed successfully. - Fix any genuine use-after-free bugs in statement or cursor handling code for every other case.
Examples
The harmless, documented exception
EXEC SQL PREPARE db_stmt FROM 'DATABASE mydb';
EXEC SQL EXECUTE db_stmt;
/* the engine automatically frees db_stmt here, internally */
EXEC SQL FREE db_stmt;
/* -258: db_stmt was already freed automatically — safe to ignore
per the official guidance, specifically for DATABASE statements */
A genuine use-after-free bug
EXEC SQL PREPARE stmt FROM :query_text;
EXEC SQL EXECUTE stmt;
EXEC SQL FREE stmt;
/* Later, mistakenly reused: */
EXEC SQL EXECUTE stmt;
/* -258: stmt was already freed and this is a genuine bug,
not the DATABASE-statement exception */
Diagnostic Checks
- Confirm whether the referenced statement is a
DATABASEstatement — if so, and the error occurs onFREE, it's the documented harmless case and can be ignored. - For anything else, review the program logic's prepare/free lifecycle for the specific statement or cursor to find the actual use-after-free bug.
Related Errors / Related Topics
- -257 — "System limit on maximum number of statements exceeded, maximum is count." The direct sibling in the same statement-lifecycle-management family — that error is about accumulating too many; this one is about referencing something already gone.
- -201 — "A syntax error has occurred." The general SQL-parsing-error family this fits into.
Check whether this is the documented DATABASE-statement exception before treating it as a bug
— that specific case is expected and safe to ignore.