0

Is it possible to interrogate PDO to find out if queries are currently active ?

ANSWER = NO

Try setAttribute( PDO::MYSQL_ATTR_USE_BUFFERED_QUERY , true); just in case it works in your case

->closeCursor() after suspect verbs should help but you have to code around usage such as

return $pdoStatement->rowCount()===1;

Suspect verbs

->quote() Slight possibility if connection used like mysql_real_escape_string()
->query() High risk - use ->closeCursor()
->fetch() Highest risk - use ->closeCursor()
->fetchAll() should be safe but errors reported to Stack Overflow
->rowCount() **THIS** was causing my problem

To organise the bug hunt use debug_backtrace()
On line before FATAL ERROR

Use that list to backtrack execution adding ->closeCursor() before each suspect verb line
save
test
if still getting FATAL ERROR fix the next verb one at a time

Once the errant line is discovered you can remove the debug_backtrace()

If that doesn't work I'm all out of ideas as the failure would have been created somewhere on the execution path.


These difficulties seem to be ignored by PHP PDO MySQL

Bug #70066 Unexpected "Cannot execute queries while other unbuffered queries"
Status = OPEN
Url = https://bugs.php.net/bug.php?id=70066
Workaround = The solution is to use exec() instead of query(), but I think that it is bug since there is no other active query.

Bug #71145 Multiple statements in init command triggers unbuffered query error
Status = OPEN
Url = https://bugs.php.net/bug.php?id=71145
Workaround = SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci, SESSION sql_mode=traditional;

Bug #74584 Error about active unbuffered queries triggered unexpectedly
Status = OPEN
Url = https://bugs.php.net/bug.php?id=74584
Description
An exception is thrown in the test case below.
- Emulated prepares must be OFF
- "LOCK TABLE" triggers the error, eg "set @foo='bar'" does NOT
I see no reason why the error occurs in this case.


IMPORTANT

The error generated is a FATAL ERROR

This means that the program ->

...stops dead

...it cannot be handled with try(){}catch($e){} block

This would provide information to discover how to fix error

"General error: 2014 Cannot execute queries while other unbuffered queries are active"

Hopefully this would short circuit looking through all the codebase to find the bug.

Currently I am trying to resolve this error being generated by

$statement = pdo->prepare( $sql );

Which means that the whole codebase is suspect

Why is this different to all other requests ?

NOTE: Error generated at prepare() stage

NOT query()

NOT fetch() and

NOT fetchAll()

NOT ->bind(':name' , $value , PDO::PARAM_STR)

Which means that I am not "executing a queries" when I get that message.

I'm asking because Stack Overflow has many requests on the error but no relevant solution

NOTE: Not Working

$pdo->setAttribute( PDO::MYSQL_ATTR_USE_BUFFERED_QUERY , true);

$pdo->setAttribute( PDO::MYSQL_ATTR_USE_BUFFERED_QUERY , false); // Just in case

John Griffiths
  • 3,263
  • 4
  • 21
  • 19
  • PDO does not know about running queries, that you can check in your database server directly. – marekful May 16 '18 at 15:57
  • 1
    https://stackoverflow.com/questions/17434102/causes-of-mysql-error-2014-cannot-execute-queries-while-other-unbuffered-queries – bassxzero May 16 '18 at 15:58
  • ^ worth reading that one; the top answer was from the chap who literally wrote the book on SQL Antipatterns :) – CD001 May 16 '18 at 16:00
  • try { $statement = pdo->prepare( $sql ); } catch(PDOException $e) { echo "PDOException ='".print_r($e,true)."'
    \n"; }
    – John Griffiths May 16 '18 at 17:27
  • try { $statement = pdo->prepare( $sql ); } catch(PDOException $e) { echo "PDOException ='".print_r($e,true)."'
    \n"; } Still results in "Fatal error: Uncaught exception" Doesn't make sense Fatal errors are not trappable but message states "Uncaught exception" Looks like it went from catchable to fatal due to missing catch(){} BUT try()catch($e){} block exists
    – John Griffiths May 16 '18 at 17:36

0 Answers0