php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35793 General error: 2050
Submitted: 2005-12-24 03:15 UTC Modified: 2006-05-07 01:00 UTC
Votes:78
Avg. Score:4.4 ± 0.9
Reproduced:69 of 69 (100.0%)
Same Version:24 (34.8%)
Same OS:16 (23.2%)
From: deadman_great at mail dot ru Assigned: Wez (profile)
Status: No Feedback Package: PDO related
PHP Version: 5CVS-2005-12-25 (snap) OS: RH Fedora Core 2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
13 + 48 = ?
Subscribe to this entry?

 
 [2005-12-24 03:15 UTC] deadman_great at mail dot ru
Description:
------------
Current script works fine on localhost (winxp), and throw errors on remote server (rh-fedora).

Software:
Local: winxp-sp2,php-5.1.1,mysql-5.0.3
Remote: fedora-c2,php-5.1.1,mysql-5.0.9

Reproduce code:
---------------
$query = 'SELECT `created`, to_days(from_unixtime(`created`)) as `day`,count(`id`) as `count` FROM `orders` WHERE `partner`=:partner AND `created`>=:date GROUP BY `day`';

$vars = array(':partner'=>9,':date'=>1132797644);

$stm = $pdo->Prepare($query);
$result = $stm->Execute($vars);
foreach ($result as $day) // LINE-123
{
...
}

Expected result:
----------------
Rows.

Actual result:
--------------
Warning: main() [function.main]: SQLSTATE[HY000]: General error: 2050 in ... on line 123

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-12-24 18:30 UTC] deadman_great at mail dot ru
OK, without OO:

<?

$pdo = new PDO('mysql:host=localhost;dbname=mydb','login','pass');
$pdo->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_WARNING);
	
function Query ()
{
	global $pdo;

	$query = 'SELECT `created`, to_days(from_unixtime(`created`)) as `day`,count(`id`) as `count` '.
	'FROM `orders` '.
	'WHERE `partner`=:partner '.
	'AND `created`>=:date '.
	'GROUP BY `day`';

	$vars = array(':partner'=>9,':date'=>1132797644);

	$stm = $pdo->Prepare($query);
	$stm->Execute($vars);
	return $stm;
}

$result = Query();
foreach ($result as $day)
{
	print_r($day); echo '<hr>';
}

$result = Query();
foreach ($result as $day)
{
	print_r($day); echo '<hr>';
}

$result = Query();
foreach ($result as $day)
{
	print_r($day); echo '<hr>';
}


?>

SQL:

CREATE TABLE `orders` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `state` tinyint(3) unsigned NOT NULL default '0',
  `partner` int(10) unsigned NOT NULL,
  `created` int(10) unsigned NOT NULL default '0',
  `completed` int(10) unsigned default NULL,
  `count` tinyint(3) unsigned NOT NULL,
  `cost` float(11,2) unsigned NOT NULL default '0.00',
  `zip` int(10) unsigned default NULL,
  `region` varchar(80) default NULL,
  `city` varchar(120) default NULL,
  `street` varchar(255) default NULL,
  `house` varchar(32) default NULL,
  `building` varchar(32) default NULL,
  `apartment` varchar(32) default NULL,
  `name` varchar(255) default NULL,
  `surname` varchar(255) default NULL,
  `patronymic` varchar(255) default NULL,
  `mail` varchar(120) default NULL,
  `comments` text,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

