#47224 [Com]: MYSQL_ATTR_INIT_COMMAND is no longer available
ID: 47224
Comment by: nitel_defect at yahoo dot com
Reported By: contact at joycebabu dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows
PHP Version: 5.3.0alpha3
Assigned To: mysql
New Comment:
I subscribe, the 1002 fix does not work: Windows 7 x64, PHP 5.3.0,
MySQL 5.1.36
Previous Comments:
[2009-07-17 00:34:23] techi at techi dot name
Using 1002 instead of constant does not work either. Using 5.3.0 under
x64 Windows
[2009-07-02 10:43:36] mg at artigo dot pl
A temporary solution is to use INT value (1002) instead of constant.
[2009-06-02 12:15:28] daniz at rocketmail dot com
Looking into
/ext/pdo_mysql/pdo_mysql.c I saw this:
/* {{{ PHP_MINIT_FUNCTION
*/
static PHP_MINIT_FUNCTION(pdo_mysql)
{
#if PDO_USE_MYSQLND
REGISTER_INI_ENTRIES();
#endif
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_USE_BUFFERED_QUERY",
(long)PDO_MYSQL_ATTR_USE_BUFFERED_QUERY);
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_LOCAL_INFILE",
(long)PDO_MYSQL_ATTR_LOCAL_INFILE);
#ifndef PDO_USE_MYSQLND
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_MAX_BUFFER_SIZE",
(long)PDO_MYSQL_ATTR_MAX_BUFFER_SIZE);
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_INIT_COMMAND",
(long)PDO_MYSQL_ATTR_INIT_COMMAND);
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_READ_DEFAULT_FILE",
(long)PDO_MYSQL_ATTR_READ_DEFAULT_FILE);
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_READ_DEFAULT_GROUP",
(long)PDO_MYSQL_ATTR_READ_DEFAULT_GROUP);
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_COMPRESS",
(long)PDO_MYSQL_ATTR_COMPRESS);
#endif
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_DIRECT_QUERY",
(long)PDO_MYSQL_ATTR_DIRECT_QUERY);
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_FOUND_ROWS",
(long)PDO_MYSQL_ATTR_FOUND_ROWS);
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_IGNORE_SPACE",
(long)PDO_MYSQL_ATTR_IGNORE_SPACE);
#ifdef PDO_USE_MYSQLND
pdo_mysqlnd_zval_cache =
mysqlnd_palloc_init_cache(PDO_MYSQL_G(cache_size));
#endif
return php_pdo_register_driver(&pdo_mysql_driver);
}
Meaning in short:
if not defined "PDO_USE_MYSQLND" -
REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_INIT_COMMAND",
(long)PDO_MYSQL_ATTR_INIT_COMMAND);
else don't register that class? Does it's supposed to come from
somewhere else? I just moved the init_command into a simple query("SET
NAMES utf8"); to get rid of the error.
[2009-05-22 04:06:55] christian dot gahlert at web dot de
Hi,
I just had the same problem. It occured because I installed the PDO
extension via pecl but forgot to also install PDO_MYSQL.
After I installed the PDO_MYSQL everything was fine.
I hope I could save someone some time :)
Chris
[2009-04-25 15:35:53] j...@php.net
For some reason this (and some other) constants are only available when
mysqlnd driver is used.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/47224
--
Edit this bug report at http://bugs.php.net/?id=47224&edit=1
#41997 [Opn]: Stored procedure call that returns a single rowset blocks future queries
ID: 41997
User updated by: nitel_defect at yahoo dot com
Reported By: nitel_defect at yahoo dot com
Status: Open
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
http://www.kpsol.ro/php_pdo_mysql.dll
Previous Comments:
[2007-07-16 17:30:00] temposeb at free dot fr
I encounter exactly the same bug for many months.
Environment : Win2000 Pro SP4, Apache 2.2, PHP 5.2.4-dev (Build Date
Jul 11 2007 20:03:23), MySQL 5.1.20-beta-community-nt-debug (same thing
with MySQL 5.0.x).
nitel_defect, where can we find the hacked DLL ?
http://source.hackthissite.org/svn/trunk/PDO/php_pdo_mysql.dll is
actually DOWN. Thx.
[2007-07-15 06:53:01] nitel_defect at yahoo dot com
Description:
The code below calls a stored procedure that fethches the whole tree in
a father-son system roles hierarchy.
In the end, the stored procedure selects everything from a temp table,
so that's our result set.
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY is on by default.
After running the call statement, all the result rows are returned
correctly but any future query (not only other calls, all queries) fail
with the message you see below.
For the time being I replicated the code I needed in PHP, but it's
frustrating not to be able to run SPs...
I tested the library found here:
http://source.hackthissite.org/svn/trunk/PDO/php_pdo_mysql.dll
and this bug was gone. But there is no source code for this modified
library and its size is much smaller so I don't quite trust it.
Uhm... help?
Reproduce code:
---
query("call getParentRoles('admin')");
do {
$rows = $st->fetchAll(PDO::FETCH_ASSOC);
} while ($st->nextRowset());
$st->closeCursor();
var_dump($db->errorInfo());
echo '';
$st = $db->query("SELECT * FROM user");
var_dump($db->errorInfo());
Expected result:
array(1) { [0]=> string(5) "0" }
array(1) { [0]=> string(5) "0" }
Actual result:
--
array(1) { [0]=> string(5) "0" }
array(3) { [0]=> string(5) "HY000" [1]=> int(2014) [2]=> string(269)
"Cannot execute queries while other unbuffered queries are active.
Consider using PDOStatement::fetchAll(). Alternatively, if your code is
only ever going to run against mysql, you may enable query buffering by
setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute." }
--
Edit this bug report at http://bugs.php.net/?id=41997&edit=1
#41997 [NEW]: Stored procedure call that returns a single rowset blocks future queries
From: nitel_defect at yahoo dot com
Operating system: Windows XP SP2
PHP version: 5.2.3
PHP Bug Type: PDO related
Bug description: Stored procedure call that returns a single rowset blocks
future queries
Description:
The code below calls a stored procedure that fethches the whole tree in a
father-son system roles hierarchy.
In the end, the stored procedure selects everything from a temp table, so
that's our result set.
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY is on by default.
After running the call statement, all the result rows are returned
correctly but any future query (not only other calls, all queries) fail
with the message you see below.
For the time being I replicated the code I needed in PHP, but it's
frustrating not to be able to run SPs...
I tested the library found here:
http://source.hackthissite.org/svn/trunk/PDO/php_pdo_mysql.dll
and this bug was gone. But there is no source code for this modified
library and its size is much smaller so I don't quite trust it.
Uhm... help?
Reproduce code:
---
query("call getParentRoles('admin')");
do {
$rows = $st->fetchAll(PDO::FETCH_ASSOC);
} while ($st->nextRowset());
$st->closeCursor();
var_dump($db->errorInfo());
echo '';
$st = $db->query("SELECT * FROM user");
var_dump($db->errorInfo());
Expected result:
array(1) { [0]=> string(5) "0" }
array(1) { [0]=> string(5) "0" }
Actual result:
--
array(1) { [0]=> string(5) "0" }
array(3) { [0]=> string(5) "HY000" [1]=> int(2014) [2]=> string(269)
"Cannot execute queries while other unbuffered queries are active. Consider
using PDOStatement::fetchAll(). Alternatively, if your code is only ever
going to run against mysql, you may enable query buffering by setting the
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute." }
--
Edit bug report at http://bugs.php.net/?id=41997&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41997&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41997&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41997&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41997&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41997&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41997&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41997&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41997&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41997&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41997&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41997&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41997&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41997&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41997&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41997&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41997&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41997&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41997&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41997&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41997&r=mysqlcfg
#39858 [Com]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
Comment by: nitel_defect at yahoo dot com
Reported By: develar at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
Assigned To: wez
New Comment:
What's the status of this bug?
I mean the part about any query ran after a fetchAll from a stored
procedure call, saying that there are still unfetched results. And that
happens even with a nextRowset call :)
The bug still exists in the last library from snaps, on Windows.
Previous Comments:
[2007-07-10 13:38:46] matt dot keeble at gmail dot com
As an update to this, I'm not sure that this is a bug in PHP at all - I
believe it's a bug with MySQL. Have stumbled across this bug report
today after receiving MySQL lost connections from the MySQL command
line, and from Navicat Terminal - in both cases there was no PHP
involved at all, just an SP that calls a function in a loop which
subsequently calls another function. The SP returns the first row, but
then dies with the error message and goes into an irretrievable loop (in
Navicat).
Don't know if this will help, but thought I would share...
[2007-06-21 12:58:38] timo at hhesse dot de
Well, this is very disappointing. A new PHP version is out and this
stupid bug has not been fixed although a solution seems to be found by
mike at we11er dot co dot uk.
I can't use PHP5 without this hacked dll on our servers. Seems like no
one feels responsible for developers on windows servers.
"There's no bug on linux so what are you talking about...?"
[2007-05-18 21:12:31] paulsidekick at gmail dot com
I am still not able to issue two stored procedures in a row using PDO
and mysql 5.0.31, php 5.2.1 and windows server 2003 when using the php
pdo_mysql.dll extension. Is there any fix for this planned? It has
been a very long time since it was first noted. If there is a solution
other than using a hacked DLL with no source code, can somebody please
advice. This is the simplest way to see it happen.
$stmt = $myPdoConnection->query("CALL myStoredProc ('x', 'y')");
//this returns results
print_r($stmt->fetchAll());
//this does not - says mysql lost connection
print_r($stmt->fetchAll());
If I do this with SELECT statements instead I get no problem. I
believe that there is an additional row set send back with stored
procedures from mysql that needs to be interated over in order to issue
the next statement. However, I cannot access them with
$stmt->nextRowset();
as I get "Warning: PDOStatement::nextRowset()
[function.PDOStatement-nextRowset]: SQLSTATE[HYC00]: Optional feature
not implemented in "
Please help.
[2007-04-09 19:13:53] jaylehvee at srgtampa dot com
I am using this modified DLL, above, and it works great, in most
regards. The core issue still exists, however. Mulitple calls to stored
procedures are still causing db connection loss. I've had to go
lazy-load kuh-ray-zee on my objects to avoid connection failures. I
shouldn't have to use the wrong patterns in order to work around a
faulty db driver.
Mike, any chance you can post your hacked source somewhere?
[2007-03-26 19:57:43] timo at hhesse dot de
Hi mike, thanks for the fixed php_pdo_mysql.dll! I tested it right now
and it works perfectly!
It took me quite the whole day finding out that it was a php bug what
made my stored procedures producing those exceptions (on Windows IIS).
But now I'm asking myself if your fix will find its way into the next
PHP release so that I can be sure my code will work at my customers
Windows servers too or if I should use some script language that
supports stored procedures as they are meant...
A reliable answer in this issue would be great! ;-)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/39858
--
Edit this bug report at http://bugs.php.net/?id=39858&edit=1
