Which PDO driver are you using?

I'm working on 1and1 server with PDO Driver for MySQL, client library version	5.1.49; locally on Mac with PDO Driver for MySQL Client API version mysqlnd 5.0.7-dev - 091210 - $Revision: 304625 $. Both environments show this issue.

I am experiencing the same issue. Tested on 5.3.5 and 5.3.10 currently.

Same issue debian wheezy, php 5.4.4-4

Hi, 

I have the same issue on 5.4.6 on Ubuntu 12.04 and PDO_MYSQL 5.5.24.

Di you have any idea where it comes from ? I had a look at the source from PDO 
and also from MySQL C API but no clue and above all too hard to find the origin.

I saw that the issue has been assigned to mysql by aharvey@php.net but I don't 
why exactly. Could you explain me ?

Antoine

I have the same issue,
php 5.4.0, pdo_mysql 5.5.19, for Win64 (x86)

issue also happened in MSSQL(PDO DBLib) on Ubuntu with PHP 5.4.14-1~precise+1

really annoying bug causing serious production hazards if we want to optimize by batching multiple queries 

is there any workaround except rewriting our database layer to mysqli or writing stored procedure on our mysql servers?

I have the same problem! In multiqueries PDO throws an error only for the first statement. And there is absolutely no difference what is going after... Please fix this problem, because it can lead to critical security holes or just hard-to-find bugs in web-applications.
I'm using PHP 5.6 and MySQL 5.6 on Windows 8 x64.

Is anyone working on this problem? As mentioned above, it can lead to dangerous bugs as there's currently no way to know if all the queries have been successfully executed or not.

As the query contains multiple result sets, what is the response if you actually take a look at the next rowset using PDOStatement::nextRowSet() in conjunction with PDOStatement::errorInfo() / PDOStatement::errorCode()?

@rquadling Genius!

Indeed, just tested it on a PDO configured to throw exceptions, and the PDOException is thrown as soon as nextRowSet() is called!

When it's configured to *not* throw exceptions, as you guessed, the error information becomes available with PDOStatement::getErrorInfo().

So there's no bug after all, the behaviour of PHP is perfectly fine, maybe we could just mention this on the PDO error handling page in the docs?

http://php.net/manual/en/pdo.error-handling.php

Thanks so much.

The test script I included in my original bug report for this issue was only a simple example. I actually had this issue with a set of SQL UPDATE statements, so showing how fetching rows and looping through result sets obviates this is not really addressing the issue. When my first update statement runs successfully I can't call nextrowset(); the statements just run one after the other. The problem with not getting error info for any following statement that may fail still stands. And I must say that I am very surprised and disappointed that noone in the php group is willing to come to grips with this - after more than 2 1/2 years!

Though it is possible to run multiple statements using `mysqli::multi_query`, with PDO it just doesn't work. For example, if you exec() a string containing multiple INSERT statements, only the first statement will be executed. No exception is thrown (PHP 5.5.17, MySQL server 5.5.38).

This is a bug. Running multiple SQL statements is useful, among other things, for creating stored procedures.

This bug still not fixed in PHP 5.6.7
Linux Fedora 21

I'm using this as workaround:

$pdo->beginTransaction();
try {
	$statement = $pdo->prepare($sql);
	$statement->execute();
	while ($statement->nextRowset()) {/* https://bugs.php.net/bug.php?id=61613 */};
	$pdo->commit();
} catch (\PDOException $e) {
	$pdo->rollBack();
	throw $e;
}

i have the same problem with php 5.5.12 on windows 7 x86

Come on, close it as bogus already.
To get an exception one have to move over resultsets, using nextRowset(), which is the proper way, not a "workaround" as someone called it.

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Since there are two statements and the first one is valid, you have to use nextRowset() and this is expected behavior.

Even if this is considered "by design", the issue should be addressed in someway.
The current situation is inconsistent and quite a lot developers stumble across it, leading to the visible feedback within this bug report.

Why is an exception thrown right away, if a single statement is executed WITHOUT accessing the result set? Why does the result set needs to be accessed when multiple queries are executed? 

imho, the implementation should 

- either never throw an exception if the result set is NOT accessed, even if it is a single query.
- or always throw an exception without accessing the result set even for multiple queries.

I don't think the current implementation is really a problem. But the documentation has to be clear about that, and the fact is, it isn't at the moment.

This bug should be reopened.

It really is a problem when you have several DELETE statements and/or UPDATE statments. It happend to me yesterday that the 3rd DELETE statment had a bug, and I could not figure out why the records where still there in my database. No exceptions where thrown.

Does using nextRowset() even work when you are using multiple DELETE statements?

just don't place multiple statements in a single query and then wonder why debug it don't work that well - it's that easy

I had to abandon using the "feature" of multiple sql statements in one query because of this.

So yes, because the feature is buggy, the "simple" solution is not to use it.

But I think it is wrong to leave this as a buggy feature that can't be really used.

As was explained years ago, this is NOT A BUG. If you execute multiple queries then you need nextRowset() to look at the results from each one. That is how it is supposed to work.