<p>MySQL raises error 1420 when you try to execute a prepared statement that still has an open cursor from a previous FETCH.</p>
<p>MySQL Error 1420: ER_EXEC_STMT_WITH_OPEN_CURSOR occurs when you call EXECUTE on a prepared statement while its cursor remains open after a FETCH. Close the cursor with CLOSE or reset the statement before re-executing.</p>
You can't execute a prepared statement which has an open
Error 1420 (SQLSTATE HY000) appears with the message: You can't execute a prepared statement which has an open cursor associated with it. Reset the statement to re-execute it.
The server blocks EXECUTE because the current prepared statement still owns an active cursor following a FETCH. MySQL requires that cursor life-cycle commands finish before re-execution.
The error surfaces in stored procedures, server-side prepared statements, and API code that loops through result sets using cursors and then tries to execute the same statement again without closing or resetting it.
Leaving cursors open wastes server resources and can stall transaction logic. Properly closing the cursor restores statement reusability and prevents application downtime.
The primary trigger is calling EXECUTE on a prepared statement that still has a cursor open after a FETCH operation.
Additional causes include missing CLOSE commands in stored procedures, error paths that exit loops prematurely, and client libraries that implicitly reuse prepared statements without cleaning up.
Always CLOSE the cursor before calling EXECUTE again. If you need to rerun the statement many times, wrap the sequence OPEN - FETCH - CLOSE inside a loop.
If using a client API, call stmt.reset() or conn.unprepare() equivalents before re-executing.
Stored procedures that iterate over large result sets must explicitly CLOSE the cursor inside the loop exit branch.
Micro-services using connection pools should ensure each borrowed connection resets statements before return.
Adopt try...finally blocks in SQL routines: OPEN, FETCH, CLOSE in the finally section.
Monitor performance_schema.prepare_stmt_instances to catch long-lived cursors early.
Error 1329: No data - zero rows fetched, but cursor left open if not closed.
Error 1243: Unknown prepared statement handler - triggered when you CLOSE a cursor that was never opened.
The cursor is opened and fetched but never closed before the next EXECUTE.
Control flow jumps out of a loop after FETCH without invoking CLOSE in an exception path.
Some connectors reuse prepared statements across calls, leading to an unexpected open cursor state.
Opening a second cursor on the same statement without closing the first leaves the original cursor open.
Occurs when you try to CLOSE or DEALLOCATE a statement that was not prepared or was already unprepared.
Raised after a FETCH returns no rows; if you forget to CLOSE the cursor, executing again can lead to Error 1420.
Appears in client libraries when you issue a new query without reading the full result set of the previous statement.
No data is lost; the server simply blocks re-execution until the cursor is closed.
MySQL does not auto-close cursors; you must call CLOSE explicitly or reset the prepared statement.
Error 1420 exists in all supported MySQL 5.7 and 8.x versions that support cursors and prepared statements.
Galaxy highlights open cursors in the SQL editor and suggests CLOSE statements with its AI copilot, reducing the chance of hitting error 1420.
.avif)
.avif){kind=logo}
