Oninit
Talk to an expert →

Informix Error -363

-363 CURSOR not on SELECT statement.

The cursor named in this statement (probably an OPEN) has been associated with a prepared statement that is not a SELECT statement. Review the program logic, especially the DECLARE for the cursor, the statement id specified in it, and the PREPARE that set up that statement. If you intended to use a cursor with an INSERT statement, you can only do that when the INSERT statement is written as part of the DECLARE statement. If you intended to execute an SQL statement, do that directly with the EXECUTE statement, not indirectly through a cursor.

This error is also returned when you attempt to associate a cursor with a SELECTINTO TEMP statement. Because of the INTO TEMP clause, the SELECT statement can return no rows and so cannot be used with a cursor.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-363 fires when a DECLARE CURSOR is associated with a prepared statement that isn't a plain, row-returning SELECT — cursors fundamentally exist to iterate over a result set, so anything that doesn't produce one in the expected way is disallowed.

  1. Declaring a cursor over a PREPAREd statement that turns out not to be a SELECT — often from a dynamically-built statement string where the actual statement type wasn't verified.
  2. Attempting a cursor over an INSERT statement outside of the specific supported pattern — insert cursors are only valid when written directly within the DECLARE statement itself, not via a separately prepared INSERT.
  3. Attempting a cursor over a SELECT ... INTO TEMP statement — the INTO TEMP clause redirects the result set into a temp table instead of returning rows to the caller, so there's nothing for a cursor to fetch from directly.
Solutions / Resolution
  1. Review the program logic around DECLARE, the statement identifier, and PREPARE, per the official guidance, to confirm the prepared statement is genuinely a plain SELECT.
  2. For insert cursors, write the INSERT directly inside the DECLARE statement rather than preparing it separately and declaring a cursor over the prepared handle.
  3. For a SELECT ... INTO TEMP, split the operation: run the SELECT ... INTO TEMP statement on its own to materialize the temp table, then declare a cursor over a plain SELECT from that temp table if iteration is needed.
Examples
Splitting a SELECT INTO TEMP from cursor iteration
-- This won't work directly:
DECLARE curs1 CURSOR FOR
    SELECT * FROM orders WHERE status = 'pending' INTO TEMP recent_orders;
-- -363

-- Fix: materialize first, then declare a cursor over the temp table
SELECT * FROM orders WHERE status = 'pending' INTO TEMP recent_orders;
DECLARE curs1 CURSOR FOR SELECT * FROM recent_orders;
An insert cursor written correctly
DECLARE ins_curs CURSOR FOR
    INSERT INTO orders (order_id, customer_id) VALUES (?, ?);
Diagnostic Checks
  1. Confirm the prepared statement associated with the cursor is a plain SELECT, not an INSERT prepared separately or a SELECT ... INTO TEMP.
  2. For dynamically built SQL, verify the statement type before attaching a cursor to it.
Related Errors / Related Topics
  • -201 — "A syntax error has occurred." The general SQL-parsing-error family this fits into.

Cursors need a plain, row-returning SELECT — split out a SELECT ... INTO TEMP into a separate materialization step, and write insert cursors directly inside the DECLARE rather than via a separately prepared INSERT.