Informix Error -267

Reasons / Common Causes

-267 is part of the same statement/cursor-lifecycle family as -257/-258, with a documented recovery path this time: the cursor's resources were released, and it needs to be re-prepared or re-declared before use.

1. The cursor was explicitly released via FREE, and then referenced again — a use-after-free, the same class of bug as -258.
2. An automatic re-prepare attempted while opening the cursor failed, leaving it unavailable — a less obvious cause: the engine tried to silently reprepare the statement on open, and that attempt itself failed.

Solutions / Resolution

1. Re-prepare or re-declare the statement before reusing the cursor, per the official guidance:
   • If the cursor was declared FOR a statement directly, re-execute its DECLARE statement.
   • If the cursor was declared FOR a statement identifier (a previously PREPAREd statement), execute PREPARE again first.
2. Review program logic for FREE calls followed by continued cursor use — the same use-after-free pattern -258 describes.
3. If an automatic re-prepare failure is suspected, investigate why the re-prepare itself failed — an underlying schema change, or a syntax issue in a dynamically built statement, are the most likely explanations.

Examples

Re-preparing after FREE

EXEC SQL FREE cur1;

/* Later, reusing the cursor without re-preparing first: */
EXEC SQL OPEN cur1;
/* -267: cur1's resources were released */

Fix — re-prepare (or re-declare) before reuse:

EXEC SQL PREPARE stmt FROM :query_text;
EXEC SQL DECLARE cur1 CURSOR FOR stmt;
EXEC SQL OPEN cur1;

An automatic re-prepare failure

/* The engine attempts an automatic re-prepare on OPEN, which fails
   because the underlying table was altered since the statement was
   first prepared */
EXEC SQL OPEN cur1;
/* -267: the automatic re-prepare failed, leaving the cursor unavailable */

Investigate the schema change or dynamic-statement issue that caused the re-prepare itself to fail, then explicitly re-prepare/re-declare once resolved.

Diagnostic Checks

1. Review program logic for FREE calls followed by continued use of the same cursor.
2. If an automatic re-prepare failure is suspected, check for recent schema changes affecting the underlying statement, or issues in how the statement was dynamically built.

Related Errors / Related Topics

• -258 — "System error - invalid statement id received by the sqlexec process." The closest sibling — the same general use-after-free theme, for statements generally rather than cursors specifically.
• -257 — "System limit on maximum number of statements exceeded, maximum is count." Another member of the same statement-lifecycle-management family.

Re-prepare or re-declare before reusing a cursor that was freed — this error has a documented, direct recovery path, not just a bug to avoid.