Oninit
Talk to an expert →

Informix Error -260

-260 Cannot execute a SELECT statement that is PREPAREd - must use

cursor.

Although you can prepare a SELECT statement, the only way you can then execute that SELECT statement is to associate its statement id with a cursor (use a DECLARE statement) and then open the cursor.

An important exception is the SELECTINTO TEMP statement, which you can execute. You cannot use it with a cursor.

You can execute other prepared statements with the EXECUTE statement. If you know the contents of this SELECT statement at the time you are writing the program, and if you are certain that it will return only a single row of data, you can embed it in the program. If it must be prepared dynamically while the program is running, revise your program to execute it through a cursor.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-260 is a clear restriction with one documented exception: a prepared SELECT statement can't be run with a direct EXECUTE — it needs a cursor, associated via DECLARE, then opened and fetched.

  1. Directly EXECUTE-ing a prepared SELECT statement, rather than declaring a cursor for it and using OPEN/FETCH.
  2. Not realizing SELECT INTO TEMP is a specific, documented exception that can be executed directly — it doesn't return rows to the caller the way an ordinary SELECT does; it creates a table instead.
  3. Confusion about handling a dynamic SELECT expected to return a single row. The official guidance is specific: either embed the statement directly in program logic (if it isn't actually variable), or execute it through a cursor (if it genuinely needs to remain dynamic).
  4. Code ported from a context that allowed direct execution of arbitrary prepared SELECT statements.
Solutions / Resolution
  1. Associate the prepared SELECT with a cursor via DECLARE, then OPEN/FETCH it, rather than calling EXECUTE directly.
  2. Recognize SELECT INTO TEMP as the one exception — it can be executed directly, per the official guidance.
  3. For a dynamic SELECT expected to return a single row, either embed it directly (if it's not actually variable) or use a cursor (if it genuinely needs to stay dynamic).
  4. For all other prepared statement types (non-SELECT), EXECUTE remains the correct approach — this restriction is specific to SELECT.
Examples
The disallowed direct execution
EXEC SQL PREPARE stmt FROM :dynamic_query;
EXEC SQL EXECUTE stmt;
/* -260: stmt is a SELECT — needs a cursor, not direct EXECUTE */

Fix — declare a cursor and fetch through it:

EXEC SQL PREPARE stmt FROM :dynamic_query;
EXEC SQL DECLARE cur1 CURSOR FOR stmt;
EXEC SQL OPEN cur1;
EXEC SQL FETCH cur1 INTO :result;
EXEC SQL CLOSE cur1;
The documented exception: SELECT INTO TEMP
EXEC SQL PREPARE stmt FROM 'SELECT * FROM orders INTO TEMP tmp_orders';
EXEC SQL EXECUTE stmt;
/* valid — SELECT INTO TEMP creates a table rather than returning
   rows, so it doesn't need a cursor */
Diagnostic Checks
  1. Review whether the prepared statement is a SELECT being executed directly instead of through a cursor.
  2. Confirm whether SELECT INTO TEMP applies — if so, direct execution is fine and this error shouldn't be expected.
Related Errors / Related Topics
  • -207 — "Cannot update cursor declared on more than one table. / Cannot declare a SELECT INTO statement FOR UPDATE." Another cursor-declaration restriction in the same general family.
  • -259 — "Cursor not open." Related through the same general cursor-usage lifecycle theme.

Check whether the statement is SELECT INTO TEMP first — that's the one case where direct execution is actually correct, not a mistake.