I hope i made a right choise of the version: got a latest snapshot for Win32..

I can reproduce this issue.
My suggested workaround is to use this:

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

in all your PDO MYSQL scripts.

Just tested your suggestion and this didnt help.
I have even tried running a real prepare and then excecuting a prepared statement... then closing cursor..

Didnt work either..

I reproduced the problem, and my suggestion fixed it.
I don't think you really tried it, so I'm closing this bug reporting.

Please read this:
http://netevil.org/node.php?nid=795

re-open this bug report if you're 100% sure that you're following my instructions and that it doesn't work.

I did like you said before and even tested once again. It still didn't help.
Updated the code for using emulated prepares:


$db = new PDO('mysql:localhost;dbname=pdotest', 'pdotest', 'pdotest');
$db->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_WARNING);
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

$stmt = $db->query('CALL pdotest.spIsStringComparisonCaseInsensitive()');

foreach($stmt as $row)
{
	echo $row['isInsensitive'];
}

$stmt->closeCursor();
$stmt = null;

/* Line below causing the warning */
$stmt2 = $db->query('CALL pdotest.spIsStringComparisonCaseInsensitive()');

foreach($stmt2 as $row)
{
	echo $row['isInsensitive'];
}


Code for the stored procedure is stillt he same:

CREATE PROCEDURE `spIsStringComparisonCaseInsensitive`()
BEGIN
  SELECT 'a' = 'A' AS isInsensitive;
END


Tested even with the latest snapshot for Win32.
MySQL Server version 5.0.18

Upgraded to MySQL 5.0.20a (lates release of MySQL for Windows)  Still having the same problem.

Your script outputs the following for me:

1
1

I'm running 5.0.19-standard on linux.

Okej.. humm you can try testing
http://hanna.codexp.net/test/pdo-test.php

You can see the source at http://hanna.codexp.net/test/pdo-test-source.php

Like i said: i was able to test it on windows. I will see if i will be fixed on linux..

Just upgraded to PHP 5.1.4 and got the same result on windows.
Have tested on FreeBSD (PHP 5.1.4) and it works like a charm (with ATT_EMULATE_PREPARES set to true)

So it has something to do with windows version.
On Windows still getting the exactly same results.

We build precisely the same code on windows as on unix, so it's extremely unlikely that the problem is with PDO.

Right now I suspect that the windows client libraries we link against are too old or broken.

Well it states that the the Client API version is 4.1.7 or something like that while on FreeBSD it's 5.0.21
When i replaced libmysql.dll in C:\PHP with the one distributed with MySQL server: it stated 5.0.21

However the problem has not been solved. (It was just my wild guess for the solution)
Any ideas?

I wonder if there is any solution for this on windows.
Maybe you can link to a new MySQL library, if that's the problem?

I am able to reproduce this issue on two different Windows platforms (2000 and XP). Both run PHP 5.1.4 using original client libraries (4.1.7). Same issue is encountered with the latest 5.2.0 build.

I switched back to PHP 5.1.4 and have since upgraded my client libraries (http://dev.mysql.com/downloads/connector/php/) to 5.0.22 (latest as of this writing), and now the test-code above works intermittently through the browser:

[Initial load]: 11
[Refresh]: 11
[Refresh]: 11
[Refresh]: Warning: PDO::query() [function.PDO-query]: SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server during query

The warning appears randomly; sometimes the initial load fails. Oddly, testing from the command appears to work 100%.

Given the basic circumstances that produce this issue, this is a fairly big showstopper.

I confirm the last comment - happens on PHP 5.1.4/MySQL 5.0.22. Executing another query after calling a stored procedure intermittently crashes the script.

Could you tried latest php-5.2 snapshot, which includes mysql 5.0.22 client lib bundled.

This seems to be working now just lik it should.
after removing $stmt->closeCursor() nothing has been broken.
Therefore i believe that this bug should be closed.
I am however not sure if it is me who has to close it or the developer.

Forgot to close this..

Don't close it :)
If you execute a prepared statement that returns a select * from table with more than one result row (not result set) it still crashes. It works ok if the result has only one row.
I tested it on WinXp, latest PHP 5.2 and MySQL.

Sorry for the dup post - my problem lies with executing a stored procedure and then another query (any query), not necessary another stored procedure.

hi