Oninit
Talk to an expert →

Informix Error -424

-424 Cursor already declared from this prepared statement.

This DECLARE statement associates a cursor with the name of a prepared statement. However, another DECLARE statement has already been executed, and it associates a different cursor with the same statement id. This action is not supported; a given statement can be associated with only one cursor. Check all the DECLARE statements in the program, and check that they all refer to unique statements.

This error message should not appear for Version 5.0 and later.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-424 is a version-history-sensitive restriction: on the affected versions (obsolete as of 5.0 and later, per the official guidance), each prepared statement could only ever have one DECLARE CURSOR associated with it — a second DECLARE against the same prepared statement identifier was rejected outright.

  1. A second DECLARE CURSOR issued against the same prepared statement identifier — the direct, only cause, on affected pre-5.0 versions.
  2. A loop or retry pattern accidentally re-declaring a cursor against the same already- cursor-bound prepared statement, rather than reusing the existing cursor or freeing/re- preparing first.
  3. Working on a genuinely old server version, where this restriction is still enforced; on 5.0+ servers, this exact error is obsolete and the underlying scenario is handled differently.
Solutions / Resolution
  1. Ensure each DECLARE statement references a unique prepared statement, per the official guidance, rather than reusing the same one for multiple cursors.
  2. Reuse the already-declared cursor rather than attempting to declare a second one against the same prepared statement.
  3. If a fresh cursor against the same underlying SQL text is genuinely needed, re-PREPARE the statement under a new identifier first, then DECLARE a cursor against that new one.
  4. Confirm the server version in use — this restriction is obsolete on 5.0 and later, so its appearance is itself a signal about which version is running.
Examples
Reusing the existing cursor instead of re-declaring
PREPARE stmt1 FROM 'SELECT * FROM orders WHERE status = ?';
DECLARE curs1 CURSOR FOR stmt1;
OPEN curs1 USING :status_val;
-- reuse curs1 for subsequent opens rather than declaring a
-- second cursor against stmt1
Preparing a fresh statement identifier for a genuinely separate cursor
PREPARE stmt2 FROM 'SELECT * FROM orders WHERE status = ?';
DECLARE curs2 CURSOR FOR stmt2;
Diagnostic Checks
  1. Check whether the prepared statement identifier already has a cursor declared against it.
  2. Confirm the server version — this restriction doesn't apply at all on 5.0 and later.
Related Errors / Related Topics
  • -412 — "Command pointer is NULL." A related dynamic-SQL/cursor-lifecycle error, about an unprepared or freed statement rather than a duplicate cursor declaration.
  • -410 — "Prepare statement failed or was not executed." Another related PREPARE/DECLARE sequencing error.

This restriction is obsolete on server versions 5.0 and later — on older versions, reuse the existing cursor or PREPARE the statement text again under a new identifier rather than re-declaring against the same one.