Question

I am having problems with the error “No data – zero rows fetched, selected, or processed.”

I have shortened my question to this since the answer below describes the problem as well as possible solutions.

The traceback was:

cursor.execute("select function_1() from dual") 

/django/lib/python2.6/django/db/backends/util.py in execute
15.             return self.cursor.execute(sql, params) 

/django/lib/python2.6/django/db/backends/mysql/base.py in execute
86. return self.cursor.execute(query, args) 

usr/local/lib/python2.6/site-packages/MySQLdb/cursors.py in execute
176.       if not self._defer_warnings: self._warning_check() 

/usr/local/lib/python2.6/site-packages/MySQLdb/cursors.py in _warning_check
92.                   warn(w[-1], self.Warning, 3) 

Answer 1

I have spent a long time dealing with the problem: “No data – zero rows fetched, selected, or processed”. I realized that part of the issue is that different versions of MySQL (or perhaps of Django and Python) cause different behaviors. I don’t think that this is specific to Python or Django, but don’t know. I don’t know if it has to do with some variables that are set up, as opposed to something inherent in the different versions.

The two sets of versions are:

• set1: (MySQL: 5.5.19), (Python: 2.7.1), (Django: 1.3.0)
• set2: (MySQL: 5.0.05), (Python: 2.6.8), (Django: 1.2.4)

What I do:

In Python (via Django):

cursor.execute("select function_1() from dual")
cursor.fetchall()

Definitions:

• Dummy query refers to any query of your database that is guaranteed to return a row, but which does not have any purpose in the code logic.
• continue_handler_1329 is: declare continue handler for 1329 begin end;

In VERSION SET1

CASE 1a: Python calls function_1 whose LAST query returns NULL. We get the error.

• Fixed by including dummy query at end (or ensuring that the last query does not return null).
• Including continue_handler_1329 has no effect, assuming that function_1 has no cursors. See below.

CASE 1b: Python calls function_1, which calls function2. There are no mysql cursors. If function2’s LAST query returns null: Function2 is still properly evaluated and returns proper value to function1.

• No fix required.
• Including continue_handler_1329 (in either function) has no effect (it still works).

CASE 1c: Python calls function_1, which opens a cursor that makes a call to function2 (either inside the cursor loop or in the cursor select itself). If function2’s LAST query returns null: THIS IS BAD. The cursor is immediately closed and function_1 continues as though the cursor had been evaluated. There are no warnings.

• Fixed by including dummy query at end of function2 (or ensuring that its last query does not return null)
• Including continue_handler_1329 in function2 has no effect.
• Including continue_handler_1329 in function_1 causes an infinite loop. The cursor doesn’t end up in its own handler when it runs out of rows, but instead ends up in the new handler, not setting Done = True.

In conclusion for VERSION SET1:

• Add last dummy query to the function that is called from Python as well as to any functions that may be called from a cursor. Or otherwise ensure that the last query of these functions never return null. continue_handler_1329 does not solve the issue and will cause problems in functions with cursors (unless continue_handler_1329 is in its own scope).

In VERSION SET2

CASE 2a: Python calls function_1 where ANY query returns NULL. We get the error.

• No dummy query can fix this.
• Fixed by including continue_handler_1329, assuming that function_1 does not have any cursors(see below). Or ensure that no query returns null.

CASE 2b: Python calls function_1, which calls function2. There are no mysql cursors. If function2s has ANY query that returns null: We get the error.

• No dummy query can fix this.
• Fixed by including continue_handler_1329 in function2 (or ensuring that no query returns null).
• Including continue_handler_1329 in function1 has no effect unless it has a cursor (see below)

CASE 2c: Python calls function_1, which opens a cursor that makes a call to function2 (either inside the cursor loop or
in the cursor select itself). If function2 has ANY query that returns null: We get the error.

• No dummy query can fix this.
• Fixed by including continue_handler_1329 in function2 (or ensuring that no query returns null).
• Including continue_handler_1329 in function_1 causes an infinite loop. The cursor doesn’t end up in its own handler when it runs out of rows, but instead ends up in the new handler, not setting Done = True.

In conclusion for version SET2

• Add continue_handler_1329 to any function that may have a query returning null, with the exception of functions with cursors. These should not contain any query that returns null, with the exception of the declared cursor itself. However functions with cursors may contain a seperate begin-end scope with a null-returning-query and continue_handler_1329.

In conclusion for it to work in BOTH:

• Add continue_handler_1329 to all functions that may contain a query returning null AND add last dummy query to the function that is called from Python, as well as to any functions that may be called from a cursor. Functions with cursors may not contain continue_handler_1329 nor queries returning null unless they are in a separate begin-end scope. (The cursor query itself may return null, which will be handled by the cursor’s continue handler.).