Error 1329 occurs when a FETCH in a stored-procedure cursor returns no row and no NOT FOUND handler is present.
MySQL Error 1329 (ER_SP_FETCH_NO_DATA) means a cursor FETCH found zero rows and the procedure lacked a NOT FOUND handler. Add a CONTINUE HANDLER FOR NOT FOUND to set a flag and exit the loop cleanly to resolve the issue.
No data - zero rows fetched, selected, or processed
MySQL raises error 1329 (SQLSTATE 02000) with the message "No data - zero rows fetched, selected, or processed" when a FETCH statement inside a stored procedure cursor returns no row but the procedure still tries to read column data.
The error usually surfaces during WHILE loops that fetch from a cursor without checking the NOT FOUND handler. Without that handler, MySQL interprets the empty result as an exception and stops execution.
The immediate trigger is a cursor FETCH that hits the end of the result set.
Missing or incorrectly declared CONTINUE HANDLER FOR NOT FOUND leads MySQL to throw error 1329 instead of silently exiting the loop.
Attempting to fetch into variables whose number or type do not match the cursor SELECT can also surface the same error because MySQL concludes that no valid row was returned.
Declare a CONTINUE HANDLER FOR NOT FOUND that sets a flag variable when the cursor is exhausted, then exit the loop based on that flag.
Always FETCH into variables whose count and data types match the cursor SELECT list exactly to avoid unexpected no-row situations.
If the procedure should allow zero-row result sets, test FOUND_ROWS or the flag before processing the fetched data.
Iteration over user IDs where a preceding DELETE removed all qualifying rows will trigger the error unless guarded.
Dynamic cursors created from parameter values that sometimes yield no rows are frequent sources during ETL jobs.
Always add a NOT FOUND handler to every stored procedure that uses cursors.
Log how many rows a cursor opens by reading ROW_COUNT immediately after OPEN to make loop design safer.
Tools like Galaxy highlight missing handlers and suggest code snippets, helping teams ship robust procedures from the editor.
Error 1327 (ER_SP_UNDECLARED_VAR) appears when you fetch into an undeclared variable. Error 1334 (ER_SP_CANT_SET_CHARSET) may arise if the cursor result set collations are inconsistent. Both are fixed by verifying declarations and session settings.
Developers forget to declare CONTINUE HANDLER FOR NOT FOUND, so MySQL throws error 1329 when the cursor is empty.
Loops keep calling FETCH after the last row because a control flag is not tested.
FETCH targets fewer or differently typed variables than the columns returned by the cursor SELECT statement.
Parameters passed to the cursor query filter out all rows, leaving nothing to fetch.
Raised when a referenced variable is not declared in the stored procedure. Declare the variable before use.
Appears if the procedure cannot switch to a required character set. Align client and server charsets.
Occurs when a subquery returns multiple rows where only one was expected. Limit the subquery result or add aggregation.
Yes. Without it, any empty result raises error 1329 and stops your procedure. Always declare a handler and exit loops safely.
No. Ignoring it causes partial data processing and hard-to-trace bugs. Fix the cursor logic instead.
Galaxy's editor linter flags cursors lacking a NOT FOUND handler and offers an auto-insert snippet, reducing human error.
No. The error exists in all supported MySQL versions that implement stored procedure cursors, including 5.7 and 8.0.
.avif)
.avif){kind=logo}
