Error 1322 is raised when a cursor is declared on anything other than a SELECT statement inside a stored program.
MySQL Error 1322: ER_SP_BAD_CURSOR_QUERY happens when you open or declare a cursor on a non-SELECT statement. Replace the offending statement with a valid SELECT or refactor the logic to avoid using cursors on UPDATE, DELETE, or CALL statements to resolve the issue.
Cursor statement must be a SELECT
The message “Cursor statement must be a SELECT” (SQLSTATE 42000) appears when MySQL encounters a cursor that is not based on a SELECT statement inside a stored procedure or function.
MySQL allows cursors only for result sets generated by SELECT. Any attempt to OPEN a cursor tied to UPDATE, INSERT, DELETE, or CALL triggers error 1322.
Using UPDATE, DELETE, INSERT, or CALL in the cursor declaration immediately causes error 1322 when the procedure is compiled or when the cursor is opened.
Dynamic SQL assembled with PREPARE and EXECUTE that ultimately resolves to a non-SELECT can also lead to the same failure once the cursor is opened.
Replace the non-SELECT cursor query with an equivalent SELECT that returns the rows you intend to process, then perform data-changing statements inside the FETCH loop.
Where a data-changing cursor is truly required, refactor by using a SELECT to collect primary keys, then apply UPDATE or DELETE inside the loop.
Attempting to iterate over rows to delete them directly with a cursor like “DECLARE c1 CURSOR FOR DELETE FROM t WHERE ...” triggers error 1322. Instead, declare “SELECT id FROM t WHERE ...” and delete inside the loop.
Calling another stored procedure within the cursor definition, such as “DECLARE c1 CURSOR FOR CALL get_rows()”, fails. Refactor get_rows() into a plain SELECT view or inline SELECT.
Always verify cursor statements are pure SELECTs before compiling procedures. Adopt a naming convention that highlights read-only cursor queries.
Use set-based SQL where possible. If row-by-row processing is necessary, limit cursors to selecting keys and perform modifications in the loop body.
Error 1324 ER_SP_BAD_CURSOR_SELECT occurs when a cursor is opened before a handler is declared, producing similar symptoms. Declare handlers before OPEN.
Error 1321 ER_SP_NOT_VAR_ERR indicates misuse of a non-variable in cursor loops. Check FETCH targets.
Declaring a cursor with UPDATE, DELETE, INSERT, or REPLACE violates the rule that cursors must be SELECT only.
Using a stored procedure call inside the cursor query prevents compilation because the resulting statement is not an explicit SELECT.
Building the cursor query dynamically can mask the real statement type until runtime, where a non-SELECT raises error 1322.
Raised when a cursor is opened before applicable handlers are declared. Fix by declaring handlers prior to OPEN.
Occurs if FETCH targets are not variables. Ensure FETCH ... INTO lists variables only.
Indicates variable declarations placed after cursor handlers. Reorder declarations above handlers.
No. MySQL allows cursors only on SELECT statements. Declare a SELECT that returns keys, then UPDATE inside the loop.
If the cursor SQL is literal, MySQL throws the error at procedure creation. Dynamic SQL may defer the error until OPEN.
Galaxy’s SQL editor validates stored program syntax in real time and flags non-SELECT cursor definitions before you run them, preventing the error.
All supported versions from 5.0 onward enforce the SELECT-only rule for cursors and will emit error 1322.