INSERT INTO `orders` VALUES (1,0,9,1134531133,1134931138,2,20,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO `orders` VALUES (2,4,9,1134911133,1134911139,1,10,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO `orders` VALUES (3,1,9,1134811133,1134811137,4,40,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO `orders` VALUES (4,3,9,1134711133,1134711533,1,10,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO `orders` VALUES (5,4,9,1134511131,1134511138,1,10,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO `orders` VALUES (6,1,0,1135521534,NULL,1,10,121231,'test','test','test','12',NULL,NULL,'test','test','test','one@test.com',NULL);
INSERT INTO `orders` VALUES (7,0,9,1134522614,NULL,1,10,354354,'test2','test2','test2','12',NULL,NULL,'test2','test2','test2','two@test.com',NULL);
 [2005-12-25 17:37 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip


 [2005-12-25 19:21 UTC] deadman_great at mail dot ru
Tried php5.1-200512251730, - same result.
 [2005-12-26 23:22 UTC] wez@php.net
Almost certainly a mysql bug.  Check in with the mysql bug database.
 [2005-12-27 11:29 UTC] deadman_great at mail dot ru
Installed latest mysql (v5.0.17). Same error.
 [2005-12-27 14:52 UTC] wez@php.net
Try it with mysql 4.x.
If it works fine there, it's a mysql 5 problem that should be reported to the mysql folks.
 [2005-12-27 15:55 UTC] deadman_great at mail dot ru
I think that mysql developers say "It's a PDO problem" :-)

Maybe this will be helpful for you. I place var_dump() for PDOStatement:

$stm = $this->pdo->Prepare($query);
$stm->Execute($vars);
var_dump($stm);

Working scripts:
object(PDOStatement)#4 (1)
object(PDOStatement)#10 (1)
object(PDOStatement)#10 (1)
object(PDOStatement)#10 (1)
object(PDOStatement)#10 (1)
...

Non working:
object(PDOStatement)#4 (1)
object(PDOStatement)#10 (1)
object(PDOStatement)#10 (1)
object(PDOStatement)#11 (1) // 1st #2050 error
object(PDOStatement)#10 (1) // 2nd #2050 error
object(PDOStatement)#12 (1) // 3rd #2050 error
object(PDOStatement)#12 (1) // error #2053
object(PDOStatement)#12 (1) // error #2053
...  // error #2053

PS: Before each error #2053: 
Warning: PDOStatement::execute() [function.execute]: SQLSTATE[HY093]: Invalid parameter number: parameter was not defined
 [2005-12-28 11:48 UTC] sniper@php.net
Assigning to the MySQL folks.
 [2006-01-24 11:04 UTC] georg@php.net
This is not a mysql bug:

mysql_stmt_fetch returns 1 (error). (Error message "Row retrieval was canceled by mysql_stmt_close() call")

So pdo called mysql_stmt_close before (I assume prepare/bind/execute failed before)
 [2006-02-14 16:06 UTC] m at tacker dot org
I can reproduce this bug on two machines (athlon-xp and pentium3) with 

PHP 5.1.1-gentoo (cli) (built: Feb 10 2006 18:06:50)
Zend Engine v2.1.0

This is the test case:

<?php

    /**
    * Test case for bug #35793
    * @see http://bugs.php.net/bug.php?id=35793
    *
    * @author Markus Tacker <m@tacker.org>
    * @version $Id: pdo-proxy-bug.php 760 2006-02-14 14:59:19Z mtacker $
    */

    // If you set this to true I will reconnect before each select
    // at line 56
    // => no crash
    $reconnect_before_select = false;

    error_reporting(E_ALL|E_STRICT);
    ini_set('display_errors', 1);

    $dsn = array(
        'dbtype' => 'mysql',
        'host' => 'localhost',
        'database' => 'test',
        'username' => 'test',
        'password' => '',
    );

    // $DB = new Database;
    $DB = new PDO($dsn['dbtype'] . ':host=' . $dsn['host'] . ';dbname=' . $dsn['database'], $dsn['username'], $dsn['password']);

    $table = uniqid();

    // Create a test table
    $sql = 'CREATE TABLE `' . $table . '` ('
    . "varname varchar(64) NOT NULL default '',"
    . "varvalue tinytext NOT NULL default '',"
    . 'PRIMARY KEY (varname)'
    . ') ENGINE=InnoDB DEFAULT CHARSET=utf8';
    $result = $DB->exec($sql);
    if ($result === false and $result->errorCode() != PDO::ERR_NONE) {
        exit('Query failed: ' . $sql . "\n");
    }
    echo 'OK: ' . $sql . "\n";

    // Insert into test table
    $sql = 'INSERT INTO `' . $table . '`'
    . ' (varname, varvalue)'
    . ' VALUES (' . $DB->quote('uniqid') . ', ' . $DB->quote($table) . ')';
    $result = $DB->exec($sql);
    if ($result === false and $result->errorCode() != PDO::ERR_NONE) {
        exit('Query failed: ' . $sql . "\n");
    }
    echo 'OK: ' . $sql . "\n";

    // Select from table
    for ($i = 0; $i < 10; $i++) {
        if ($reconnect_before_select) {
            unset($DB);
            $DB = new PDO($dsn['dbtype'] . ':host=' . $dsn['host'] . ';dbname=' . $dsn['database'], $dsn['username'], $dsn['password']);
        }
        $sql = 'SELECT * FROM `' . $table . '` LIMIT 1';
        $result = $DB->query($sql);
        if ($result === false or $result->errorCode() != PDO::ERR_NONE) {
            exit('Query failed: ' . $sql . "\n");
        }
        echo 'OK: ' . $sql . "\n";
        $row = $result->fetchObject();
        // $row = $result->fetch();
        // $row = $result->fetchAll();
        if ($row === false or $result->errorCode() != PDO::ERR_NONE) {
            $info = $result->errorInfo();
            exit('Fetch failed: ' . $info[2] . ' (' . $info[0] . '/' . $info[1] . ')' . "\n");
        }
        echo 'OK: ' . $table . ' == ' . $row->varvalue . "\n";
        $result->closeCursor();
    }

    // Delete temp table
    $DB->exec('DROP TABLE `' . $table . '`');

?>
 [2006-03-11 10:42 UTC] peres dot yzqk8 at mailnull dot com
I'd got same problem with this piece of code:

$s = $db->query("SELECT * FROM test ORDER BY poledrugie;");
var_dump($s->fetchAll());
$s = $db->query("SELECT * FROM test ORDER BY poletrzecie;");
var_dump($s->fetchAll());

Changed it to:

$s = $db->query("SELECT * FROM test ORDER BY poledrugie;");
var_dump($s->fetchAll());
$st = $db->query("SELECT * FROM test ORDER BY poletrzecie;");
var_dump($st->fetchAll());

So I think it's wrong use of PHP objects...
 [2006-03-18 22:09 UTC] gg15 at gmx dot net
$result = $db->query('SELECT COUNT(*) FROM XYZ');
$row = $result->fetch(PDO::FETCH_ASSOC);
$result->closeCursor();

$result = $db->query('SELECT * FROM XYZ');
$row = $result->fetch(PDO::FETCH_ASSOC); // this one throws the error

an $result = null; between the statements fixes the issue, so I think this is a problem of php...
 [2006-03-21 18:37 UTC] email at steffenweber dot net
I can confirm that this error does not occur on Windows XP + PHP 5.1.2 + MySQL 5.0.18. It does happen for me on Gentoo Linux + PHP 5.1.2 + MySQL 4.1.16.

You cannot use the same variable for a PDOStatement object twice. As others have pointed out it works when you set this variable to null in between.
 [2006-03-23 00:25 UTC] qlogix at gmail dot com
I can confirm the statement on Centos 4.1, PHP 5.1.2, Mysql 4.1.16

"You cannot use the same variable for a PDOStatement object twice. As others have pointed out it works when you set this variable to null in between."

<?php
$db = new PDO(SQL_DSN,SQL_USER,SQL_PASSWORD);	
$db->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);	
$result = $db->query('SELECT COUNT(*) FROM Locations');
echo $result."<br>";
$row = $result->fetchAll(PDO::FETCH_ASSOC);	
/* Comment the next line out and script returns an error */
//$result = null;	
$result = $db->query('SELECT COUNT(*) FROM Accounts');
echo $result."<br>";
$row = $result->fetch(PDO::FETCH_ASSOC); /* This line causes the error */
?>


With line "$result = null;" commented out:
Object id #2
Object id #3
PDOException Object
(
    [message:protected] => SQLSTATE[HY000]: General error: 2050 

With line "$result = null;" not commented out:
Object id #2
Object id #2

No error message (script works)
 [2006-04-09 07:39 UTC] wez@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip

Try the next snapshot dated after this message.
 [2006-04-09 15:31 UTC] email at steffenweber dot net
I?ve tried php5.1-200604091430.tar.bz2 and the error is still there.
 [2006-04-17 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2006-04-17 16:56 UTC] email at steffenweber dot net
You must be kidding? :-(
 [2006-04-17 17:04 UTC] mike@php.net
You need to change the bug status back to "Open" if the issue still occurs. The bug has been suspended by a cron script because it was still in state "Feedback".

I re-opened the bug for you.
 [2006-04-30 00:56 UTC] wez@php.net
Please read this blog entry and see if following the advice there helps:
http://netevil.org/node.php?nid=795
(you'll want to upgrade to PHP 5.1.3 or a current snapshot first).
 [2006-05-02 14:53 UTC] email at steffenweber dot net
Upgrading to PHP 5.1.3 and using $db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true); fixes the problem for me.
 [2006-05-07 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2006-08-01 20:52 UTC] mass at carlsoft dot net
Can we at least change this error message to be more specific, perhaps suggesting to emulate prepares (as wez @ php . net suggested)? or better yet make the emulation default?
 [2006-08-23 11:14 UTC] tjerk dot meesters at gmail dot com
This problem still occurs with:
PHP-5.1.5
MySQL-5.0.22
Linux platform

Using PDO::ATTR_EMULATE_PREPARES doesn't resolve the problem, the error message remains:

SQLSTATE[HY000]: General error: 2050 Row retrieval was canceled by mysql_stmt_close() call
 [2006-10-16 14:46 UTC] andiesPostfach at web dot de
The Problem still exists in PHP 5.2 RC5 !!

System ist SUSE-Linux 9.3
MySQL Version 5.0.18
 [2006-10-17 01:15 UTC] michal dot vrchota at seznam dot cz
I think I have solved this problem:

You have to free your PDOStatement instance

Of course You have to call closeCursor() method to be sure, but if you have more queries and still using same identifier ($stmt) you have free it by passing NULL value

Sample:
$stmt->closeCursor();
$stmt = NULL;

// now it works ;)
 [2006-11-01 15:11 UTC] richard at phase dot org
$this->pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

(a suggested fix above) fails on 5.2.RC6 as PDO::ATTR_EMULATE_PREPARES appears no longer to be defined.
 [2006-11-03 08:53 UTC] arnaud dot lb at gmail dot com
I have the same problem with php-5.2, mysql-5.0.26 on 
Debian system.

Fixed the problem using the 
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY option.

It seems that closeCursor() does not works properly.
 [2006-12-28 01:22 UTC] dennis at inmarket dot lviv dot ua
Remember to have these "fixes" in your code on every connection you might have to the same database.
 [2008-03-19 16:40 UTC] ob dot php at daevel dot fr
This bug/problem is not solved with PHP 5.2.0 under Debian stable (etch).

Full code :
<?php
$db = new pdo( 'mysql:host=localhost;dbname=admin', 'administration', 'XXX' );
$db->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING );

if( ( $res = $db->query( 'select id from user_group' ) ) !== false )
{
	print_r( $res->fetchAll() );
}

if( ( $res = $db->query( 'select description from user_group' ) ) !== false )
{
	print_r( $res->fetchAll() );
}
?>

And result for the second query :
Warning: PDOStatement::fetchAll(): SQLSTATE[HY000]: General error: 2050  in /home/dev-olivier/toutgagner.admin/test.php on line 14
Array
(
)

Won't it be fixed ?
 [2008-08-19 16:06 UTC] baptiste dot place at utopiaweb dot fr
Got the same error with second statement of a function.
Worked fine on winXP xampp, PHP 5.2.6, MySql 5.0.51b.

Deployed on a debian server with PHP 5.2.0-8 and MySQL 5.0.32, the code threw this error.

Made it work with michal vrchota's solution, thanks a lot.
 [2008-10-21 06:20 UTC] vishalraj82 at gmail dot com
I guess this is a problem with pdo.
When you connect to localhost using pdo, fire a query and store the result in variable, the variable needs to be reset before it can be reused, given that mysql resids on a remote server and not on localhost.

$conn = new PDO("localhost"....
$sql1 = "SELECT * from TEST";
$res = $conn->query($sql1);
...
...


$sql2 = "SELECT * from MYTAB";
$res = $conn->query($sql2); // In this line you will get mysql general error if $res has not been reset before being used again
 [2008-10-30 05:35 UTC] post-christian at freenet dot de
I think we need to rethink about how mysql works. If you don't use mysql_stmt_store_result(), which make sense when loading long data, mysql seems to allow only one active statement per connection. puhh. hard to believe but could be true. I'm having the same problem with a mysql driver for perl.
 [2009-03-26 15:00 UTC] maxlemans at free dot fr
The problem seems to be still unsolved. I reproduced it today when using the statement variable twice or more for different queries

Code :

// Request writting
$strSQL = " 
SELECT  id
FROM    mybase.mytable
";

// Request running 
$objStatement = $oPDO->query($strSQL);

// Results browsing
while ($arrRow = $objStatement->fetch(PDO::FETCH_NUM))
{
        array_push($arrData, $arrRow[0]);
}

// Cursor closing
$objStatement->closeCursor();


// Request writting
$strSQL = " 
SELECT  id
FROM    mybase.myOTHERtable
";

// Request running 
$objStatement = $oPDO->query($strSQL);

// Results browsing
while ($arrRow = $objStatement->fetch(PDO::FETCH_NUM))
{
        array_push($arrData, $arrRow[0]);
}

// Cursor closing
$objStatement->closeCursor();


To solve this problem I use the following after $objStatement->closeCursor() :

unset($objStatement);

As $objStatement is affected an new PDOStatement instance, I think it would be nice if PHP could remove the previous PDOStatement instance as it is no longer usable.
 [2009-04-29 17:15 UTC] brice dot laurencin at gmail dot com
I ran against the very bug just now. I lost half a day with a bug referenced 3 years and a half ago. Nice.
And more, just a simple affectation ain't possible? What?!?

I hate PHP more and more every day.

/rant OFF

The bug didn't occurred on Ubuntu Jaunty (PHP 5.2.6), it smashed me on the Red Hat 4.1.1-52 (PHP 5.1.6) production server.
 [2009-07-04 07:57 UTC] ben at ecoland dot com dot au
This needs to be fixed - C'mon guys.

I'm using PHP under CentOS 5.0 and shocked it exists
 [2011-04-27 18:30 UTC] danizobin at gmail dot com
On WinXP no problem, on CentOs I see the bug
 [2015-04-29 01:38 UTC] jefrey at jefrey dot ml
It's 2015 and I'm still facing this bug...
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 13:01:29 2024 UTC