#44967 [NEW]: FastCGI broken in 5.2.6 NTS on IIS
From: randy at rcs-comp dot com Operating system: Windows 2003 Server PHP version: 5.2.6 PHP Bug Type: CGI related Bug description: FastCGI broken in 5.2.6 NTS on IIS Description: I am using the technique described here: http://learn.iis.net/page.aspx/247/using-fastcgi-to-host-php-applications-on-iis-60/ to get PHP running on IIS with fastcgi. I have confirmed that the following three builds will run correctly on my Windows 2003 server setup according to the instructions above: - PHP 5.2.5 NTS - PHP 5.2.5 TS - PHP 5.2.6 TS However, when trying to run with 5.2.6 NTS, as is recommended in the above URL, I get an IIS error. Reproduce code: --- phpinfo(); Expected result: normal phpinfo() output Actual result: -- - FastCGI Error The FastCGI Handler was unable to process the request. Error Details: * Error Number: 5 (0x80070005). * Error Description: Access is denied. HTTP Error 500 - Server Error. Internet Information Services (IIS) - -- Edit bug report at http://bugs.php.net/?id=44967&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44967&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44967&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44967&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44967&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44967&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44967&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44967&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44967&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44967&r=support Expected behavior:http://bugs.php.net/fix.php?id=44967&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44967&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44967&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44967&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44967&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44967&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44967&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44967&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44967&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44967&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44967&r=mysqlcfg
#42596 [Csd]: session.save_path MODE option will not set "write" bit for group or world
ID: 42596 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com Status: Closed Bug Type: Session related Operating System: Linux PHP Version: 5.2.4 New Comment: THANK YOU! Previous Comments: [2007-09-10 23:43:13] [EMAIL PROTECTED] 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. [2007-09-08 03:47:00] randy at rcs-comp dot com Description: When using the mode parameter in session_save_path (or presumably session.save_path) it will not set the "write" bit correctly for anyone but the owner of the file. Read and execute bits are set correctly. This is important b/c I would like to setguid on the session directory so that a non-priveleged user (the website reseller) can clean it out. That way, all I have to do is add apache to the user's group, and no more problems with clearing out sessions. Reproduce code: --- // delete the session file just created // delete the session file just created Expected result: [EMAIL PROTECTED] sessions]# ls -l total 0 -rw--- 1 apache apache 0 Sep 7 23:30 sess_b1fb... [EMAIL PROTECTED] sessions]# ls -l total 0 -rw-rw 1 apache apache 0 Sep 7 23:31 sess_b1fb... [EMAIL PROTECTED] sessions]# ls -l total 0 -rwxrwxrwx 1 apache apache 0 Sep 7 23:40 sess_b1fb... Actual result: -- [EMAIL PROTECTED] sessions]# ls -l total 0 -rw--- 1 apache apache 0 Sep 7 23:30 sess_b1fb... [EMAIL PROTECTED] sessions]# ls -l total 0 -rw-r- 1 apache apache 0 Sep 7 23:31 sess_b1fb... ^^ < Permission does not have write bit [EMAIL PROTECTED] sessions]# ls -l total 0 -rwxr-xr-x 1 apache apache 0 Sep 7 23:40 sess_b1fb... ^^ < Permission does not have write bits -- Edit this bug report at http://bugs.php.net/?id=42596&edit=1
#42603 [NEW]: Followup Comment for bug #42596
From: randy at rcs-comp dot com Operating system: Linux PHP version: 5.2.4 PHP Bug Type: Session related Bug description: Followup Comment for bug #42596 Description: The bug #42596 was classified as bogus but its not. I couldn't post a comment on that thread, so here is my followup: Are you kidding me! From the php.ini file: ; The file storage module creates files using mode 600 by default. ; You can change that by using ; ; session.save_path = "N;MODE;/path" ; ; where MODE is the octal representation of the mode. Note that this ; does not overwrite the process's umask. ;session.save_path = "/tmp" I realize its not in the documentation, but it should be. -- Edit bug report at http://bugs.php.net/?id=42603&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42603&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42603&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42603&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42603&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42603&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42603&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42603&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42603&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42603&r=support Expected behavior:http://bugs.php.net/fix.php?id=42603&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42603&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42603&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42603&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42603&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42603&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42603&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42603&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42603&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42603&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42603&r=mysqlcfg
#42596 [NEW]: session.save_path MODE option will not set "write" bit for group or world
From: randy at rcs-comp dot com Operating system: Linux PHP version: 5.2.4 PHP Bug Type: Session related Bug description: session.save_path MODE option will not set "write" bit for group or world Description: When using the mode parameter in session_save_path (or presumably session.save_path) it will not set the "write" bit correctly for anyone but the owner of the file. Read and execute bits are set correctly. This is important b/c I would like to setguid on the session directory so that a non-priveleged user (the website reseller) can clean it out. That way, all I have to do is add apache to the user's group, and no more problems with clearing out sessions. Reproduce code: --- // delete the session file just created // delete the session file just created Expected result: [EMAIL PROTECTED] sessions]# ls -l total 0 -rw--- 1 apache apache 0 Sep 7 23:30 sess_b1fb... [EMAIL PROTECTED] sessions]# ls -l total 0 -rw-rw 1 apache apache 0 Sep 7 23:31 sess_b1fb... [EMAIL PROTECTED] sessions]# ls -l total 0 -rwxrwxrwx 1 apache apache 0 Sep 7 23:40 sess_b1fb... Actual result: -- [EMAIL PROTECTED] sessions]# ls -l total 0 -rw--- 1 apache apache 0 Sep 7 23:30 sess_b1fb... [EMAIL PROTECTED] sessions]# ls -l total 0 -rw-r- 1 apache apache 0 Sep 7 23:31 sess_b1fb... ^^ < Permission does not have write bit [EMAIL PROTECTED] sessions]# ls -l total 0 -rwxr-xr-x 1 apache apache 0 Sep 7 23:40 sess_b1fb... ^^ < Permission does not have write bits -- Edit bug report at http://bugs.php.net/?id=42596&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42596&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42596&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42596&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42596&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42596&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42596&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42596&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42596&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42596&r=support Expected behavior:http://bugs.php.net/fix.php?id=42596&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42596&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42596&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42596&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42596&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42596&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42596&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42596&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42596&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42596&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42596&r=mysqlcfg
#39310 [Bgs]: PDO Scrolling cursors not available for Sqlite and don't work for Mysql
ID: 39310
User updated by: randy at rcs-comp dot com
Reported By: randy at rcs-comp dot com
Status: Bogus
Bug Type: PDO related
Operating System: Win XP
PHP Version: 5.1.6
New Comment:
Is there anywhere in the documentation that describes what database
drivers support this? Or, is there a way to tell programatically?
Thanks.
Previous Comments:
[2006-12-04 02:30:50] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
This is because cursors are only supported in instance where
the underlying database provides such functionality. In the
case of MySQL and SQLite there is no such support. PDO does
not provide emulation for cursors.
[2006-11-16 22:39:15] randy at rcs-comp dot com
For what it is worth, I have confirmed that this continues to be a
problem in version 5.2.0.
[2006-10-30 16:23:31] randy at rcs-comp dot com
Sorry, reproduce code file is here:
http://www.rcs-comp.com/tmp/simple_pdo_test.php.txt
[2006-10-30 16:21:49] randy at rcs-comp dot com
Description:
When trying to make the scrolling cursor example found here:
http://us2.php.net/manual/en/function.pdostatement-fetch.php
under Example 2 to work, I could not. Note that I am unsure of which
way I should use the prepare statement. The example uses this:
$stmt = $dbh->prepare($sql, array(PDO::ATTR_CURSOR,
PDO::CURSOR_SCROLL));
But based on the documentation here:
http://us2.php.net/manual/en/function.pdo-prepare.php
It seems that this would make more sense (the driver options are in an
associative array:
$stmt = $dbh->prepare($sql, array(PDO::ATTR_CURSOR =>
PDO::CURSOR_SCROLL));
Note that I have tried both methods for both Sqlite and MySQL. The
results are as follows:
MySql w/ example array: returns object but scrolling does not work.
MySql w/ associative array: returns object but scrolling does not
work.
SQLite w/ example array: returns object but scrolling does not work.
SQLite w/ associative array: returns FALSE
Reproduce code:
---
Example file can be found here:
http://www.rcs-comp.com/tmp/simple_pdo_test.php
>php simple_pdo_test.php
Expected result:
connections created
tables created: 0 0
tables filled
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
object(PDOStatement)#3 (1) {
["queryString"]=>
string(53) "SELECT user, email, time FROM testtable ORDER BY user"
}
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
rows updated: 3 3
rows deleted: 3 3
tables droped: 3 0
Actual result:
--
connections created
tables created: 0 0
tables filled
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
bool(false)
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
rows updated: 3 3
rows deleted: 3 3
tables droped: 3 0
--
Edit this bug report at http://bugs.php.net/?id=39310&edit=1
#39618 [Opn]: Inconsistent row count totals being returned with sqlite2 and sqlite3 PDO
ID: 39618 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com Status: Open -Bug Type: Documentation problem +Bug Type: PDO related Operating System: Windows XP PHP Version: 5.2.0 New Comment: I will not leave this bug report alone until you address the fact that the SQLite 2 driver itself is inconsistent in the way it returns row counts. Please see my last post. Previous Comments: [2006-11-30 09:35:29] [EMAIL PROTECTED] The only thing we can do about *SQLite* inconsistencies and problems is DOCUMENT THEM. Please do not touch the report anymore, if you don't have a patch yourself and not going to do anything about it anyway. Thank you. [2006-11-28 14:56:16] randy at rcs-comp dot com Then please address the inconstancy in the driver itself. I will repost for ease of reference: Notice that the bug only appears after a prepared statement is requested. This means the driver itself is inconsistent in what it returns. If this is not a bug, then under "Actual Results" I should have: >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 //<-- if truly not a bug, then this should say "3 5" statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 5 rows updated w/ exec() (some): 2 7 rows updated w/ prep & execute() (all): 3 3 [2006-11-28 14:52:43] [EMAIL PROTECTED] >It may be true that SQLite works this way, but if that is >the case, then PHP should work around this for the SQLite2 >driver so that the PDO interface is consistant. .. or document it. Please let developers to decide what to do with such kind of problems. ------------ [2006-11-28 14:44:50] randy at rcs-comp dot com "Since this is the way SQLite works, we can't fix it in PHP and this should be documented." It may be true that SQLite works this way, but if that is the case, then PHP should work around this for the SQLite2 driver so that the PDO interface is consistant. The PHP developer should not have to be concerned with driver specific details like this. -------------------- [2006-11-28 14:42:34] randy at rcs-comp dot com Tony, Sorry, I am not going to let this one drop unless someone else chimes in. I have been around bugs.php.net to know that you are reluctant to fix bugs that are truly bugs. Case in point: http://bugs.php.net/bug.php?id=37846 This is a bug and not a documentation problem! 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/39618 -- Edit this bug report at http://bugs.php.net/?id=39618&edit=1
#39618 [Opn]: Inconsistent row count totals being returned with sqlite2 and sqlite3 PDO
ID: 39618 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com Status: Open -Bug Type: Documentation problem +Bug Type: PDO related Operating System: Windows XP PHP Version: 5.2.0 New Comment: Then please address the inconstancy in the driver itself. I will repost for ease of reference: Notice that the bug only appears after a prepared statement is requested. This means the driver itself is inconsistent in what it returns. If this is not a bug, then under "Actual Results" I should have: >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 //<-- if truly not a bug, then this should say "3 5" statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 5 rows updated w/ exec() (some): 2 7 rows updated w/ prep & execute() (all): 3 3 Previous Comments: [2006-11-28 14:52:43] [EMAIL PROTECTED] >It may be true that SQLite works this way, but if that is >the case, then PHP should work around this for the SQLite2 >driver so that the PDO interface is consistant. .. or document it. Please let developers to decide what to do with such kind of problems. ------------ [2006-11-28 14:44:50] randy at rcs-comp dot com "Since this is the way SQLite works, we can't fix it in PHP and this should be documented." It may be true that SQLite works this way, but if that is the case, then PHP should work around this for the SQLite2 driver so that the PDO interface is consistant. The PHP developer should not have to be concerned with driver specific details like this. -------------------- [2006-11-28 14:42:34] randy at rcs-comp dot com Tony, Sorry, I am not going to let this one drop unless someone else chimes in. I have been around bugs.php.net to know that you are reluctant to fix bugs that are truly bugs. Case in point: http://bugs.php.net/bug.php?id=37846 This is a bug and not a documentation problem! -------------------- [2006-11-28 14:39:00] randy at rcs-comp dot com Another reason it is a bug is because the PDO SQLite2 driver is inconsistent itself! Notice that the bug only appears after a prepared statement is requested. If this is not a bug, then under "Actual Results" I should have: >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 //<-- if truly not a bug, then this should say "3 5" statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 5 rows updated w/ exec() (some): 2 7 rows updated w/ prep & execute() (all): 3 3 [2006-11-28 14:36:08] [EMAIL PROTECTED] The very same issue in SQLite bug db (http://www.sqlite.org/cvstrac/tktview?tn=383) has beem resolved by adding it to the docs. If you think it's wrong, then you can report it to SQLite developers and persuade them to fix it in SQLite. Since this is the way SQLite works, we can't fix it in PHP and this should be documented. >If you insist that this is a documentation problem Yes, I do. >will you please have another PHP developer chime in and agree with you. No, thank you. 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/39618 -- Edit this bug report at http://bugs.php.net/?id=39618&edit=1
#39618 [Opn]: Inconsistent row count totals being returned with sqlite2 and sqlite3 PDO
ID: 39618 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com Status: Open Bug Type: PDO related Operating System: Windows XP PHP Version: 5.2.0 New Comment: "Since this is the way SQLite works, we can't fix it in PHP and this should be documented." It may be true that SQLite works this way, but if that is the case, then PHP should work around this for the SQLite2 driver so that the PDO interface is consistant. The PHP developer should not have to be concerned with driver specific details like this. Previous Comments: [2006-11-28 14:42:34] randy at rcs-comp dot com Tony, Sorry, I am not going to let this one drop unless someone else chimes in. I have been around bugs.php.net to know that you are reluctant to fix bugs that are truly bugs. Case in point: http://bugs.php.net/bug.php?id=37846 This is a bug and not a documentation problem! [2006-11-28 14:39:00] randy at rcs-comp dot com Another reason it is a bug is because the PDO SQLite2 driver is inconsistent itself! Notice that the bug only appears after a prepared statement is requested. If this is not a bug, then under "Actual Results" I should have: >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 //<-- if truly not a bug, then this should say "3 5" statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 5 rows updated w/ exec() (some): 2 7 rows updated w/ prep & execute() (all): 3 3 [2006-11-28 14:36:08] [EMAIL PROTECTED] The very same issue in SQLite bug db (http://www.sqlite.org/cvstrac/tktview?tn=383) has beem resolved by adding it to the docs. If you think it's wrong, then you can report it to SQLite developers and persuade them to fix it in SQLite. Since this is the way SQLite works, we can't fix it in PHP and this should be documented. >If you insist that this is a documentation problem Yes, I do. >will you please have another PHP developer chime in and agree with you. No, thank you. -------------------- [2006-11-28 14:26:33] randy at rcs-comp dot com THIS IS NOT A DOCUMENTATION PROBLEM!!! The documentation describes the best way for the function to work. It is a problem with a PDO driver not working like every other PDO driver! What is the point of a database abstraction layer if you can't rely upon it to be consistent across drivers If you insist that this is a documentation problem, will you please have another PHP developer chime in and agree with you. If so, I will leave the bug report alone. Thank you. [2006-11-28 14:22:46] [EMAIL PROTECTED] Reclassified as docu problem. 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/39618 -- Edit this bug report at http://bugs.php.net/?id=39618&edit=1
#39618 [Opn]: Inconsistent row count totals being returned with sqlite2 and sqlite3 PDO
ID: 39618 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com Status: Open Bug Type: PDO related Operating System: Windows XP PHP Version: 5.2.0 New Comment: Tony, Sorry, I am not going to let this one drop unless someone else chimes in. I have been around bugs.php.net to know that you are reluctant to fix bugs that are truly bugs. Case in point: http://bugs.php.net/bug.php?id=37846 This is a bug and not a documentation problem! Previous Comments: [2006-11-28 14:39:00] randy at rcs-comp dot com Another reason it is a bug is because the PDO SQLite2 driver is inconsistent itself! Notice that the bug only appears after a prepared statement is requested. If this is not a bug, then under "Actual Results" I should have: >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 //<-- if truly not a bug, then this should say "3 5" statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 5 rows updated w/ exec() (some): 2 7 rows updated w/ prep & execute() (all): 3 3 [2006-11-28 14:36:08] [EMAIL PROTECTED] The very same issue in SQLite bug db (http://www.sqlite.org/cvstrac/tktview?tn=383) has beem resolved by adding it to the docs. If you think it's wrong, then you can report it to SQLite developers and persuade them to fix it in SQLite. Since this is the way SQLite works, we can't fix it in PHP and this should be documented. >If you insist that this is a documentation problem Yes, I do. >will you please have another PHP developer chime in and agree with you. No, thank you. ---------------- [2006-11-28 14:26:33] randy at rcs-comp dot com THIS IS NOT A DOCUMENTATION PROBLEM!!! The documentation describes the best way for the function to work. It is a problem with a PDO driver not working like every other PDO driver! What is the point of a database abstraction layer if you can't rely upon it to be consistent across drivers If you insist that this is a documentation problem, will you please have another PHP developer chime in and agree with you. If so, I will leave the bug report alone. Thank you. [2006-11-28 14:22:46] [EMAIL PROTECTED] Reclassified as docu problem. -------------------- [2006-11-28 14:20:00] randy at rcs-comp dot com Tony, Thank you for your time on this and the explanation. However, I still think this represents a bug in PHP for three reasons. 1) The documentation says "PDOStatement::rowCount -- Returns the number of rows affected by the last SQL statement" Notice that it says "the last" SQL statement. In my example, the rowCount() returns the SUM of several SQL statements not the total of the "last SQL statement." This function does not work the way the documentation says it does, and is therefore buggy. 2) I understand what you are saying about "this is how it is supposed to work in Sqlite2." However, just because SQLite2 is working correctly does not automatically mean that PDO is working correctly. PDO is a database abstraction layer whose purpose is to hide the implimenation details of the specific drivers for PHP developers. If you don't fix this bug, every SQLite2 developer would need to be aware of this driver specific issue and code around it. 3) I tested PDO MySQL, PDO Mssql, and PDO SQLite 3 and NONE of them exhibit the behavior of PDO SQLite2. This is a huge incompatability for the SQLite 2 driver. I welcome a difference of opinion, but honestly it seems pretty clear to me that this is a bug. 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/39618 -- Edit this bug report at http://bugs.php.net/?id=39618&edit=1
#39618 [Opn]: Inconsistent row count totals being returned with sqlite2 and sqlite3 PDO
ID: 39618 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com Status: Open -Bug Type: Documentation problem +Bug Type: PDO related Operating System: Windows XP PHP Version: 5.2.0 New Comment: Another reason it is a bug is because the PDO SQLite2 driver is inconsistent itself! Notice that the bug only appears after a prepared statement is requested. If this is not a bug, then under "Actual Results" I should have: >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 //<-- if truly not a bug, then this should say "3 5" statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 5 rows updated w/ exec() (some): 2 7 rows updated w/ prep & execute() (all): 3 3 Previous Comments: [2006-11-28 14:36:08] [EMAIL PROTECTED] The very same issue in SQLite bug db (http://www.sqlite.org/cvstrac/tktview?tn=383) has beem resolved by adding it to the docs. If you think it's wrong, then you can report it to SQLite developers and persuade them to fix it in SQLite. Since this is the way SQLite works, we can't fix it in PHP and this should be documented. >If you insist that this is a documentation problem Yes, I do. >will you please have another PHP developer chime in and agree with you. No, thank you. ---------------- [2006-11-28 14:26:33] randy at rcs-comp dot com THIS IS NOT A DOCUMENTATION PROBLEM!!! The documentation describes the best way for the function to work. It is a problem with a PDO driver not working like every other PDO driver! What is the point of a database abstraction layer if you can't rely upon it to be consistent across drivers If you insist that this is a documentation problem, will you please have another PHP developer chime in and agree with you. If so, I will leave the bug report alone. Thank you. [2006-11-28 14:22:46] [EMAIL PROTECTED] Reclassified as docu problem. -------------------- [2006-11-28 14:20:00] randy at rcs-comp dot com Tony, Thank you for your time on this and the explanation. However, I still think this represents a bug in PHP for three reasons. 1) The documentation says "PDOStatement::rowCount -- Returns the number of rows affected by the last SQL statement" Notice that it says "the last" SQL statement. In my example, the rowCount() returns the SUM of several SQL statements not the total of the "last SQL statement." This function does not work the way the documentation says it does, and is therefore buggy. 2) I understand what you are saying about "this is how it is supposed to work in Sqlite2." However, just because SQLite2 is working correctly does not automatically mean that PDO is working correctly. PDO is a database abstraction layer whose purpose is to hide the implimenation details of the specific drivers for PHP developers. If you don't fix this bug, every SQLite2 developer would need to be aware of this driver specific issue and code around it. 3) I tested PDO MySQL, PDO Mssql, and PDO SQLite 3 and NONE of them exhibit the behavior of PDO SQLite2. This is a huge incompatability for the SQLite 2 driver. I welcome a difference of opinion, but honestly it seems pretty clear to me that this is a bug. [2006-11-28 11:07:12] [EMAIL PROTECTED] See http://www.sqlite.org/cvstrac/tktview?tn=383 "The sqlite_changes API function returns the number of rows that have been inserted, deleted, or modified since the database was last quiescent. A "quiescent" database is one in which there are no outstanding calls to sqlite_exec and no VMs created by sqlite_compile that have not been finalized by sqlite_finalize." This is how it is supposed to work in Sqlite2, but Sqlite3 seems to work differently. 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/39618 -- Edit this bug report at http://bugs.php.net/?id=39618&edit=1
#39618 [Opn]: Inconsistent row count totals being returned with sqlite2 and sqlite3 PDO
ID: 39618 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com Status: Open -Bug Type: Documentation problem +Bug Type: PDO related Operating System: Windows XP PHP Version: 5.2.0 New Comment: THIS IS NOT A DOCUMENTATION PROBLEM!!! The documentation describes the best way for the function to work. It is a problem with a PDO driver not working like every other PDO driver! What is the point of a database abstraction layer if you can't rely upon it to be consistent across drivers If you insist that this is a documentation problem, will you please have another PHP developer chime in and agree with you. If so, I will leave the bug report alone. Thank you. Previous Comments: [2006-11-28 14:22:46] [EMAIL PROTECTED] Reclassified as docu problem. [2006-11-28 14:20:00] randy at rcs-comp dot com Tony, Thank you for your time on this and the explanation. However, I still think this represents a bug in PHP for three reasons. 1) The documentation says "PDOStatement::rowCount -- Returns the number of rows affected by the last SQL statement" Notice that it says "the last" SQL statement. In my example, the rowCount() returns the SUM of several SQL statements not the total of the "last SQL statement." This function does not work the way the documentation says it does, and is therefore buggy. 2) I understand what you are saying about "this is how it is supposed to work in Sqlite2." However, just because SQLite2 is working correctly does not automatically mean that PDO is working correctly. PDO is a database abstraction layer whose purpose is to hide the implimenation details of the specific drivers for PHP developers. If you don't fix this bug, every SQLite2 developer would need to be aware of this driver specific issue and code around it. 3) I tested PDO MySQL, PDO Mssql, and PDO SQLite 3 and NONE of them exhibit the behavior of PDO SQLite2. This is a huge incompatability for the SQLite 2 driver. I welcome a difference of opinion, but honestly it seems pretty clear to me that this is a bug. [2006-11-28 11:07:12] [EMAIL PROTECTED] See http://www.sqlite.org/cvstrac/tktview?tn=383 "The sqlite_changes API function returns the number of rows that have been inserted, deleted, or modified since the database was last quiescent. A "quiescent" database is one in which there are no outstanding calls to sqlite_exec and no VMs created by sqlite_compile that have not been finalized by sqlite_finalize." This is how it is supposed to work in Sqlite2, but Sqlite3 seems to work differently. -------------------- [2006-11-24 14:56:53] randy at rcs-comp dot com Description: After using prepare() & execute() to retrieve a PDO Statement from a PDO Sqlite2 connection, subsequent calls to exec() return a "rows affected" value that appears to sum the previous calls to exec() together. Reproduce code: --- http://www.rcs-comp.com/phpcode/simple_pdo_test3.php.txt Expected result: >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 rows updated w/ exec() (some): 2 2 rows updated w/ prep & execute() (all): 3 3 Actual result: -- >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 5 <-- notice the addition from the prev. row rows updated w/ exec() (some): 2 7 <-- notice the addition from the prev. row rows updated w/ prep & execute() (all): 3 3 <-- problem disappears -- Edit this bug report at http://bugs.php.net/?id=39618&edit=1
#39618 [Bgs->Opn]: Inconsistent row count totals being returned with sqlite2 and sqlite3 PDO
ID: 39618 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com -Status: Bogus +Status: Open Bug Type: PDO related Operating System: Windows XP PHP Version: 5.2.0 New Comment: Tony, Thank you for your time on this and the explanation. However, I still think this represents a bug in PHP for three reasons. 1) The documentation says "PDOStatement::rowCount -- Returns the number of rows affected by the last SQL statement" Notice that it says "the last" SQL statement. In my example, the rowCount() returns the SUM of several SQL statements not the total of the "last SQL statement." This function does not work the way the documentation says it does, and is therefore buggy. 2) I understand what you are saying about "this is how it is supposed to work in Sqlite2." However, just because SQLite2 is working correctly does not automatically mean that PDO is working correctly. PDO is a database abstraction layer whose purpose is to hide the implimenation details of the specific drivers for PHP developers. If you don't fix this bug, every SQLite2 developer would need to be aware of this driver specific issue and code around it. 3) I tested PDO MySQL, PDO Mssql, and PDO SQLite 3 and NONE of them exhibit the behavior of PDO SQLite2. This is a huge incompatability for the SQLite 2 driver. I welcome a difference of opinion, but honestly it seems pretty clear to me that this is a bug. Previous Comments: [2006-11-28 11:07:12] [EMAIL PROTECTED] See http://www.sqlite.org/cvstrac/tktview?tn=383 "The sqlite_changes API function returns the number of rows that have been inserted, deleted, or modified since the database was last quiescent. A "quiescent" database is one in which there are no outstanding calls to sqlite_exec and no VMs created by sqlite_compile that have not been finalized by sqlite_finalize." This is how it is supposed to work in Sqlite2, but Sqlite3 seems to work differently. -------------------- [2006-11-24 14:56:53] randy at rcs-comp dot com Description: After using prepare() & execute() to retrieve a PDO Statement from a PDO Sqlite2 connection, subsequent calls to exec() return a "rows affected" value that appears to sum the previous calls to exec() together. Reproduce code: --- http://www.rcs-comp.com/phpcode/simple_pdo_test3.php.txt Expected result: >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 rows updated w/ exec() (some): 2 2 rows updated w/ prep & execute() (all): 3 3 Actual result: -- >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 5 <-- notice the addition from the prev. row rows updated w/ exec() (some): 2 7 <-- notice the addition from the prev. row rows updated w/ prep & execute() (all): 3 3 <-- problem disappears -- Edit this bug report at http://bugs.php.net/?id=39618&edit=1
#39656 [NEW]: Crash when calling fetch() on a PDO statment object after closeCursor()
From: randy at rcs-comp dot com Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: Reproducible crash Bug description: Crash when calling fetch() on a PDO statment object after closeCursor() Description: After calling the example code using CLI on Windows XP, CLI appears to crash. I get the XP notification box asking to send info to Microsoft, however the PHP process is still listed in the task manager and must be killed (end process tree) in order to get the command prompt working correctly. I installed the .pdb files from snaps.php.net in the hopes of providing a backtrace, but I never got the debug interface that the instructions said I would. If you need a backtrace, please point me to better instructions on how to create one. Reproduce code: --- http://www.rcs-comp.com/phpcode/simple_pdo_test4.php.txt Expected result: >php simple_pdo_test4.php Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164686920 [3] => 1164686920 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) bool( false ) Actual result: -- Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164686920 [3] => 1164686920 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) // at this point I get the XP dialog box telling me "CLI has encountered a problem and needs to close...Please tell Microsoft about this problem..." -- Edit bug report at http://bugs.php.net/?id=39656&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39656&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39656&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39656&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39656&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39656&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39656&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39656&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39656&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39656&r=support Expected behavior:http://bugs.php.net/fix.php?id=39656&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39656&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39656&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39656&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39656&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39656&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39656&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39656&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39656&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39656&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39656&r=mysqlcfg
#39618 [NEW]: Inconsistent row count totals being returned with sqlite2 and sqlite3 PDO
From: randy at rcs-comp dot com Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: PDO related Bug description: Inconsistent row count totals being returned with sqlite2 and sqlite3 PDO Description: After using prepare() & execute() to retrieve a PDO Statement from a PDO Sqlite2 connection, subsequent calls to exec() return a "rows affected" value that appears to sum the previous calls to exec() together. Reproduce code: --- http://www.rcs-comp.com/phpcode/simple_pdo_test3.php.txt Expected result: >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 rows updated w/ exec() (some): 2 2 rows updated w/ prep & execute() (all): 3 3 Actual result: -- >php simple_pdo_test3.php rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 3 statement preped and all records retrieved rows updated w/ exec() (some): 2 2 rows updated w/ exec() (all): 3 5 <-- notice the addition from the prev. row rows updated w/ exec() (some): 2 7 <-- notice the addition from the prev. row rows updated w/ prep & execute() (all): 3 3 <-- problem disappears -- Edit bug report at http://bugs.php.net/?id=39618&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39618&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39618&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39618&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39618&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39618&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39618&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39618&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39618&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39618&r=support Expected behavior:http://bugs.php.net/fix.php?id=39618&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39618&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39618&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39618&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39618&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39618&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39618&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39618&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39618&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39618&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39618&r=mysqlcfg
#39612 [NEW]: closeCursor() does not allow SQLite 2 statement to resume
From: randy at rcs-comp dot com Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: PDO related Bug description: closeCursor() does not allow SQLite 2 statement to resume Description: The documentation for PDOStatement::closeCursor(): frees up the connection to the server so that other SQL statements may be issued, but leaves the statement in a state that enables it to be executed again. When using PDO with a SQLite 3 connection, this works as intended. However, when trying to resume with a SQLite 2 connection, fetch() returns FALSE. Reproduce code: --- http://www.rcs-comp.com/phpcode/simple_pdo_test2.php.txt Expected result: 4 arrays of the first row of data: >php simple_pdo_test2.php Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Actual result: -- The last call to fetch() returns FALSE >php simple_pdo_test2.php Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) Array ( [id] => 1 [0] => 1 [user] => user1 [1] => user1 [email] => [EMAIL PROTECTED] [2] => [EMAIL PROTECTED] [time] => 1164353530 [3] => 1164353530 [message] => this is my message 1 [4] => this is my message 1 [confirmed] => 0 [5] => 0 ) bool(false) -- Edit bug report at http://bugs.php.net/?id=39612&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39612&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39612&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39612&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39612&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39612&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39612&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39612&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39612&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39612&r=support Expected behavior:http://bugs.php.net/fix.php?id=39612&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39612&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39612&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39612&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39612&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39612&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39612&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39612&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39612&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39612&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39612&r=mysqlcfg
#39545 [NEW]: Update PDO drivers so that PDO::closeCursor() is no longer needed
From: randy at rcs-comp dot com Operating system: PHP version: 5.2.0 PHP Bug Type: Feature/Change Request Bug description: Update PDO drivers so that PDO::closeCursor() is no longer needed Description: Request 1: Could you please document which PDO drivers require PDOStatement::closeCursor() method to be called. Request 2: Could you work on the drivers to get rid of this limitation or to track and handle it automatically. I am working on a PDO driver for Creole and this requirement is affecting my ability to come up with a 100% compatible solution. Thanks. -- Edit bug report at http://bugs.php.net/?id=39545&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39545&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39545&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39545&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39545&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39545&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39545&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39545&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39545&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39545&r=support Expected behavior:http://bugs.php.net/fix.php?id=39545&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39545&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39545&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39545&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39545&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39545&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39545&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39545&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39545&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39545&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39545&r=mysqlcfg
#39310 [Asn]: PDO Scrolling cursors not available for Sqlite and don't work for Mysql
ID: 39310
User updated by: randy at rcs-comp dot com
Reported By: randy at rcs-comp dot com
Status: Assigned
Bug Type: PDO related
Operating System: Win XP
PHP Version: 5.1.6
Assigned To: wez
New Comment:
For what it is worth, I have confirmed that this continues to be a
problem in version 5.2.0.
Previous Comments:
[2006-10-30 16:23:31] randy at rcs-comp dot com
Sorry, reproduce code file is here:
http://www.rcs-comp.com/tmp/simple_pdo_test.php.txt
[2006-10-30 16:21:49] randy at rcs-comp dot com
Description:
When trying to make the scrolling cursor example found here:
http://us2.php.net/manual/en/function.pdostatement-fetch.php
under Example 2 to work, I could not. Note that I am unsure of which
way I should use the prepare statement. The example uses this:
$stmt = $dbh->prepare($sql, array(PDO::ATTR_CURSOR,
PDO::CURSOR_SCROLL));
But based on the documentation here:
http://us2.php.net/manual/en/function.pdo-prepare.php
It seems that this would make more sense (the driver options are in an
associative array:
$stmt = $dbh->prepare($sql, array(PDO::ATTR_CURSOR =>
PDO::CURSOR_SCROLL));
Note that I have tried both methods for both Sqlite and MySQL. The
results are as follows:
MySql w/ example array: returns object but scrolling does not work.
MySql w/ associative array: returns object but scrolling does not
work.
SQLite w/ example array: returns object but scrolling does not work.
SQLite w/ associative array: returns FALSE
Reproduce code:
---
Example file can be found here:
http://www.rcs-comp.com/tmp/simple_pdo_test.php
>php simple_pdo_test.php
Expected result:
connections created
tables created: 0 0
tables filled
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
object(PDOStatement)#3 (1) {
["queryString"]=>
string(53) "SELECT user, email, time FROM testtable ORDER BY user"
}
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
rows updated: 3 3
rows deleted: 3 3
tables droped: 3 0
Actual result:
--
connections created
tables created: 0 0
tables filled
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
bool(false)
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
rows updated: 3 3
rows deleted: 3 3
tables droped: 3 0
--
Edit this bug report at http://bugs.php.net/?id=39310&edit=1
#39310 [Opn]: PDO Scrolling cursors not available for Sqlite and don't work for Mysql
ID: 39310
User updated by: randy at rcs-comp dot com
Reported By: randy at rcs-comp dot com
Status: Open
Bug Type: PDO related
Operating System: Win XP
PHP Version: 5.1.6
New Comment:
Sorry, reproduce code file is here:
http://www.rcs-comp.com/tmp/simple_pdo_test.php.txt
Previous Comments:
[2006-10-30 16:21:49] randy at rcs-comp dot com
Description:
When trying to make the scrolling cursor example found here:
http://us2.php.net/manual/en/function.pdostatement-fetch.php
under Example 2 to work, I could not. Note that I am unsure of which
way I should use the prepare statement. The example uses this:
$stmt = $dbh->prepare($sql, array(PDO::ATTR_CURSOR,
PDO::CURSOR_SCROLL));
But based on the documentation here:
http://us2.php.net/manual/en/function.pdo-prepare.php
It seems that this would make more sense (the driver options are in an
associative array:
$stmt = $dbh->prepare($sql, array(PDO::ATTR_CURSOR =>
PDO::CURSOR_SCROLL));
Note that I have tried both methods for both Sqlite and MySQL. The
results are as follows:
MySql w/ example array: returns object but scrolling does not work.
MySql w/ associative array: returns object but scrolling does not
work.
SQLite w/ example array: returns object but scrolling does not work.
SQLite w/ associative array: returns FALSE
Reproduce code:
---
Example file can be found here:
http://www.rcs-comp.com/tmp/simple_pdo_test.php
>php simple_pdo_test.php
Expected result:
connections created
tables created: 0 0
tables filled
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
object(PDOStatement)#3 (1) {
["queryString"]=>
string(53) "SELECT user, email, time FROM testtable ORDER BY user"
}
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
rows updated: 3 3
rows deleted: 3 3
tables droped: 3 0
Actual result:
--
connections created
tables created: 0 0
tables filled
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
bool(false)
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
rows updated: 3 3
rows deleted: 3 3
tables droped: 3 0
--
Edit this bug report at http://bugs.php.net/?id=39310&edit=1
#39310 [NEW]: PDO Scrolling cursors not available for Sqlite and don't work for Mysql
From: randy at rcs-comp dot com
Operating system: Win XP
PHP version: 5.1.6
PHP Bug Type: PDO related
Bug description: PDO Scrolling cursors not available for Sqlite and don't work
for Mysql
Description:
When trying to make the scrolling cursor example found here:
http://us2.php.net/manual/en/function.pdostatement-fetch.php
under Example 2 to work, I could not. Note that I am unsure of which way
I should use the prepare statement. The example uses this:
$stmt = $dbh->prepare($sql, array(PDO::ATTR_CURSOR, PDO::CURSOR_SCROLL));
But based on the documentation here:
http://us2.php.net/manual/en/function.pdo-prepare.php
It seems that this would make more sense (the driver options are in an
associative array:
$stmt = $dbh->prepare($sql, array(PDO::ATTR_CURSOR =>
PDO::CURSOR_SCROLL));
Note that I have tried both methods for both Sqlite and MySQL. The
results are as follows:
MySql w/ example array: returns object but scrolling does not work.
MySql w/ associative array: returns object but scrolling does not work.
SQLite w/ example array: returns object but scrolling does not work.
SQLite w/ associative array: returns FALSE
Reproduce code:
---
Example file can be found here:
http://www.rcs-comp.com/tmp/simple_pdo_test.php
>php simple_pdo_test.php
Expected result:
connections created
tables created: 0 0
tables filled
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
object(PDOStatement)#3 (1) {
["queryString"]=>
string(53) "SELECT user, email, time FROM testtable ORDER BY user"
}
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
rows updated: 3 3
rows deleted: 3 3
tables droped: 3 0
Actual result:
--
connections created
tables created: 0 0
tables filled
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
bool(false)
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
user1 [EMAIL PROTECTED] 1162224979
user2 [EMAIL PROTECTED] 1162224979
user3 [EMAIL PROTECTED] 1162224979
rows updated: 3 3
rows deleted: 3 3
tables droped: 3 0
--
Edit bug report at http://bugs.php.net/?id=39310&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39310&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39310&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39310&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39310&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39310&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39310&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39310&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39310&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39310&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39310&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39310&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39310&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39310&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39310&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39310&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39310&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39310&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39310&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39310&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39310&r=mysqlcfg
#38987 [Bgs]: isapi_fcgi.dll has problems with search engine friendly paths
ID: 38987 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com Status: Bogus Bug Type: IIS related Operating System: Win XP PHP Version: 5.2.0RC4 New Comment: Can you please tell me how this is related to PECL? I have looked through the PECL packages and do not find this project listed. In addition, the package itself is outside the PECL folder in CVS. Previous Comments: [2006-09-28 22:55:30] [EMAIL PROTECTED] Please report issues related to PECL projects to PECL bug tracker. [2006-09-28 22:27:30] randy at rcs-comp dot com Actually, the error comes from the isapi_fcgi.dll module I believe: http://viewcvs.php.net/viewvc.cgi/fastcgi-isapi/isapi_fcgi/isapi_fcgi.cpp?revision=1.3&view=markup Also, there is another bug dealing with this module that makes me think that PHP developers are working on this module? Here is the reference: http://bugs.php.net/bug.php?id=37448 (The bug is not necessarily related to mine though, just both being caused by isapi_fcgi.dll) [2006-09-28 22:19:49] [EMAIL PROTECTED] >I see in CVS that there have been some changes in this area What do you mean? >Is there a configuration or something that I can change to make this work? The error message comes from IIS, not PHP, so I have serious doubts we can help you. [2006-09-28 21:33:57] randy at rcs-comp dot com Description: I am using the code (and dll) from here: http://msmvps.com/blogs/guilherme/archive/2006/02/02/82336.aspx on a Windows XP machine with IIS 5.1. It runs well, except for one problem. I use the PATH_INFO information to run scripts that are search engine friendly. So, I can have a path like this: http://www.example.com/index.php/view/News-Main Which works fine. I can also pass other variables like this: http://www.example.com/index.php/view/News-Main/article/hi_there Which also works fine. However, I have a content module that uses urls like this: http://www.example.com/index.php/view/Content-Main/page/index.html Which gives me the following error: Error initializing bind path for index.php/view/Content-Main/page/index.html I see in CVS that there have been some changes in this area (I guess this error would have crashed the server before?). Is there a configuration or something that I can change to make this work? I don't understand why it is happening? There is no problem with this when I use php directly and bypass isapi_fcgi.dll. Thanks. -- Edit this bug report at http://bugs.php.net/?id=38987&edit=1
#38987 [Fbk->Opn]: isapi_fcgi.dll has problems with search engine friendly paths
ID: 38987 User updated by: randy at rcs-comp dot com Reported By: randy at rcs-comp dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Win XP PHP Version: 5.2.0RC4 New Comment: Actually, the error comes from the isapi_fcgi.dll module I believe: http://viewcvs.php.net/viewvc.cgi/fastcgi-isapi/isapi_fcgi/isapi_fcgi.cpp?revision=1.3&view=markup Also, there is another bug dealing with this module that makes me think that PHP developers are working on this module? Here is the reference: http://bugs.php.net/bug.php?id=37448 (The bug is not necessarily related to mine though, just both being caused by isapi_fcgi.dll) Previous Comments: [2006-09-28 22:19:49] [EMAIL PROTECTED] >I see in CVS that there have been some changes in this area What do you mean? >Is there a configuration or something that I can change to make this work? The error message comes from IIS, not PHP, so I have serious doubts we can help you. [2006-09-28 21:33:57] randy at rcs-comp dot com Description: I am using the code (and dll) from here: http://msmvps.com/blogs/guilherme/archive/2006/02/02/82336.aspx on a Windows XP machine with IIS 5.1. It runs well, except for one problem. I use the PATH_INFO information to run scripts that are search engine friendly. So, I can have a path like this: http://www.example.com/index.php/view/News-Main Which works fine. I can also pass other variables like this: http://www.example.com/index.php/view/News-Main/article/hi_there Which also works fine. However, I have a content module that uses urls like this: http://www.example.com/index.php/view/Content-Main/page/index.html Which gives me the following error: Error initializing bind path for index.php/view/Content-Main/page/index.html I see in CVS that there have been some changes in this area (I guess this error would have crashed the server before?). Is there a configuration or something that I can change to make this work? I don't understand why it is happening? There is no problem with this when I use php directly and bypass isapi_fcgi.dll. Thanks. -- Edit this bug report at http://bugs.php.net/?id=38987&edit=1
#38987 [NEW]: isapi_fcgi.dll has problems with search engine friendly paths
From: randy at rcs-comp dot com Operating system: Win XP PHP version: 5.2.0RC4 PHP Bug Type: CGI related Bug description: isapi_fcgi.dll has problems with search engine friendly paths Description: I am using the code (and dll) from here: http://msmvps.com/blogs/guilherme/archive/2006/02/02/82336.aspx on a Windows XP machine with IIS 5.1. It runs well, except for one problem. I use the PATH_INFO information to run scripts that are search engine friendly. So, I can have a path like this: http://www.example.com/index.php/view/News-Main Which works fine. I can also pass other variables like this: http://www.example.com/index.php/view/News-Main/article/hi_there Which also works fine. However, I have a content module that uses urls like this: http://www.example.com/index.php/view/Content-Main/page/index.html Which gives me the following error: Error initializing bind path for index.php/view/Content-Main/page/index.html I see in CVS that there have been some changes in this area (I guess this error would have crashed the server before?). Is there a configuration or something that I can change to make this work? I don't understand why it is happening? There is no problem with this when I use php directly and bypass isapi_fcgi.dll. Thanks. -- Edit bug report at http://bugs.php.net/?id=38987&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38987&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38987&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38987&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38987&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38987&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38987&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38987&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38987&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38987&r=support Expected behavior:http://bugs.php.net/fix.php?id=38987&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38987&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38987&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38987&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38987&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38987&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38987&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38987&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38987&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38987&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38987&r=mysqlcfg
#37448 [Com]: FastCGI Error: Server too busy Server
ID: 37448 Comment by: randy at rcs-comp dot com Reported By: coder1 at gmail dot com Status: No Feedback Bug Type: CGI related Operating System: Windows XP PHP Version: 5.1.4 New Comment: I am requesting that this bug status be changed to "open" since there has been plenty of feedback and until the bug has been confirmed to be fixed. I have also run into this same issue with php > 5.1.4 including the latest 5.1 snapshot. My solution was to use 5.1.2 instead. Previous Comments: [2006-09-07 14:12:36] robert dot sevcik at gmail dot com I'm sorry for spamming, but I went a step further, downgraded to PHP Version 5.1.0-dev and the FastCGI has no problem. Build date Jun 21 2005 12:21:48 [2006-09-07 10:20:42] robert dot sevcik at gmail dot com I tested it with my app, output_buffering doesn't workaround the problem fully. Bigger output still harmes the fastcgi. [2006-09-07 10:13:19] robert dot sevcik at gmail dot com Hello, I confirm, still no go with latest snapshot - 5.2.0RC4-dev, Build Date Sep 7 2006 00:15:28 I tried phpinfo() with CGI only, go Tried the same with isapi_fcgi.dll, no go Then I changed output_buffering=1000 and... GO! :) (Windows 2003 server SP1) [2006-07-30 23:34:14] djohnson241 at gmail dot com Some more information( hopefully useful ). After further testing I was able to determine that this is only happening for me if I output a lot of text at once. If I split it up into a bunch of smaller echo's, it works fine. Unfortunately this doesn't work with my template system, as all output is echoed in one statement. dave [2006-07-30 23:16:36] djohnson241 at gmail dot com I can verify the above experiment. I got the 5.2 snapshot and used the following: ", 131); ?> That works fine. But change the 131 to 132 and you get the 503 error. At a loss. dave 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/37448 -- Edit this bug report at http://bugs.php.net/?id=37448&edit=1
#37892 [NEW]: $obj != null is incorrectly evaluated
From: randy at rcs-comp dot com
Operating system: Win XP Pro
PHP version: 5CVS-2006-06-22 (snap)
PHP Bug Type: *General Issues
Bug description: $obj != null is incorrectly evaluated
Description:
When evaluating an instantiated object with "!=" the result is incorreclty
returned as false;
Reproduce code:
---
echo phpversion();
class foo {
var $test;
}
$obj = new foo();
if( $obj != null ) {
echo "\n\ncorrect";
} else {
echo "\n\nnot correct";
}
Expected result:
D:\tmp>"c:\Program Files\PHP514\php.exe" obj_null.php
5.1.4
correct
Actual result:
--
D:\tmp>php obj_null.php
5.2.0-dev
not correct
--
Edit bug report at http://bugs.php.net/?id=37892&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37892&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37892&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37892&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37892&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37892&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37892&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37892&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37892&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37892&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37892&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37892&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37892&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37892&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37892&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37892&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37892&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37892&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37892&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37892&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37892&r=mysqlcfg
#32938 [NEW]: SQLITE extension vs built in for version 3.x
From: randy at rcs-comp dot com Operating system: Windows PHP version: 5CVS-2005-05-04 (dev) PHP Bug Type: Feature/Change Request Bug description: SQLITE extension vs built in for version 3.x Description: I have read most of the bugs on Sqlite 3.x for PHP. The concencous from the PHP developers appears to be that Sqlite 3.x is not necessary since it will be included in PDO. In addition, 3.x support can be enabled on Linux by recompiling. Unfortunately, I am using Windows. I am sure it is possible to recompile PHP on windows, but it sure doesn't sound like fun. I would like to propose moving SQLite support into an extension for PHP on Windows and compiling a 2.x and 3.x extension. That would allow windows users to use the new libraries without compromising backwards compatability. As for the PDO argument, I think it is important to recognize that a lot of us are using PEAR:DB, ADODB, Creole, etc and that PDO support in these DB abstraction layers may be a while in coming. It would be nice to user their native support for SQLite and get the benefits of 3.x as well. I realize that this is probably beating a dead horse, but I felt my perspective was a little different. Thanks. -- Edit bug report at http://bugs.php.net/?id=32938&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32938&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32938&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32938&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32938&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32938&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32938&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32938&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32938&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32938&r=support Expected behavior: http://bugs.php.net/fix.php?id=32938&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32938&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32938&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32938&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32938&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32938&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32938&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32938&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32938&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32938&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32938&r=mysqlcfg
#29761 [Com]: token_get_all()
ID: 29761
Comment by: randy at rcs-comp dot com
Reported By: steemann at globalpark dot de
Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux 2.4.22
PHP Version: 4.3.8
New Comment:
This might help...
PHP 5.0.2, Apache 2.0.52
Test code:
';
print_r( token_get_all('';
?>
Expected result (I think):
Array
(
[0] => Array
(
[0] => 365
[1] => Array
(
[0] => 308
[1] => $a
)
[2] => =
[3] => Array
(
[0] => 308
[1] => $b
)
[4] => ;
)
Result:
Array
(
[0] => <
[1] => ?
[2] => Array
(
[0] => 307
[1] => php
)
[3] => Array
(
[0] => 369
[1] =>
)
[4] => Array
(
[0] => 309
[1] => $a
)
[5] => =
[6] => Array
(
[0] => 309
[1] => $b
)
[7] => ;
)
Result after restarting Apache:
-
Array
(
[0] => Array
(
[0] => 366
[1] => Array
(
[0] => 309
[1] => $a
)
[2] => =
[3] => Array
(
[0] => 309
[1] => $b
)
[4] => ;
)
Hope it helps...
Previous Comments:
[2004-12-02 17:31:54] fpoeydomenge at free dot fr
Same problem with PHP 5.0.2, but I only get the version where :
T_OPEN_TAG: '<?php '
is replaced by :
<
?
T_STRING: 'php'
[2004-10-19 21:58:52] bloudon at townnews dot com
Bug is reproducible only when tokenizer is loaded dynamically.
If tokenizer is compiled into PHP then the bug does not occur.
Same behavior on Linux 2.4.24 and Linux 2.6.8.1.
[2004-10-04 11:11:22] guth at fiifo dot u-psud dot fr
Same problem with PHP 5.0.*, with any PHP script.
[2004-08-19 17:48:22] steemann at globalpark dot de
Description:
Don't know if it's a tokenizer issue or something else:
I just wanted to check out the token_get_all() function.
I tried the test code from the manual page (see code
below). I am using token_get_all() with a constant input.
Unfortunately, on my box, the result for the test code is
varying, i. e. tokening a constant string has two
different results. I found this out it by simple hitting
reload in the browser multiple times. I've put both
results I've gotten in the "Actual result" textarea. The
possibility for each result seems to be about 50%.
Environment:
Configure Command => './configure'
'--with-apxs=/opt/pdp/apache/bin/apxs'
'--prefix=/opt/pdp/php' '--with-mysql=/opt/pdp/mysql/'
'--with-config-file-path=/opt/pdp/'
'--with-iconv=/opt/pdp/iconv/'
'--with-imagick=/opt/pdp/ImageMagick/' '--with-zlib'
'--with-gd' '--with-freetype-dir=/usr'
'--enable-gd-native-ttf' '--enable-gd-imgstrttf'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-dom'
'--with-dom-xslt' '--with-dom-exslt' '--enable-sysvsem'
'--enable-sysvshm' '--disable-debug' '--enable-sockets'
PHP API => 20020918
PHP Extension => 20020429
Zend Extension => 20021010
Debug Build => no
Thread Safety => disabled
Maybe my box is f**ked up??
Reproduce code:
---
$data="";
foreach(token_get_all($data) as $c)
{
if(is_array($c))
{
print(token_name($c[0]) . ": '".htmlentities($c[1])."'\n");
}
else
{
print("$c\n");
}
}
Expected result:
T_OPEN_TAG: '<?php '
T_STRING: 'ob_start'
(
)
;
T_WHITESPACE: ' '
T_CLOSE_TAG: '?>'
Actual result:
--
In about 50% I get:
<
?
T_STRING: 'php'
T_WHITESPACE: ' '
T_STRING: 'ob_start'
(
)
;
T_WHITESPACE: ' '
T_CLOSE_TAG: '?>'
the other 50% I get:
T_OPEN_TAG: '<?php '
T_STRING: 'ob_start'
(
)
;
T_WHITESPACE: ' '
T_CLOSE_TAG: '?>'
--
Edit this bug report at http://bugs.php.net/?id=29761&edit=1
#31219 [NEW]: mssql_query() returns false on successful database insert or update
From: randy at rcs-comp dot com
Operating system: Windows XP
PHP version: 5.0.3
PHP Bug Type: MSSQL related
Bug description: mssql_query() returns false on successful database insert or
update
Description:
Upon a successful database modification, mssql_query should return true.
However, in 5.0.3, it returns false.
I went back to 5.0.2 and the bug was not present.
Possibly related to: http://bugs.php.net/bug.php?id=31135
Also possibly the same problem as this:
http://bugs.php.net/bug.php?id=31195&edit=2
Although I still posted the bug because the above bug is in a different
PHP version.
Reproduce code:
---
$link = mssql_connect('<>', "<>", "");
mssql_select_db("<>", $link);
$SQL = "INSERT INTO <> VALUES <>";
$rs = mssql_query($SQL, $link);
if (!$rs) {
echo "problem";
} else {
echo "worked";
}
Expected result:
The DB should be updated and "worked" should be displayed
Actual result:
--
The DB is updated and "problem" is displayed
--
Edit bug report at http://bugs.php.net/?id=31219&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31219&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31219&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31219&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31219&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31219&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31219&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31219&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31219&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31219&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31219&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31219&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31219&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31219&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31219&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31219&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31219&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31219&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31219&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31219&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31219&r=mysqlcfg
