#33416 [NEW]: PHP doesn't like functions named getAll
From: shadda at gmail dot com Operating system: Windows XP SP2 PHP version: 5.0.4 PHP Bug Type: Class/Object related Bug description: PHP doesn't like functions named getAll Description: While writing a small abstraction layer for my application, I noticed that a variable was not being set to the return value of a class method. After several tests I was able to determine without a doubt that this error was being caused merely by the name of the class method. As shown here, http://mycrap.tradedaemon.com/bugs/test2.php In the above url, I've named the method getAlls(). Notice the populated array at the bottom. http://mycrap.tradedaemon.com/bugs/test1.php In the next example, i've named it back to getAll(). Notice the LACK of a populated array at the bottom. I've spent the last hour and a half writing other examples to make sure I wasn't missing something, but sure enough, php does not like methods named getAll(). -- Edit bug report at http://bugs.php.net/?id=33416&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33416&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33416&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33416&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33416&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33416&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33416&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33416&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33416&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33416&r=support Expected behavior: http://bugs.php.net/fix.php?id=33416&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33416&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33416&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33416&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33416&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33416&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33416&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33416&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33416&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33416&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33416&r=mysqlcfg
#33416 [Opn]: PHP doesn't like functions named getAll
ID: 33416 User updated by: shadda at gmail dot com Reported By: shadda at gmail dot com Status: Open Bug Type: Class/Object related Operating System: Windows XP SP2 PHP Version: 5.0.4 New Comment: Also, I've done a thorough search of my code to check for a lose method that may have been overriding it. No such luck. For now I guess I'll just rename it. (Though I'm still skeptical it's not just me doing something retarded) Previous Comments: [2005-06-21 05:47:12] shadda at gmail dot com Description: While writing a small abstraction layer for my application, I noticed that a variable was not being set to the return value of a class method. After several tests I was able to determine without a doubt that this error was being caused merely by the name of the class method. As shown here, http://mycrap.tradedaemon.com/bugs/test2.php In the above url, I've named the method getAlls(). Notice the populated array at the bottom. http://mycrap.tradedaemon.com/bugs/test1.php In the next example, i've named it back to getAll(). Notice the LACK of a populated array at the bottom. I've spent the last hour and a half writing other examples to make sure I wasn't missing something, but sure enough, php does not like methods named getAll(). -- Edit this bug report at http://bugs.php.net/?id=33416&edit=1
#31524 [NEW]: Can't Compile --with-imap
From: shadda at gmail dot com Operating system: Knoppix Debian (Linux) PHP version: 5.0.3 PHP Bug Type: IMAP related Bug description: Can't Compile --with-imap Description: I have tried this in multiple versions of php5, including several snapshots. I've also done so with different IMAP C-Client versions, also with different snapshots. I've compiled the C-Client and placed it in correct locations, as well as setup the actuall IMAP and POP3 server on my system. IMAP *.c files located in /usr/local/imap-2004b/lib/ IMAP *.h files located in /usr/local/imap-2004b/include/ The c-client.a and libc-client.a files are also in lib/, (I have also tried using symlinks instead of actuall copy when creating libc-client.a, but that didn't work either) I trimmed my ./configure line down, and narrowed the problem specifically to imap. I can compile with any other extension of my choosing but this one. ./configure --with-apxs2=/var/www/bin/apxs --with-imap=/usr/local/imap-2004b Results in a configure error that tells me to check the config.log file. I do so, and I see that the failed operation was #include confdefs.h confdefs.h is part of the package i'm installing (PHP5) and i cannot see it not being found, just because i'm compiling --with-imap. I consulted several debian forums and IRC channels, as well as EFNet #PHP, and no one was able to solve this problem. I also did a thorough search of google and bugs.php.net but found nothing similar to this problem. I have recompiled IMAP four times now, but it still does it. When running ./configure statement, it runs fine until i -- Edit bug report at http://bugs.php.net/?id=31524&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31524&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31524&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31524&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31524&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31524&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31524&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31524&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31524&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31524&r=support Expected behavior: http://bugs.php.net/fix.php?id=31524&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31524&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31524&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31524&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31524&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31524&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31524&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31524&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31524&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31524&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31524&r=mysqlcfg
#31524 [Opn]: Can't Compile --with-imap
ID: 31524 User updated by: shadda at gmail dot com Reported By: shadda at gmail dot com Status: Open Bug Type: IMAP related Operating System: Knoppix Debian (Linux) PHP Version: 5.0.3 New Comment: err Okay, bug report was trimmed for some reason (?) It runs fine until it gets to Checking Whether IMAP Support Works.no then sprouts the error, and tells me to check the log. I will paste the log here if need be. Thanks. Previous Comments: [2005-01-13 00:29:16] shadda at gmail dot com Description: I have tried this in multiple versions of php5, including several snapshots. I've also done so with different IMAP C-Client versions, also with different snapshots. I've compiled the C-Client and placed it in correct locations, as well as setup the actuall IMAP and POP3 server on my system. IMAP *.c files located in /usr/local/imap-2004b/lib/ IMAP *.h files located in /usr/local/imap-2004b/include/ The c-client.a and libc-client.a files are also in lib/, (I have also tried using symlinks instead of actuall copy when creating libc-client.a, but that didn't work either) I trimmed my ./configure line down, and narrowed the problem specifically to imap. I can compile with any other extension of my choosing but this one. ./configure --with-apxs2=/var/www/bin/apxs --with-imap=/usr/local/imap-2004b Results in a configure error that tells me to check the config.log file. I do so, and I see that the failed operation was #include confdefs.h confdefs.h is part of the package i'm installing (PHP5) and i cannot see it not being found, just because i'm compiling --with-imap. I consulted several debian forums and IRC channels, as well as EFNet #PHP, and no one was able to solve this problem. I also did a thorough search of google and bugs.php.net but found nothing similar to this problem. I have recompiled IMAP four times now, but it still does it. When running ./configure statement, it runs fine until i -- Edit this bug report at http://bugs.php.net/?id=31524&edit=1
#31524 [Fbk->Opn]: Can't Compile --with-imap
ID: 31524 User updated by: shadda at gmail dot com Reported By: shadda at gmail dot com -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: Knoppix Debian (Linux) PHP Version: 5.0.3 New Comment: UPDATE: Okay, it seems that IMAP-2004b was compiling with OpenSSL support *even after telling it explicitly not to* and that was the reason why it would not compile. Still at a loss why it was reporting problems with confdefs.h, but i guess this falls under "C-Client" bugs. Thanks for your time, I have it working now. Previous Comments: [2005-01-13 08:11:41] [EMAIL PROTECTED] Please put that log somewhere online and provide a link... it's too large to be pasted here. [2005-01-13 00:35:15] shadda at gmail dot com err Okay, bug report was trimmed for some reason (?) It runs fine until it gets to Checking Whether IMAP Support Works.no then sprouts the error, and tells me to check the log. I will paste the log here if need be. Thanks. [2005-01-13 00:29:16] shadda at gmail dot com Description: I have tried this in multiple versions of php5, including several snapshots. I've also done so with different IMAP C-Client versions, also with different snapshots. I've compiled the C-Client and placed it in correct locations, as well as setup the actuall IMAP and POP3 server on my system. IMAP *.c files located in /usr/local/imap-2004b/lib/ IMAP *.h files located in /usr/local/imap-2004b/include/ The c-client.a and libc-client.a files are also in lib/, (I have also tried using symlinks instead of actuall copy when creating libc-client.a, but that didn't work either) I trimmed my ./configure line down, and narrowed the problem specifically to imap. I can compile with any other extension of my choosing but this one. ./configure --with-apxs2=/var/www/bin/apxs --with-imap=/usr/local/imap-2004b Results in a configure error that tells me to check the config.log file. I do so, and I see that the failed operation was #include confdefs.h confdefs.h is part of the package i'm installing (PHP5) and i cannot see it not being found, just because i'm compiling --with-imap. I consulted several debian forums and IRC channels, as well as EFNet #PHP, and no one was able to solve this problem. I also did a thorough search of google and bugs.php.net but found nothing similar to this problem. I have recompiled IMAP four times now, but it still does it. When running ./configure statement, it runs fine until i -- Edit this bug report at http://bugs.php.net/?id=31524&edit=1
#31949 [NEW]: PHP5.0.3 Does not install with jpeg support
From: shadda at gmail dot com Operating system: Debian Linux PHP version: 5.0.3 PHP Bug Type: GD related Bug description: PHP5.0.3 Does not install with jpeg support Description: Hello. On a clean install of my debian system, I attempted to install php5.0.3. Here is my configuration line: ./configure --with-apxs2=/var/www/bin/apxs --with-mysql --with-gd --with-zlib --with-zlib-dir=/usr/include/zlib.h --with-libxml=/usr/local/bin --with-imap=/usr/bin/imap --with-imap-ssl=/usr --with-curl=/home/shadda/curl-7.13.0 --enable-exif --with-jpeg-dir=/home/shadda/php-5.0.3/jpeg-6b My --with-jpeg-dir line has changed many times while tracking this bug, but the interesting thing is that it never once failed. Checking my config.log *and* my makefile logs with a fine tooth comb told me that it was in fact attempting to compile with jpeg support, and could find no point at which this was failing. But after every make, make install, (and yes, I restarted/stop/started apache many, many times) I would discover in phpinfo(), that although the configure line at the top reflected any changes i had just made, JPG Support was not enabled, or even visible on the page (And of course, no JPEG functions would work, either). I spent the better part of a day looking for ways around this. I deleted the config.cache file prior to configuring, and a large amount of other more obscure workarounds but just could *not* get it to go. Even after installing a snapshot i had on hand, it would not work. I searched around bugs.php.net thoroughly but have not found a bug report related this this. I went back and got another snapshot release of 5.0.3, snapshot release php5-200502130130. I ran that same configure line from above, make, make install, restarted apache, and now i have JPG support. I've solved it on my system, but felt I should report this nevertheless. Thankyou. -- Edit bug report at http://bugs.php.net/?id=31949&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31949&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31949&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31949&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31949&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31949&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31949&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31949&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31949&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31949&r=support Expected behavior: http://bugs.php.net/fix.php?id=31949&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31949&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31949&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31949&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31949&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31949&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31949&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31949&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31949&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31949&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31949&r=mysqlcfg
#31949 [Com]: PHP5.0.3 Does not install with jpeg support
ID: 31949 Comment by: Shadda at gmail dot com Reported By: shadda at gmail dot com Status: Open Bug Type: GD related Operating System: Debian Linux PHP Version: 5.0.3 New Comment: And yes, I realize I submitted a bug report on a problem that's already been fixed. My reasoning is that since there were no prior reports it was worth mentioning. Previous Comments: [2005-02-13 04:46:48] shadda at gmail dot com Description: Hello. On a clean install of my debian system, I attempted to install php5.0.3. Here is my configuration line: ./configure --with-apxs2=/var/www/bin/apxs --with-mysql --with-gd --with-zlib --with-zlib-dir=/usr/include/zlib.h --with-libxml=/usr/local/bin --with-imap=/usr/bin/imap --with-imap-ssl=/usr --with-curl=/home/shadda/curl-7.13.0 --enable-exif --with-jpeg-dir=/home/shadda/php-5.0.3/jpeg-6b My --with-jpeg-dir line has changed many times while tracking this bug, but the interesting thing is that it never once failed. Checking my config.log *and* my makefile logs with a fine tooth comb told me that it was in fact attempting to compile with jpeg support, and could find no point at which this was failing. But after every make, make install, (and yes, I restarted/stop/started apache many, many times) I would discover in phpinfo(), that although the configure line at the top reflected any changes i had just made, JPG Support was not enabled, or even visible on the page (And of course, no JPEG functions would work, either). I spent the better part of a day looking for ways around this. I deleted the config.cache file prior to configuring, and a large amount of other more obscure workarounds but just could *not* get it to go. Even after installing a snapshot i had on hand, it would not work. I searched around bugs.php.net thoroughly but have not found a bug report related this this. I went back and got another snapshot release of 5.0.3, snapshot release php5-200502130130. I ran that same configure line from above, make, make install, restarted apache, and now i have JPG support. I've solved it on my system, but felt I should report this nevertheless. Thankyou. -- Edit this bug report at http://bugs.php.net/?id=31949&edit=1
#31974 [Com]: func_get_args() does not work when variables have "_" in the middle of the name
ID: 31974
Comment by: shadda at gmail dot com
Reported By: pinhinha at gmail dot com
Status: Open
Bug Type: *Programming Data Structures
Operating System: LINUX
PHP Version: 5.0.3
New Comment:
You do realise, array_combine() does exactly that, right? Not to
mention that even were you using php4 there are several user comments
throughought php.net that show you how to accomplish this very thing
(And if I recall, There's a PEAR_COMPAT package that contains this
functionality.)
Previous Comments:
[2005-02-14 20:23:31] pinhinha at gmail dot com
Description:
Builds an associative array using value of previous defined vars.
It works on PHP 4.0.10
It doens't work on PHP 5.0.3
If the var names don't have "_" (underscore) in the name it works on
PHP4 AND PHP5.
Reproduce code:
---
function do_array() {
$new_array=array();
foreach (func_get_args() as $var) {
if (isset($GLOBALS[$var]))
$new_array[$var]=$GLOBALS[$var];
else exit("Error: var '$var' is not set.");
}
return $new_array;
}
$domain_name = "php.net";
$visit_date = date("Y-m-d");
$array = do_array("domain_name", "visit_date");
Expected result:
$array = ("domain_name" => "php.net",
"visit_date" => "2005-02-14"
);
Actual result:
--
Error: var 'domain_name' is not set.
--
Edit this bug report at http://bugs.php.net/?id=31974&edit=1
#47021 [Com]: SoapClient stumbles over WSDL delivered with "Transfer-Encoding: chunked"
ID: 47021
Comment by: shadda at gmail dot com
Reported By: daniel dot gorski at develnet dot org
Status: To be documented
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.3CVS-2009-01-06 (CVS)
New Comment:
I ran into this bug today myself, and after having compiled the latest
snapshot as of 8:00pm CST 2009-05-16 I am still experiencing this error.
Previous Comments:
[2009-04-16 10:56:27] bj...@php.net
This was fixed by introducing an 'dechunk' stream filter, see
http://news.php.net/php.cvs/57042
[2009-04-16 10:34:48] dmi...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2009-01-26 10:54:53] giovanni at giacobbi dot net
Please see related discussion:
http://marc.info/?t=12329199332&r=1&w=2
See also bug report #43069 which actually caused this bug.
[2009-01-22 15:35:02] ml at x-net dot be
I can confirm this bug. I tried avoiding the chunking in Apache by
using mod_deflate, but the PHP SOAP client probably doesn't send an
Accept-Encoding header with gzip in it.
[2009-01-06 16:28:52] daniel dot gorski at develnet dot org
Description:
The \SoapClient (and probably the \SoapServer) stumble over WSDL files
that are delivered via HTTP in chunks, carrying the HTTP response header
"Transfer-Encoding: chunked".
Reproduce code:
---
$sc = \SoapClient('http://any.wsdl/that/is/delivered/in/chunks');
Expected result:
No error, intantiation and initialization of the \SoapClient object.
Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
WSDL: Couldn't load from [URL]: Start tag expected, '<' not found in
[FILE]
--
Edit this bug report at http://bugs.php.net/?id=47021&edit=1
#36652 [NEW]: Prepared statements killing script
From: shadda at gmail dot com
Operating system: Debian 3.1
PHP version: 5.1.2
PHP Bug Type: PDO related
Bug description: Prepared statements killing script
Description:
Using prepared statements causes my script to die, in two ways depending
on how I use them. If I use bindParam() the script dies silently (no
error, no exception thrown, even with PDO::ATTR_ERRMODE set to
ERRMODE_EXCEPTION) and I am unable to output anything (above or below).
When I pass the parameter through PDOStatement::execute(), I receive the
following error:
SQLSTATE[42P18]: Indeterminate datatype: 7 ERROR: could not determine data
type of parameter $1
Reproduce code:
---
prepare("select font_name, path from fonts_list where id =
?");
$query->execute( array($_GET['foo']) );
//Produces error (see above)
//Second example
$query = $db->prepare("Select font_name, path from fonts_list where id =
:id");
$query->bindParam(':id', $id);
$id = $_GET['foo'];
$query->execute();
//Kills the script. No Error. Nothing error log.
--
Edit bug report at http://bugs.php.net/?id=36652&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36652&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36652&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36652&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36652&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36652&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36652&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36652&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36652&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36652&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36652&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36652&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36652&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36652&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36652&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36652&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36652&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36652&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36652&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36652&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36652&r=mysqlcfg
#36652 [Fbk->Opn]: Prepared statements killing script
ID: 36652
User updated by: shadda at gmail dot com
Reported By: shadda at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Debian 3.1
PHP Version: 5.1.2
New Comment:
Excuse the delay; I'm using PDO_PGSQL driver, and yes I've tried the
latest snapshot from snaps.php.net.
I just built it, and tested the code.
Gluttony:/home/shadda/php5.1-200603081930# php -r '
try {
$db = new PDO("pgsql:host=localhost;dbname=carbonix", "xoom",
"1914");
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$q = $db->prepare("select ?");
$q->execute( array(1) ); var_dump($q->fetch());
} catch (Exception $e) { echo $e->getMessage(); }'
Returns:
SQLSTATE[42P18]: Indeterminate datatype: 7 ERROR: could not determine
data type of parameter
Previous Comments:
[2006-03-08 08:28:12] [EMAIL PROTECTED]
What driver are you using with PDO ?
Is it PDO_OCI or PDO_MYSQL or something else?
Did you try CVS snapshot from http://snaps.php.net?
----------------
[2006-03-08 06:19:42] shadda at gmail dot com
Description:
Using prepared statements causes my script to die, in two ways
depending on how I use them. If I use bindParam() the script dies
silently (no error, no exception thrown, even with PDO::ATTR_ERRMODE
set to ERRMODE_EXCEPTION) and I am unable to output anything (above or
below). When I pass the parameter through PDOStatement::execute(), I
receive the following error:
SQLSTATE[42P18]: Indeterminate datatype: 7 ERROR: could not determine
data type of parameter $1
Reproduce code:
---
prepare("select font_name, path from fonts_list where id
= ?");
$query->execute( array($_GET['foo']) );
//Produces error (see above)
//Second example
$query = $db->prepare("Select font_name, path from fonts_list where id
= :id");
$query->bindParam(':id', $id);
$id = $_GET['foo'];
$query->execute();
//Kills the script. No Error. Nothing error log.
--
Edit this bug report at http://bugs.php.net/?id=36652&edit=1
#37037 [NEW]: Can't access result returned from an INSERT
From: shadda at gmail dot com
Operating system: Debian 3.1
PHP version: 5.1.3RC2
PHP Bug Type: PDO related
Bug description: Can't access result returned from an INSERT
Description:
I'm using PostgreSQL 8.1.2, on Debian Sid. In my database, I have a table
with a RULE on inserts...
CREATE RULE test_rule AS
ON INSERT TO test_table
DO ALSO
SELECT NEW.id;
When a new row is inserted to this table, it returns the ID (currval) of
the new row. This works from PSQL, DBI (perl), and JDBC, aswell as the
standard Pgsql extension in PHP.
>From PDO, however, when calling PDOStatement::Fetch() after an insert,
only an empty array is returned, and not the resultset I was expecting.
Reproduce code:
---
create table test_table ( id serial primary key );
create rule test_rule as on insert to test_table do also select new.id;
[EMAIL PROTECTED]:/$ php -r '
$db = new
PDO("pgsql:host=localhost;user=xoom;password=1914;dbname=general");
$q = $db->query("insert into foo default values");
var_dump($q->fetch());
'
Expected result:
array(2) {
[0]=>
string(2) "10"
["id"]=>
string(2) "10"
}
Actual result:
--
array(0) {
}
--
Edit bug report at http://bugs.php.net/?id=37037&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37037&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37037&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37037&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37037&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37037&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37037&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37037&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37037&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37037&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37037&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37037&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37037&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37037&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37037&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37037&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37037&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37037&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37037&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37037&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37037&r=mysqlcfg
#37037 [Opn]: Can't access result returned from an INSERT
ID: 37037
User updated by: shadda at gmail dot com
Reported By: shadda at gmail dot com
Status: Open
Bug Type: PDO related
Operating System: Debian 3.1
PHP Version: 5.1.3RC2
New Comment:
Just a quick note -- in the above insert statement, the table should be
'test_table'
Previous Comments:
[2006-04-11 10:30:53] shadda at gmail dot com
Description:
I'm using PostgreSQL 8.1.2, on Debian Sid. In my database, I have a
table with a RULE on inserts...
CREATE RULE test_rule AS
ON INSERT TO test_table
DO ALSO
SELECT NEW.id;
When a new row is inserted to this table, it returns the ID (currval)
of the new row. This works from PSQL, DBI (perl), and JDBC, aswell as
the standard Pgsql extension in PHP.
>From PDO, however, when calling PDOStatement::Fetch() after an insert,
only an empty array is returned, and not the resultset I was expecting.
Reproduce code:
---
create table test_table ( id serial primary key );
create rule test_rule as on insert to test_table do also select
new.id;
[EMAIL PROTECTED]:/$ php -r '
$db = new
PDO("pgsql:host=localhost;user=xoom;password=1914;dbname=general");
$q = $db->query("insert into foo default values");
var_dump($q->fetch());
'
Expected result:
array(2) {
[0]=>
string(2) "10"
["id"]=>
string(2) "10"
}
Actual result:
--
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=37037&edit=1
