#32973 [Opn->Bgs]: Problem with unbuffered prep. statements

From: Date: Sun, 08 May 2005 13:01:44 +0000
Subject: #32973 [Opn->Bgs]: Problem with unbuffered prep. statements
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-78764@lists.php.net to get a copy of this message
ID: 32973 Updated by: georg@php.net Reported By: andrey@php.net -Status: Open +Status: Bogus Bug Type: MySQLi related Operating System: Linux PHP Version: 5CVS-2005-05-07 (dev) New Comment: It makes no sense to do some magic and closing unbuffered statements when executing mysql_prepare. $stmt1 = $mysql->prepare("SELECT foo FROM bar"); $stmt1->execute(); $stmt2->prepare("SELECT foo FROM user"); So why should 2nd prepare automatically clean resultset from first statement instead of giving an error ?? It's well documented that you have to either store the resultset or to close the statement before executing any other command (execept you're using cursors with MySQL 5.0). The same is also true when executing unbuffered queries in ext/mysql and ext/mysqli. Previous Comments: ------------------------------------------------------------------------ [2005-05-07 08:51:52] andrey@php.net Description: ------------ Prepare does not clean the wire before the next prepare. It should be discussed whether it should be done but this bug is created to have a track of this issue. Reproduce code: --------------- <?php $st = $db->prepare("SELECT 1 AS test"); $st->execute(); $st->bind_result($x); $st->fetch(); var_dump($x); $st = $db->prepare("SELECT 1.23 AS test"); var_dump($st); $st->execute(); $st->bind_result($x); $st->fetch(); var_dump($x); ?> Expected result: ---------------- int(1) object(mysqli_stmt)#3 (0) { } string(4) "1.23" Actual result: -------------- int(1) bool(false) PHP Fatal error: Call to a member function execute() on a non-object in /home/andrey/tst/ttt.php on line 11 ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=32973&edit=1

« previous php.bugs (#78764) next »