Bug #48539 [Csd]: pdo_dblib fails to connect, throws empty PDOException "SQLSTATE[] (null)"
Edit report at https://bugs.php.net/bug.php?id=48539&edit=1 ID: 48539 Updated by: ssuffic...@php.net Reported by:frase at cs dot wisc dot edu Summary:pdo_dblib fails to connect, throws empty PDOException "SQLSTATE[] (null)" Status: Closed Type: Bug Package:PDO related Operating System: * PHP Version:5.2.10, 5.3.0RC4 Assigned To:felipe Block user comment: N Private report: N New Comment: I see that this option is not implemented in FreeTDS dblib.c. Calling DBSETOPT with this option should have no effect and produce no error. Masking it for all libraries except MS DBLIB (depreciated) is not a solution unless the underlying FreeTDS library has a bug. The previous implementation would return exit if DBSETOPT failed, causing the connection to close with an error. The current version does not exit in error if the DBSETOPT returns FAIL. Newer versions should return a more specific error than the "SQLSTATE[] (null) (severity 0)". Please test again and provide the error if you can. I am running Sybase ASE and so cannot accurately reproduce your error with MSSQL. Previous Comments: [2013-09-25 14:55:58] kap...@php.net The following patch has been added/updated: Patch Name: mssql-null-exception Revision: 1380120958 URL: https://bugs.php.net/patch-display.php?bug=48539&patch=mssql-null-exception&revision=1380120958 [2013-05-09 10:15:06] talktome at aboutandrew dot co dot uk This problem exists in php 5.4.10 [2012-12-13 16:08:25] wdmeldon at gmail dot com I've tested this in 5.3.19 and was not able to replicate. [2012-07-13 13:10:20] snowcorenet at gmail dot com Could anyone tell me, please, if this is fixed in php 5.3? [2011-04-11 18:37:18] tom at punkave dot com Did this fix ever get put in PHP 5.3? I am getting this error exactly as originally described with all PHP 5.3.x versions tried. 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 https://bugs.php.net/bug.php?id=48539 -- Edit this bug report at https://bugs.php.net/bug.php?id=48539&edit=1
Bug #42715 [Asn->Csd]: Consistent Connection Failed to MSSQL 2000 server
Edit report at https://bugs.php.net/bug.php?id=42715&edit=1 ID: 42715 Updated by: ssuffic...@php.net Reported by:pradeep at value-one dot com Summary:Consistent Connection Failed to MSSQL 2000 server -Status: Assigned +Status: Closed Type: Bug Package:MSSQL related Operating System: Windows 2003 PHP Version:5.1.5 Assigned To:fmk Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I think we can drop support for SQL Server 2000. It also looks like this was related to a server configuration error. Bug closed. Previous Comments: [2007-12-03 09:50:14] pradeep at value-one dot com Well Soulax I did following to resolve my issues. Hope all these will resolve your issue as well. 1. Synchronize your server time by any INTERNET time servers. Then restart your server so that time will synchronized between your database server and web server. 2. You need to patch your SQL Server 2000 with latest Service Packs at least SP4. 3. You may require Windows 2003 Service Pack 2 for IIS6 issues. 4. After above patching, restart your server. 5. You need to have Updated MSSQL Client Library which has not shipped with default PHP package. you can download this library from http://webzila.com/dll/1/ntwdblib.zip. Replace existing NTWDBLIB.DLL from your PHP folder with downloaded file. Hope doing all step will work. :-) [2007-11-30 21:39:44] soulax at email dot com Any updates on this? Im having the same exact symptom. (Web Server) OS: Windows 2003 PHP: 5.2.4 WEB SERVER: IIS6 trying to connect to a Windows 2003 box on the LAN running SQL SERVER 2000 via mssql. It works, then doesn't connect, then works, and so on and so forth. It used to work fine, perhaps some windows updates caused this? I know im using a mish mash of OS's and App's, but it's all i have available via my IT department. [2007-10-02 15:06:16] pradeep at value-one dot com Most ppl from community has told me that the debug builds are not a GOOD CHOICE for production applications (or say mission critical). May I know when this bug been resolved in stable version(s)? In addition, in my previous working I rolled back my all windows 2003 pactches (SP2 and Security Patches) then again SQL Server is able to communicate with PHP while I think all these patches are very essential for my server. What is the HACK? What I had missed or which service or patch creating this problem? I appreciate if someone could work on it. [2007-09-22 15:30:48] pradeep at value-one dot com Thanks Jani I had already implemented PHP 5.2.4 Snapshot of developer build dated 19 September, 5:00PM but I face the same problem. The problem still lying but when I move my database server from this machine to another machine (i.e. Install and restore my MSSQL 2000 databases to different machine) then all works fine with my previous PHP as well as suggested PHP debug build (latest snapshot). I am wondering what is the exact cause of problem? if this is PHP bug then why is it not repeating when both Web Server (IIS) and Database Server (MSSQL) are on different machine. One more question, Is this debug build affect my production application (critical for my enterprise) or Does any debug build have any security vulnerability? I am asking this because right now my application running with suggested Snapshot build. [2007-09-21 09:07:34] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi 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 https://bugs.php.net/bug.php?id=42715 -- Edit this bug report at https://bugs.php.net/bug.php?id=42715&edit=1
Req #57593 [Asn->Csd]: PDO_DBLIB does not implement nextRowset
Edit report at https://bugs.php.net/bug.php?id=57593&edit=1
ID: 57593
Updated by: ssuffic...@php.net
Reported by:ur...@php.net
Summary:PDO_DBLIB does not implement nextRowset
-Status: Assigned
+Status: Closed
Type: Feature/Change Request
-Package:PDO_DBLIB
+Package:*General Issues
Operating System: CentOS 4 i386
PHP Version:5.1.6
Assigned To:fmk
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-03-27 17:33:31] ur...@php.net
Description:
The php-mssql extension implements the nextRowset feature to advance to the
next result set from a query. the current PDO_DBLIB does not provide this
functionality.
Reproduce code:
---
$db = new PDO("dblib:host=host:1433;dbname=tempdb","user","pass");
$sql = <execute();
$row = $res->fetch(PDO::FETCH_NUM);
while ($row = $res->fetch(PDO::FETCH_NUM)
|| ($res->nextRowset() && $row = $res->fetch(PDO::FETCH_NUM))) {
echo $res->columnCount().':';
echo implode(',',$row)."\n";
}
Expected result:
1:1
1:2
1:3
Actual result:
--
PDOStatement::nextRowset(): SQLSTATE[IM001]: Driver does not support this
function: driver does not support multiple rowsets in nextresult-pdo.php on
line 34
--
Edit this bug report at https://bugs.php.net/bug.php?id=57593&edit=1
Req #46575 [Opn->Bgs]: NULL comparison when using "not in" not consistent with Windows SQL
Edit report at https://bugs.php.net/bug.php?id=46575&edit=1
ID: 46575
Updated by: ssuffic...@php.net
Reported by:ben at thelocust dot org
Summary:NULL comparison when using "not in" not consistent
with Windows SQL
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package:MSSQL related
Operating System: *
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2011-12-01 05:20:03] ssufficool at gmail dot com
This is a behavior set by the MSSQL "ANSI NULLS" setting. Depending if ANSI
NULLS is on or off, it will return the NULL for the NOT IN selection.
This is a server setting, not a PHP setting.
Try issuing a "SET ANSI_NULLS ON" before the query using both VBScript and PHP.
The behavior should then be the same.
[2009-01-07 18:17:08] ka...@php.net
I don't see the error here, your asking SQL server to return 'test_id' from the
table 'test' where 'test_number' doesn't even to 1 or 2, and since NULL is
different from 1 and 2 then why shouldn't it be returned? I see that more of a
bug in the ASP/VBScript drivers, and I don't think we should put such an
inconsistency into because others do it.
I changed the category of this to a Feature/Change request, letting the
extension maintainer decided whenever to do it or not :)
[2008-11-14 16:35:50] ben at thelocust dot org
Description:
When querying a MSSQL database table, and using the "not in" syntax, PHP's
mssql_query will also return rows with NULL in the field specified.
Reproduce code:
---
SQL Server 2000 or 2005
Table "test"
test_id (int) test_name (vchar)test_number (int)
1 Foo 1
2 Bar 2
3 3
4 Baz
$sql = "select test_id from test where test_number not in (1,2)";
$res = mssql_query($sql);
while ($row = mssql_fetch_array($res)) {
?>
https://bugs.php.net/bug.php?id=46575&edit=1
Bug #55291 [Opn->Bgs]: All ODBC Queries Return INTs as Strings For Multiple ODBC Drivers
Edit report at https://bugs.php.net/bug.php?id=55291&edit=1
ID: 55291
Updated by: ssuffic...@php.net
Reported by:brandonkirsch at gmail dot com
Summary:All ODBC Queries Return INTs as Strings For Multiple
ODBC Drivers
-Status: Open
+Status: Bogus
Type: Bug
Package:ODBC related
Operating System: SUSE SLES 10 SP2
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Most database layers convert numeric values to strings to preserve their
precision as PHP does not support all numeric precisions which a database might
(i.e. 64 bit integers). Since strings may be silently converted to numeric in
PHP ("1" + 2 = 3), this should not pose too much of an issue.
Previous Comments:
[2011-07-26 21:44:49] brandonkirsch at gmail dot com
Description:
odbc_* and PDO ODBC functions are each returning SQL integer values as PHP
strings. However, SQL NULL values properly appear as PHP NULL values.
I have tested against multiple ODBC providers (FreeTDS and iSeries Access for
Linux).
System:
SUSE Enterprise Linux Server 10 (SP2) - 32bit
Linux dev-webhost1 2.6.16.60-0.42.5-default #1 Mon Aug 24 09:41:41 UTC 2009
i686
i686 i386 GNU/Linux
UnixODBC
PHP 5.3.6 from source
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-
mssql=/usr/local/freetds --with-ldap --prefix=/usr/local/php5 --with-config-
file-
path=/usr/local/php5/etc --enable-sockets --enable-soap --with-openssl --with-
unixODBC=/usr --with-gd --with-jpeg-dir=/usr/lib --with-pdo-odbc=unixODBC,/usr
Test script:
---
1. odbc_* against FreeTDS to SQL Server 2008:
$odbc = odbc_connect('hpsql3','--censored--','--censored--');
$or = odbc_exec($odbc,'SELECT 1');
var_dump(odbc_fetch_array($or)); // array( string "1" )
2. odbc_* against iSeries Access for Linux to AS/400:
$odbc = odbc_connect('iSeriesDSN','--','--');
$or = odbc_exec($odbc,'SELECT 1 FROM SYSIBM.SYSDUMMY1');
var_dump(odbc_fetch_array($or)); // array( string "1" )
3. PDO against FreeTDS to SQL Server 2008
$pdo = new PDO('odbc:hpsql3','--','--');
var_dump($pdo->query('SELECT 1')->fetch(PDO::FETCH_ASSOC)); // array (string
"1")
4. PDO against iSeries Access for Linux to AS/400
$pdo = new PDO('odbc:iSeriesDSN','--','--');
var_dump($pdo->query('SELECT 1 FROM
SYSIBM.SYSDUMMY1')->fetch(PDO::FETCH_ASSOC)); // array (string "1")
Expected result:
I expect to get arrays containing (int) 1
Actual result:
--
I actually get arrays containing (string) "1"
--
Edit this bug report at https://bugs.php.net/bug.php?id=55291&edit=1
Bug #55784 [Opn->Csd]: Missing transaction support in pdo-dblib
Edit report at https://bugs.php.net/bug.php?id=55784&edit=1 ID: 55784 Updated by: ssuffic...@php.net Reported by:wrobel at wsb-nlu dot edu dot pl Summary:Missing transaction support in pdo-dblib -Status: Open +Status: Closed Type: Bug Package:PDO related PHP Version:5.3.8 -Assigned To: +Assigned To:ssufficool Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Try 5.4 RC2 Previous Comments: [2011-09-26 11:15:23] wrobel at wsb-nlu dot edu dot pl Description: Fix to bug #38955 - "add transaction support" was not merged into PHP 5.2 or 5.3 for over a year now! http://svn.php.net/viewvc/?view=revision&revision=300628 -- Edit this bug report at https://bugs.php.net/bug.php?id=55784&edit=1
Req #58600 [Opn->Csd]: Support for transactions -mssql
Edit report at https://bugs.php.net/bug.php?id=58600&edit=1
ID: 58600
Updated by: ssuffic...@php.net
Reported by:sigurdne at online dot no
Summary:Support for transactions -mssql
-Status: Open
+Status: Closed
Type: Feature/Change Request
-Package:PDO_DBLIB
+Package:*General Issues
Operating System: Ubuntu 8.10
PHP Version:5.2.6
-Assigned To:
+Assigned To:ssufficool
Block user comment: N
Private report: N
New Comment:
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
Try 5.4 RC2
Previous Comments:
[2009-03-30 02:26:16] sigurdne at online dot no
By looking at the pdo_mysql - it looks like something like this could work.
However there seems to be a problem that the transaction state is not reported
correctly - so when it comes to the commit - it claims that it is not in a
transaction.
Anyone that could help out?
diff -aburN --exclude='.svn*' --exclude='CVS*' PDO_DBLIB-1.0.org/dblib_driver.c
PDO_DBLIB-1.0/dblib_driver.c
--- PDO_DBLIB-1.0.org/dblib_driver.c2005-10-16 16:58:50.0 +0200
+++ PDO_DBLIB-1.0/dblib_driver.c2009-03-27 13:10:14.0 +0100
@@ -166,14 +166,30 @@
return 1;
}
+static int dblib_handle_begin(pdo_dbh_t *dbh TSRMLS_DC)
+{
+ return 0 <= dblib_handle_doer(dbh, ZEND_STRL("BEGIN TRAN") TSRMLS_CC);
+}
+
+static int dblib_handle_commit(pdo_dbh_t *dbh TSRMLS_DC)
+{
+ return 0 <= dblib_handle_doer(dbh, ZEND_STRL("COMMIT TRAN") TSRMLS_CC);
+}
+
+static int dblib_handle_rollback(pdo_dbh_t *dbh TSRMLS_DC)
+{
+ return 0 <= dblib_handle_doer(dbh, ZEND_STRL("ROLLBACK TRAN")
TSRMLS_CC);
+}
+
+
static struct pdo_dbh_methods dblib_methods = {
dblib_handle_closer,
dblib_handle_preparer,
dblib_handle_doer,
dblib_handle_quoter,
- NULL,
- NULL,
- NULL,
+ dblib_handle_begin,
+ dblib_handle_commit,
+ dblib_handle_rollback,
NULL,
NULL, /* last insert */
dblib_fetch_error, /* fetch error */
[2009-03-27 04:57:32] sigurdne at online dot no
Description:
Would be nice to support transactions for mssql.
Tried both the precompiled ubuntu packages and custom built from pecl with the
same result:
'This driver doesn't support transactions'
Cutom built:
versions:
* PDO-1.0.3
* PDO_DBLIB-1.0
* FreeTDS 0.82
To allow configure to work:
$ touch /usr/include/tds.h
$ touch /usr/lib/libtds.a
configure:
$ ./configure --with-mssql
Reproduce code:
---
$this->db = new PDO("dblib:host={$this->Host};dbname={$this->Database}",
$this->User, $this->Password, array(PDO::ATTR_PERSISTENT => $persistent));
$this->db->beginTransaction();
Actual result:
--
Error message: 'This driver doesn't support transactions'
--
Edit this bug report at https://bugs.php.net/bug.php?id=58600&edit=1
Bug #57045 [Opn->Bgs]: PDO_DBLIB install problem
Edit report at https://bugs.php.net/bug.php?id=57045&edit=1 ID: 57045 Updated by: ssuffic...@php.net Reported by:foxiii at korea dot com Summary:PDO_DBLIB install problem -Status: Open +Status: Bogus Type: Bug -Package:PDO_DBLIB +Package:*General Issues Operating System: CentOS 4.3 PHP Version:5_1 CVS-2006-05-29 Block user comment: N Private report: N New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. The built in PDO extension in 5.4 should be more feature complete and have less bugs. The PECL extension is over 6 years old. Previous Comments: [2010-06-16 16:30:57] liam at morland dot ca Another solution: pecl install -n pdo_dblib The -n makes it skip dependencies. [2009-02-03 12:24:38] camden dot michael at gmail dot com I had this same issue, and since it was reported about 2 years ago with no movement, it doesn't seem like the developers are going to work on this anytime soon. I was able to "fix" this issue, by downloading the pdo_dblib pecl extension, removing the pdo 1.0 dependency, and installing from my local copy. Here are the steps I took, pecl download pdo_dblib This will download a tar ball of the extension. Extract the tar ball. tar -xzvf PDO_DBLIB-*.tgz That will uncompress the package in to a standalone file, package.xml and a folder containing the extension, in my case it was, PDO_DBLIB-X.X. Where X was the version number. Open package.xml using your favourite command line editor. Find and remove the line, pdo Save the package.xml file, and move it in to the PDO_DBLIB directory. mv package.xml ./PDO_DBLIB-X.X Navigate to the PDO_DBLIB directory, then install the package from the directory. You may need root access for this step. cd PDO_DBLIB-X.X PHP_PDO_SHARED=1 pecl install package.xml [2006-05-29 04:12:18] foxiii at korea dot com . [2006-05-29 03:49:23] foxiii at korea dot com Oh.. not match package field. [2006-05-29 03:45:27] foxiii at korea dot com Description: PDO_DBLIB install problem. I required PDO for MSSQL. So, I install PHP 5.1.4 (--enable-pdo=shared) but, I can't show complete message on install PDO_DBLIB, showed message "pear/PDO_DBLIB requires PHP extension "pdo" (version >= 1.0)" == ./pecl upgrade PDO = is OK ./pecl upgrade PDO_SQLITE = is OK ./pecl upgrade PDO_DBLIB= failed == == [root@devserv bin]# ./pecl list-all ALL PACKAGES: = PACKAGELATEST LOCAL pecl/PDO1.0.3 PHP Data Objects Interface pecl/PDO_SQLITE 1.0.1 SQLite v3 Interface driver for PDO == == [root@devserv bin]# rpm -qa | grep freetds freetds-0.63-1.2.el4.rf == Result, I installed PDO1.0.3, but, PDO_DBLIB want PDO>=1.0. I installed PDO_SQLITE nothing any error, just has problem on PDO_DBLIB... Plz, solve it. -- Edit this bug report at https://bugs.php.net/bug.php?id=57045&edit=1
Bug #38805 [Opn->]: PDO Truncates Text from SQL Server Text Data Type Field
Edit report at https://bugs.php.net/bug.php?id=38805&edit=1
ID: 38805
Updated by: ssuffic...@php.net
Reported by:gkrajci at arescorporation dot com
Summary:PDO Truncates Text from SQL Server Text Data Type
Field
-Status: Open
+Status: To be documented
Type: Bug
Package:PDO related
Operating System: Windows NT PBMA-WB2 5.2 build 37
PHP Version:5.1.6
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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.
Previous Comments:
[2010-12-17 21:07:48] ka...@php.net
.
[2010-03-04 20:55:06] juan dot pineda at resultstel dot com
I solved this problem by adding to my php script a TEXTSIZE that is less than
the allowed memory from the MSSQL server.
Remember, all the number are in Bytes, so I kept playing with the numbers,
until this worked:
// ranges from 0 - 3145728 = 3Megabytes. Default to 4096.
$sql = "SET TEXTSIZE 3145728";
mssql_query($sql, $db) or die(mssql_get_last_message());
Remember to always know what the allowed upload size for your server is.
I hope this helps someone
[2010-02-12 16:57:02] s...@php.net
Those changes are still in SVN. That means the TEXTLIMIT var is being set to
its highest possible value, which in turn means that truncation shouldn't be an
issue now.
$pdo->query('SET TEXTSIZE 30');
should work from PHP 5.2.11 up, it just needs doccing.
[2010-02-12 09:05:28] philipp at servicemail24 dot de
This problem is actually fixed in cvs:
http://www.mail-archive.com/php-cvs@lists.php.net/msg40731.html
http://www.mail-archive.com/php-cvs@lists.php.net/msg40711.html
Here is the working source code:
http://cvs.php.net/viewvc.cgi/php-src/ext/pdo_dblib/
I have no idea why these fixes aren't included in the 5.2 and 5.3 releases!
@sfox can you ensure that pdo_dblib is updated with the release of 5.2.13 and
5.3.2?
[2010-02-11 15:40:43] philipp at servicemail24 dot de
php 5.3.2 dotdeb still suffers from this problem.
does this fix help?
"Possible fix: remove "case SQLTEXT" from
ext/pdo_dblib/dblib_stmt.c:execute and let it fall though to default."
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
https://bugs.php.net/bug.php?id=38805
--
Edit this bug report at https://bugs.php.net/bug.php?id=38805&edit=1
Bug #60122 [Opn]: Many multi-row statements gives wrong result
Edit report at https://bugs.php.net/bug.php?id=60122&edit=1
ID: 60122
Updated by: ssuffic...@php.net
Reported by:armiksos at gmail dot com
Summary:Many multi-row statements gives wrong result
Status: Open
Type: Bug
Package:PDO related
Operating System: windows 7
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Which driver are you using (i.e. MySQL, PostgreSQL, DBLIB, SqlServer?)
Previous Comments:
[2011-10-24 14:49:39] armiksos at gmail dot com
Description:
If you create two query of multi-row statements in one .php file and you assign
them
to the same variable after processing one of them, the second query will give
only
result of only ONE statement.
If you assign the result of query to another variable, the result will be
correct.
So$another_var_name = $conn->query("SELECT 1 as one; SELECT 2 as two;
SELECT 3
as three;");
will work in Test script, otherwise result will be wrong.
Test script:
---
$q = $conn->query("SELECT 1 as one; SELECT 2 as two; SELECT 3 as
three;");
do
{
$r=$q->fetchAll(PDO::FETCH_ASSOC);
echo "";
print_r($r);
}while($q->nextRowset());
$q = $conn->query("SELECT 1 as one; SELECT 2 as two; SELECT 3 as
three;");
do
{
$r=$q->fetchAll(PDO::FETCH_ASSOC);
echo "";
print_r($r);
}while($q->nextRowset());
Expected result:
Array ( [0] => Array ( [one] => 1 ) )
Array ( [0] => Array ( [two] => 2 ) )
Array ( [0] => Array ( [three] => 3 ) )
Array ( [0] => Array ( [one] => 1 ) )
Array ( [0] => Array ( [two] => 2 ) )
Array ( [0] => Array ( [three] => 3 ) )
Actual result:
--
Array ( [0] => Array ( [one] => 1 ) )
Array ( [0] => Array ( [two] => 2 ) )
Array ( [0] => Array ( [three] => 3 ) )
Array ( [0] => Array ( [one] => 1 ) )
--
Edit this bug report at https://bugs.php.net/bug.php?id=60122&edit=1
Bug #54908 [Opn->Fbk]: DBLIB segfaults when GROUPing with 0 rows for prepared statements
Edit report at https://bugs.php.net/bug.php?id=54908&edit=1
ID: 54908
Updated by: ssuffic...@php.net
Reported by:StevenHadfield at letu dot edu
Summary:DBLIB segfaults when GROUPing with 0 rows for
prepared statements
-Status: Open
+Status: Feedback
Type: Bug
Package:PDO related
Operating System: Fedora Rawhide
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
PDO_DBLIB has been significantly redesigned in PHP 5.4. Many memory allocations
were removed possibly resolving this issue.
Previous Comments:
[2011-05-23 15:25:45] StevenHadfield at letu dot edu
gdb backtrace:
#0 _zend_mm_free_int (heap=0xb2c310, p=0xe1b868) at
/usr/src/debug/php-5.3.6/Zend/zend_alloc.c:2028
#1 0x7fffef1d1b1e in free_statement (stmt=0xe1bb70) at
/usr/src/debug/php-5.3.6/ext/pdo/pdo_stmt.c:2410
#2 0x005d0f3f in zend_objects_store_del_ref_by_handle_ex (handle=2,
handlers=)
at /usr/src/debug/php-5.3.6/Zend/zend_objects_API.c:220
#3 0x005d0f63 in zend_objects_store_del_ref (zobject=0xe1aa08) at
/usr/src/debug/php-5.3.6/Zend/zend_objects_API.c:172
#4 0x005a09f2 in _zval_dtor (zvalue=) at
/usr/src/debug/php-5.3.6/Zend/zend_variables.h:35
#5 _zval_ptr_dtor (zval_ptr=0xe1c170) at
/usr/src/debug/php-5.3.6/Zend/zend_execute_API.c:443
#6 _zval_ptr_dtor (zval_ptr=0xe1c170) at
/usr/src/debug/php-5.3.6/Zend/zend_execute_API.c:432
#7 0x005bb931 in zend_hash_del_key_or_index (ht=0x939ec8,
arKey=, nKeyLength=, h=,
flag=) at /usr/src/debug/php-5.3.6/Zend/zend_hash.c:500
#8 0x0062b36a in ZEND_UNSET_VAR_SPEC_CV_HANDLER
(execute_data=0x7fffeb09c050) at
/usr/src/debug/php-5.3.6/Zend/zend_vm_execute.h:22511
#9 0x005d1e2b in execute (op_array=0xe1b260) at
/usr/src/debug/php-5.3.6/Zend/zend_vm_execute.h:107
#10 0x71e78d6d in xdebug_execute (op_array=0xe1b260) at
/usr/src/debug/php-pecl-xdebug-2.1.1/xdebug-2.1.1/xdebug.c:1268
#11 0x005affb0 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.6/Zend/zend.c:1194
#12 0x0055d3b3 in php_execute_script (primary_file=0x7fffdd20) at
/usr/src/debug/php-5.3.6/main/main.c:2268
#13 0x0042486e in main (argc=2, argv=0x7fffdf28) at
/usr/src/debug/php-5.3.6/sapi/cli/php_cli.c:1193
[2011-05-23 15:21:06] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2011-05-23 15:18:04] StevenHadfield at letu dot edu
Description:
I haven't fully figured out the cause of this problem, but for what I can
narrow it down, it's a bit of a remote case.
What I am experiencing is odd behavior when doing a PDO(DBLIB) prepared
statement on a SELECT query with a GROUP BY clause. As far as I can tell, when
the query would have returned 0 results, the query returns an empty array, but
the next time the query is run, I get the following result (regardless of what
the data should actually be):
array(1) {
[0]=>
array(2) {
["!"]=>
NULL
[0]=>
NULL
}
}
After this occurs, any attempt (whether explicit or implicit) to unset the
statement results in a segfault in Zend/zend_alloc.c:2028:
if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
I have also found that this only happens when the first execution of the
prepared statement results in a 0 row query. If the order of the execution in
the test script below is reversed so that a result is returned, the prepared
statement works fine from then on.
Another specific of this bug is that it only occurs with the GROUP BY clause.
The query will work fine if I have an aggregate function, but do not have the
GROUP BY column specified.
I have tried the query in a different query tool, and it works fine.
I also tried the script with the php5.3-201105231230 snapshot, but was still
having the issue.
This problem is similar to Bug #40639, but my problem seems more narrow in
focus. I also do not receive the same segfault as the other bug.
Test script:
---
prepare('SELECT COALESCE(SUM(tblTransaction.Amount), 0) FROM
tblTransaction INNER JOIN tblDiscount ON tblTransaction.Trans
Bug #56081 [Opn->Fbk]: header files not installed + dependencies
Edit report at https://bugs.php.net/bug.php?id=56081&edit=1 ID: 56081 Updated by: ssuffic...@php.net Reported by:matt at kynx dot org Summary:header files not installed + dependencies -Status: Open +Status: Feedback Type: Bug -Package:PDO +Package:*General Issues Operating System: RedHat 9 PHP Version:5CVS-2004-05-30 (dev) Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2004-05-30 10:19:59] matt at kynx dot org Description: Seems that the header files (in particular php_pdo_driver.h) were not installed with the package. This caused installation of the drivers to fail. Workaround was to manually copy the header files from the tar archive to: /usr/local/include/php/ext/pdo. Also pdo_mysql-1.0.tgz falsely reports "PHP version >= 5.0.0 is required" and had to be installed with --nodeps. Can't wait to start using this! Reproduce code: --- pear install PDO-0.1.1.tgz pear install --nodeps pdo_mysql-0.1.tgz Expected result: Build process completed successfully Installing 'pdo_mysql.so' at ext_dir (/usr/local/lib/php/20040412/pdo_mysql.so) install ok: pdo_mysql 0.1 Actual result: -- configure: error: Cannot find php_pdo_driver.h. `/tmp/tmpUfBBnG/pdo_mysql-0.1/configure' failed -- Edit this bug report at https://bugs.php.net/bug.php?id=56081&edit=1
Bug #56150 [Opn->Fbk]: PDOException - [2017] Can't open named pipe...
Edit report at https://bugs.php.net/bug.php?id=56150&edit=1
ID: 56150
Updated by: ssuffic...@php.net
Reported by:dan at yes dot lt
Summary:PDOException - [2017] Can't open named pipe...
-Status: Open
+Status: Feedback
Type: Bug
-Package:PDO
+Package:*General Issues
Operating System: Win2k
PHP Version:5CVS-2004-07-29 (dev)
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2004-11-08 12:06:58] vincent at 7oqp dot net
pdo_mysql try to connect to mysql with unix socket if you enter "localhost" as
hostname.
Use ip address (127.0.0.1) instead of hostname (localhost) :
$db = new PDO('mysql:dbname=test;host=127.0.0.1', 'user', 'password');
It worked for me on XP.
[2004-07-29 18:19:48] dan at yes dot lt
Description:
Fatal error: Uncaught exception 'PDOException' with message '[2017] Can't open
named pipe to host: . pipe: MySQL (2)' in ...
Reproduce code:
---
$db = new PDO('mysql:dbname=test;host=localhost', 'user', 'password');
--
Edit this bug report at https://bugs.php.net/bug.php?id=56150&edit=1
Bug #56158 [Opn->Fbk]: PDO OCI - could not find driver
Edit report at https://bugs.php.net/bug.php?id=56158&edit=1 ID: 56158 Updated by: ssuffic...@php.net Reported by:marcin at matysiak at raiffeisen dot pl Summary:PDO OCI - could not find driver -Status: Open +Status: Feedback Type: Bug -Package:PDO_OCI +Package:*General Issues Operating System: WINXP PHP Version:5.0.0b1 (beta1) Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2004-12-07 10:48:10] jan dot reitz at lanxess dot com try writing the "OCI:" in lowercase, i tried it here and it stopped working when i wrote it in uppercase [2004-08-06 04:33:02] marcin at matysiak at raiffeisen dot pl Description: I hava a simple problem. If try use PDO for ORACLE - constructor give me an exception. "could not find driver" Thanks for help... Marcin Matysiak System WinXP Apache 2.0 PHP 5.0 pdo support - enabled PDO Driver for OCI 8 and later - enabled ORACLE 9i client Reproduce code: --- getMessage(); } ?> Actual result: -- could not find driver -- Edit this bug report at https://bugs.php.net/bug.php?id=56158&edit=1
Bug #56220 [Opn->Fbk]: connecting pdo with problem
Edit report at https://bugs.php.net/bug.php?id=56220&edit=1 ID: 56220 Updated by: ssuffic...@php.net Reported by:h_lookzadeh at yahoo dot com Summary:connecting pdo with problem -Status: Open +Status: Feedback Type: Bug -Package:PDO_OCI +Package:*General Issues Operating System: winxp PHP Version:5.0.0b1 (beta1) Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2004-12-07 10:52:38] jan dot reitz at lanxess dot com the string you pasted in your bug report has a "0" (ZERO) instead of an "O" (as the first Character of "Object") try to edit your php.ini replacing PD0 with PDO. [2004-10-25 05:13:56] h_lookzadeh at yahoo dot com Description: I use PHP5.0.5 & apache 2.0 on winxp when start apache the error is: PHP startup : Unable to load dynamic library 'c:\php\ext\php_pd0_oci.dll'-%1 is not a valid win32 application. PHP startup : Unable to load dynamic library 'c:\php\ext\php_oci8.dll'-the specified procedure could not be found. -- Edit this bug report at https://bugs.php.net/bug.php?id=56220&edit=1
Req #37839 [Opn]: Limit of returned rows
Edit report at https://bugs.php.net/bug.php?id=37839&edit=1
ID: 37839
Updated by: ssuffic...@php.net
Reported by:rael at grad dot icmc dot usp dot br
Summary:Limit of returned rows
Status: Open
Type: Feature/Change Request
Package:PDO related
Operating System: Any
PHP Version:5.1.4
Block user comment: N
Private report: N
New Comment:
This same effect is achievable using the fetch method with the offset argument
and limiting the results in your fetch loop.
It could be argued the offset and limit arguments should be added to the
fetchAll() method though.
Previous Comments:
[2006-06-18 17:17:06] rael at grad dot icmc dot usp dot br
Description:
A PDO method for limit the number of rows returned from a query, independent of
the used DBMS. This feature is available in DBMS abstraction packages, like
ADODB (and in Java JDBC too). Something like this:
function setLimit($limit, $offset);
Reproduce code:
---
$con = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
$stmt = $con->prepare("SELECT * FROM table");
$stmt->setLimit(10, 2);
Expected result:
10 tableresults starting from position 2
Actual result:
--
Function not exists yet.
--
Edit this bug report at https://bugs.php.net/bug.php?id=37839&edit=1
Bug #60818 [Opn]: Problem storing UTF data
Edit report at https://bugs.php.net/bug.php?id=60818&edit=1 ID: 60818 Updated by: ssuffic...@php.net Reported by:wrobel at wsb-nlu dot edu dot pl Summary:Problem storing UTF data Status: Open Type: Bug Package:PDO related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This will require a re-write of the PDO_DBLIB to allow the use of the "encoding" option. After that, all queries and parameter will require you to encode them before binding with utf8_encode(). You will also have to decode them using utf8_decode() when returned from the server. I was working to bring full Unicode support to the driver, but it would have broken so much code I had to rethink the strategy. Previous Comments: [2012-01-24 11:32:39] redman dot naw at gmail dot com Hi, -you should use utf8_decode to convert UTF8 character to ISO-8859-1(latin-1) character - i use this function with MySQL, that's work :D [2012-01-20 12:04:20] wrobel at wsb-nlu dot edu dot pl Description: I have a problem storing UTF data on MSSQL using pdo_dblib. In the following query: EXECUTE p_proc id = :id, @name = :name I cannot bind the ":name" param using the N'string' notation required by SQL Server (see http://support.microsoft.com/kb/239530) You cannot get around this by typing: EXECUTE p_proc id = :id, @name = N:name because binding fails on N:name The same problem happens with qoute function - it allways quotes with '' a never with N'' - perhaps there should be a new param like PDO::PARAM_STR to tell that with deal with a Unicode value? -- Edit this bug report at https://bugs.php.net/bug.php?id=60818&edit=1
Bug #64522 [Opn]: After first query to MSSQL (DBLIB) all the other queries return null values
Edit report at https://bugs.php.net/bug.php?id=64522&edit=1
ID: 64522
Updated by: ssuffic...@php.net
Reported by:capile at tecnodz dot com
Summary:After first query to MSSQL (DBLIB) all the other
queries return null values
Status: Open
Type: Bug
Package:PDO related
Operating System: Ubuntu Linux
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
The issue may be the way the cursor closer is implemented. It frees the column
metadata but I can't find where it is reallocated for the next statement. This
may be allocated in PDO core. I remember writing tests, but they did not call
"$stmt->closeCursor();". Does your script work without the closeCursor()?
I have no way to test anymore since I do not have an SQL/Sybase server to
connect to. :(
Previous Comments:
[2013-05-28 17:19:11] mneyman at yesco dot com
Also tested on Ubuntu 12.04 with PHP 5.4.15 and it does not work
[2013-03-26 18:44:16] capile at tecnodz dot com
Downgraded PHP on Ubuntu 12.10 to 5.3.10 and now it works. I also noticed that
cursors are closed at each statement/query/exec.
[2013-03-26 18:24:57] capile at tecnodz dot com
Description:
After first statement/query/exec (successful or not) all the other statements
return null as a result. There's nothing relevant in the
PDOStatement::errorInfo().
Occurs no matter if the statement cursor was closed or not.
Tested on:
* Ubuntu 12.10 with both PHP 5.4.6 and 5.4.13 (doesn't work)
* Ubuntu 13.04 with PHP 5.4.9 (doesn't work)
* Ubuntu 12.04 with PHP 5.3.10 (works)
All the installations were made with apt-get (PHP 5.4.13 from
http://ppa.launchpad.net/ondrej/php5/ubuntu).
All of them use the PDO version 1.0.4dev (got with `php --re pdo`)
Test script:
---
$pdo=new PDO('dblib:host=db;dbname=admin;charset=UTF-8',$username,$password);
$statement=$pdo->query('select 1+1 as result');
print_r($statement->fetchAll());
$statement->closeCursor();
$statement=$pdo->query('select 1+1 as result');
print_r($statement->fetchAll());
Expected result:
Array
(
[0] => Array
(
[result] => 2
[0] => 2
)
)
Array
(
[0] => Array
(
[result] => 2
[0] => 2
)
)
Actual result:
--
Array
(
[0] => Array
(
[result] => 2
[0] => 2
)
)
Array
(
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64522&edit=1
Bug #64522 [Opn]: After first query to MSSQL (DBLIB) all the other queries return null values
Edit report at https://bugs.php.net/bug.php?id=64522&edit=1
ID: 64522
Updated by: ssuffic...@php.net
Reported by:capile at tecnodz dot com
Summary:After first query to MSSQL (DBLIB) all the other
queries return null values
Status: Open
Type: Bug
Package:PDO related
Operating System: Ubuntu Linux
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
I installed Sybase Adaptive Server and was able to reproduce. A workaround is
to
do a $statement=null and then reuse the $statement variable. This calls the
statement destructor in addition to the cursorCloser().
This may be something new to the PDO core. From what I can see on git, no
changes
have been made to pdo_dblib since it was last working. I will continue to look
into this.
Previous Comments:
[2013-05-29 02:38:18] ssuffic...@php.net
The issue may be the way the cursor closer is implemented. It frees the column
metadata but I can't find where it is reallocated for the next statement. This
may be allocated in PDO core. I remember writing tests, but they did not call
"$stmt->closeCursor();". Does your script work without the closeCursor()?
I have no way to test anymore since I do not have an SQL/Sybase server to
connect to. :(
[2013-05-28 17:19:11] mneyman at yesco dot com
Also tested on Ubuntu 12.04 with PHP 5.4.15 and it does not work
[2013-03-26 18:44:16] capile at tecnodz dot com
Downgraded PHP on Ubuntu 12.10 to 5.3.10 and now it works. I also noticed that
cursors are closed at each statement/query/exec.
[2013-03-26 18:24:57] capile at tecnodz dot com
Description:
After first statement/query/exec (successful or not) all the other statements
return null as a result. There's nothing relevant in the
PDOStatement::errorInfo().
Occurs no matter if the statement cursor was closed or not.
Tested on:
* Ubuntu 12.10 with both PHP 5.4.6 and 5.4.13 (doesn't work)
* Ubuntu 13.04 with PHP 5.4.9 (doesn't work)
* Ubuntu 12.04 with PHP 5.3.10 (works)
All the installations were made with apt-get (PHP 5.4.13 from
http://ppa.launchpad.net/ondrej/php5/ubuntu).
All of them use the PDO version 1.0.4dev (got with `php --re pdo`)
Test script:
---
$pdo=new PDO('dblib:host=db;dbname=admin;charset=UTF-8',$username,$password);
$statement=$pdo->query('select 1+1 as result');
print_r($statement->fetchAll());
$statement->closeCursor();
$statement=$pdo->query('select 1+1 as result');
print_r($statement->fetchAll());
Expected result:
Array
(
[0] => Array
(
[result] => 2
[0] => 2
)
)
Array
(
[0] => Array
(
[result] => 2
[0] => 2
)
)
Actual result:
--
Array
(
[0] => Array
(
[result] => 2
[0] => 2
)
)
Array
(
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64522&edit=1
Bug #64522 [Opn]: After first query to MSSQL (DBLIB) all the other queries return null values
Edit report at https://bugs.php.net/bug.php?id=64522&edit=1
ID: 64522
Updated by: ssuffic...@php.net
Reported by:capile at tecnodz dot com
Summary:After first query to MSSQL (DBLIB) all the other
queries return null values
Status: Open
Type: Bug
Package:PDO related
Operating System: Ubuntu Linux
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
The pull request attached to this bug report will introduce another error when
the another statement is issued without fetching ALL the previous results:
SQLSTATE[HY000]: General error: 20019 Attempt to initiate a new Adaptive Server
operation with results pending [20019] (severity 7) [select 1+1 as result1]
The last statement should be able to be flushed using dbcancel(), but for some
reason this is not working as documented. I also tried dbcanquery(). Both
render
the statement not re-useable, but weirdly enough the column metatdata is
repopulated with the new column names and types
code: print_r($pdo->getColumnMeta(0))
Previous Comments:
[2013-05-29 13:51:34] capile at tecnodz dot com
Sorry, I commented without properly testing, just compiled 5.4.15 and tested
with $statement = null; and it was possible to keep using the connection, even
with transactions.
Also works with unset($statement);
Test script:
---
$db->exec('create table #test ( id int not null )');
$db->exec('begin transaction test1');
$db->exec('insert into #test (id) values (100)');
$db->exec('insert into #test (id) values (200)');
$db->exec('insert into #test (id) values (300)');
$db->exec('commit transaction test1');
$stmt = $db->query('select * from #test');
var_dump($stmt->fetchAll(PDO::FETCH_NUM));
$stmt->closeCursor();
unset($stmt);
$db->exec('drop table #test');
Expected result:
array(3) {
[0]=>
array(1) {
[0]=>
string(3) "100"
}
[1]=>
array(1) {
[0]=>
string(3) "200"
}
[2]=>
array(1) {
[0]=>
string(3) "300"
}
}
[2013-05-29 12:48:38] capile at tecnodz dot com
using $statement = null; would make it impossible to use transactions and some
stored procedures.
This was introduced back in late
2011(https://github.com/php/php-src/commit/3a069e814fe01b36812b5c768dd52ccdea3ed098)
but only on PHP 5.4+ (5.3- worked as expected).
I compiled PHP 5.4.13 with the pull request applied and it worked as expected.
[2013-05-29 03:42:49] ssuffic...@php.net
I installed Sybase Adaptive Server and was able to reproduce. A workaround is
to
do a $statement=null and then reuse the $statement variable. This calls the
statement destructor in addition to the cursorCloser().
This may be something new to the PDO core. From what I can see on git, no
changes
have been made to pdo_dblib since it was last working. I will continue to look
into this.
[2013-05-29 02:38:18] ssuffic...@php.net
The issue may be the way the cursor closer is implemented. It frees the column
metadata but I can't find where it is reallocated for the next statement. This
may be allocated in PDO core. I remember writing tests, but they did not call
"$stmt->closeCursor();". Does your script work without the closeCursor()?
I have no way to test anymore since I do not have an SQL/Sybase server to
connect to. :(
[2013-05-28 17:19:11] mneyman at yesco dot com
Also tested on Ubuntu 12.04 with PHP 5.4.15 and it does not work
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
https://bugs.php.net/bug.php?id=64522
--
Edit this bug report at https://bugs.php.net/bug.php?id=64522&edit=1
Bug #64522 [Opn->Asn]: After first query to MSSQL (DBLIB) all the other queries return null values
Edit report at https://bugs.php.net/bug.php?id=64522&edit=1
ID: 64522
Updated by: ssuffic...@php.net
Reported by:capile at tecnodz dot com
Summary:After first query to MSSQL (DBLIB) all the other
queries return null values
-Status: Open
+Status: Assigned
Type: Bug
Package:PDO related
Operating System: Ubuntu Linux
PHP Version:5.4.13
-Assigned To:
+Assigned To:ssufficool
Block user comment: N
Private report: N
New Comment:
See commit 9ef762d:
[master 9ef762d] FIX BUG #64522
1 file changed, 2 insertions(+), 3 deletions(-)
Previous Comments:
[2013-05-31 04:35:41] ssuffic...@php.net
Related To: Bug #64522
[2013-05-30 05:12:16] ssuffic...@php.net
The pull request attached to this bug report will introduce another error when
the another statement is issued without fetching ALL the previous results:
SQLSTATE[HY000]: General error: 20019 Attempt to initiate a new Adaptive Server
operation with results pending [20019] (severity 7) [select 1+1 as result1]
The last statement should be able to be flushed using dbcancel(), but for some
reason this is not working as documented. I also tried dbcanquery(). Both
render
the statement not re-useable, but weirdly enough the column metatdata is
repopulated with the new column names and types
code: print_r($pdo->getColumnMeta(0))
[2013-05-29 13:51:34] capile at tecnodz dot com
Sorry, I commented without properly testing, just compiled 5.4.15 and tested
with $statement = null; and it was possible to keep using the connection, even
with transactions.
Also works with unset($statement);
Test script:
---
$db->exec('create table #test ( id int not null )');
$db->exec('begin transaction test1');
$db->exec('insert into #test (id) values (100)');
$db->exec('insert into #test (id) values (200)');
$db->exec('insert into #test (id) values (300)');
$db->exec('commit transaction test1');
$stmt = $db->query('select * from #test');
var_dump($stmt->fetchAll(PDO::FETCH_NUM));
$stmt->closeCursor();
unset($stmt);
$db->exec('drop table #test');
Expected result:
array(3) {
[0]=>
array(1) {
[0]=>
string(3) "100"
}
[1]=>
array(1) {
[0]=>
string(3) "200"
}
[2]=>
array(1) {
[0]=>
string(3) "300"
}
}
[2013-05-29 12:48:38] capile at tecnodz dot com
using $statement = null; would make it impossible to use transactions and some
stored procedures.
This was introduced back in late
2011(https://github.com/php/php-src/commit/3a069e814fe01b36812b5c768dd52ccdea3ed098)
but only on PHP 5.4+ (5.3- worked as expected).
I compiled PHP 5.4.13 with the pull request applied and it worked as expected.
[2013-05-29 03:42:49] ssuffic...@php.net
I installed Sybase Adaptive Server and was able to reproduce. A workaround is
to
do a $statement=null and then reuse the $statement variable. This calls the
statement destructor in addition to the cursorCloser().
This may be something new to the PDO core. From what I can see on git, no
changes
have been made to pdo_dblib since it was last working. I will continue to look
into this.
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
https://bugs.php.net/bug.php?id=64522
--
Edit this bug report at https://bugs.php.net/bug.php?id=64522&edit=1
Bug #64522 [Asn->Csd]: After first query to MSSQL (DBLIB) all the other queries return null values
Edit report at https://bugs.php.net/bug.php?id=64522&edit=1 ID: 64522 Updated by: ssuffic...@php.net Reported by:capile at tecnodz dot com Summary:After first query to MSSQL (DBLIB) all the other queries return null values -Status: Assigned +Status: Closed Type: Bug Package:PDO related Operating System: Ubuntu Linux PHP Version:5.4.13 Assigned To:ssufficool Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2013-05-31 04:59:35] ssuffic...@php.net Automatic comment on behalf of ssufficool Revision: http://git.php.net/?p=php-src.git;a=commit;h=0074cd2675687a25155cdde2ebc6b9f4a709c743 Log: pdo_dblib: fix bug #64522DBLIB statement destructor was being called late and clobbered results from subsequent statement objects sharing the same connection [2013-05-31 04:47:27] ssuffic...@php.net The following patch has been added/updated: Patch Name: FIX_BUG_64522 Revision: 1369975647 URL: https://bugs.php.net/patch-display.php?bug=64522&patch=FIX_BUG_64522&revision=1369975647 [2013-05-31 04:35:41] ssuffic...@php.net See commit 9ef762d: [master 9ef762d] FIX BUG #64522 1 file changed, 2 insertions(+), 3 deletions(-) [2013-05-31 04:35:41] ssuffic...@php.net Related To: Bug #64522 [2013-05-30 05:12:16] ssuffic...@php.net The pull request attached to this bug report will introduce another error when the another statement is issued without fetching ALL the previous results: SQLSTATE[HY000]: General error: 20019 Attempt to initiate a new Adaptive Server operation with results pending [20019] (severity 7) [select 1+1 as result1] The last statement should be able to be flushed using dbcancel(), but for some reason this is not working as documented. I also tried dbcanquery(). Both render the statement not re-useable, but weirdly enough the column metatdata is repopulated with the new column names and types code: print_r($pdo->getColumnMeta(0)) 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 https://bugs.php.net/bug.php?id=64522 -- Edit this bug report at https://bugs.php.net/bug.php?id=64522&edit=1
Req #37223 [Opn->Fbk]: Include default column value in PDO::getColumnMeta
Edit report at https://bugs.php.net/bug.php?id=37223&edit=1 ID: 37223 Updated by: ssuffic...@php.net Reported by:rael at grad dot icmc dot usp dot br Summary:Include default column value in PDO::getColumnMeta -Status: Open +Status: Feedback Type: Feature/Change Request Package:PDO related Operating System: * PHP Version:5.1.2 Block user comment: N Private report: N Previous Comments: [2013-05-31 05:15:39] ssuffic...@php.net Which driver? The getColumnMeta method is specific to each driver. [2006-04-27 12:54:47] rael at grad dot icmc dot usp dot br Description: The current implementation of PDO::getColumnMeta() method don't contains information about the default value from columns. Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at https://bugs.php.net/bug.php?id=37223&edit=1
Req #37839 [Opn->Wfx]: Limit of returned rows
Edit report at https://bugs.php.net/bug.php?id=37839&edit=1
ID: 37839
Updated by: ssuffic...@php.net
Reported by:rael at grad dot icmc dot usp dot br
Summary:Limit of returned rows
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:PDO related
Operating System: Any
PHP Version:5.1.4
Block user comment: N
Private report: N
New Comment:
This is easily emulated using the existing fetch() function.
Previous Comments:
[2011-12-24 06:33:08] ssuffic...@php.net
This same effect is achievable using the fetch method with the offset argument
and limiting the results in your fetch loop.
It could be argued the offset and limit arguments should be added to the
fetchAll() method though.
[2006-06-18 17:17:06] rael at grad dot icmc dot usp dot br
Description:
A PDO method for limit the number of rows returned from a query, independent of
the used DBMS. This feature is available in DBMS abstraction packages, like
ADODB (and in Java JDBC too). Something like this:
function setLimit($limit, $offset);
Reproduce code:
---
$con = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
$stmt = $con->prepare("SELECT * FROM table");
$stmt->setLimit(10, 2);
Expected result:
10 tableresults starting from position 2
Actual result:
--
Function not exists yet.
--
Edit this bug report at https://bugs.php.net/bug.php?id=37839&edit=1
Req #43120 [Opn->Wfx]: PDO: domain Authenticated Machines no Username/password (make them optional)
Edit report at https://bugs.php.net/bug.php?id=43120&edit=1 ID: 43120 Updated by: ssuffic...@php.net Reported by:tshipclark at gmail dot com Summary:PDO: domain Authenticated Machines no Username/password (make them optional) -Status: Open +Status: Wont fix Type: Feature/Change Request Package:PDO related Operating System: Windows PHP Version:5.2.4 Block user comment: N Private report: N New Comment: >From FreeTDS Documentation: "Windows NT Authentication", often called "integrated security", relies on Microsoft's trusted connections and is not supported by FreeTDS. In it, user's network security attributes are established at network login time. When connecting to the database server, SQL Server uses Windows NT facilities to determine the validated network username. SQL Server then permits or denies login access based on that network username alone, without requiring a separate login name and password. You can use the username of DOMAIN\USER with their NTLM password. Not optimal, but that's as good as it gets. Previous Comments: [2007-10-30 11:02:22] j...@php.net it's a feature/change request, keep it there. [2007-10-28 14:18:11] tshipclark at gmail dot com Description: We currently use mssql_pconnect to connect to our server and we don't supply a username/password because the machine iis is running on is domain authenticated. My problem is Pdo will not allow me to not enter a username and password. And even if I put in blanks for username/password i still get permission denied. If you could make username/password optional that would be great! -- Edit this bug report at https://bugs.php.net/bug.php?id=43120&edit=1
Bug #64808 [Opn->Asn]: FreeTDS PDO getColumnMeta on a prepared but not executed statement crashes
Edit report at https://bugs.php.net/bug.php?id=64808&edit=1
ID: 64808
Updated by: ssuffic...@php.net
Reported by:chris dot kings-lynne at navitas dot com
Summary:FreeTDS PDO getColumnMeta on a prepared but not
executed statement crashes
-Status: Open
+Status: Assigned
Type: Bug
Package:PDO related
Operating System: Debian
PHP Version:5.4.15
-Assigned To:
+Assigned To:ssufficool
Block user comment: N
Private report: N
Previous Comments:
[2013-05-10 06:13:21] chris dot kings-lynne at navitas dot com
Not that useful without debug symbols, but at least shows the crash is in dblib:
(gdb) bt
#0 0x7fffeb0817e6 in ?? () from /usr/lib/php5/20100525/pdo_dblib.so
#1 0x73e5de15 in ?? () from /usr/lib/php5/20100525/pdo.so
#2 0x7407906b in xdebug_execute_internal () from
/usr/lib/php5/20100525/xdebug.so
#3 0x00746e18 in ?? ()
#4 0x00734438 in execute ()
#5 0x74079449 in xdebug_execute () from
/usr/lib/php5/20100525/xdebug.so
#6 0x006c9630 in zend_execute_scripts ()
#7 0x0066bba8 in php_execute_script ()
#8 0x00776553 in ?? ()
#9 0x00776d18 in ?? ()
#10 0x74a52c8d in __libc_start_main () from /lib/libc.so.6
#11 0x00430359 in _start ()
[2013-05-10 06:01:25] chris dot kings-lynne at navitas dot com
Description:
If you attempt to use getColumnMeta() on a prepared but not yet executed
PDOStatement, using the dblib driver, you get a segmentation fault.
FreeTDS library version 0.82-7
Test script:
---
prepare('SELECT * FROM users');
$meta = $result->getColumnMeta(1);
Expected result:
I would expect to get the column metadata just as it as after execution, as in
this code sample:
prepare('SELECT * FROM users');
$result->execute();
$meta = $result->getColumnMeta(1);
var_dump($meta);
Gives:
array(8) {
'max_length' =>
int(8)
'precision' =>
int(0)
'scale' =>
int(0)
'column_source' =>
string(4) "mode"
'native_type' =>
string(7) "unknown"
'name' =>
string(4) "mode"
'len' =>
int(8)
'pdo_type' =>
int(2)
}
Actual result:
--
Segmentation fault
Don't have debugging symbols or gdb on the machine sorry :(
--
Edit this bug report at https://bugs.php.net/bug.php?id=64808&edit=1
Bug #61919 [Opn->Fbk]: PDO DBLIB Driver is not working
Edit report at https://bugs.php.net/bug.php?id=61919&edit=1 ID: 61919 Updated by: ssuffic...@php.net Reported by:shahitha at digitalmesh dot com Summary:PDO DBLIB Driver is not working -Status: Open +Status: Feedback Type: Bug Package:MSSQL related Operating System: Linux Ubuntu PHP Version:5.3.11 Block user comment: N Private report: N New Comment: Please post code to reproduce this issue. Previous Comments: [2012-07-13 13:09:21] snowcorenet at gmail dot com Seems like it is not fixed yet in php 5.3 - https://bugs.php.net/bug.php?id=48539 [2012-05-03 04:23:13] shahitha at digitalmesh dot com Description: Hi, As I tired to connect with MSSQL with my Linux system using PDO DBLIB Driver I am getting following error SQLSTATE[] (null) (severity 0) -- Edit this bug report at https://bugs.php.net/bug.php?id=61919&edit=1
Bug #64328 [Opn->Csd]: No results when re-executing PDO dblib query using same variable
Edit report at https://bugs.php.net/bug.php?id=64328&edit=1
ID: 64328
Updated by: ssuffic...@php.net
Reported by:brad at wcubed dot net
Summary:No results when re-executing PDO dblib query using
same variable
-Status: Open
+Status: Closed
Type: Bug
Package:PDO related
Operating System: FreeBSD 9.1 amd64
PHP Version:5.4.12
-Assigned To:
+Assigned To:ssufficool
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Duplicate of BUG #64522
Previous Comments:
[2013-03-01 03:56:49] brad at wcubed dot net
Reverse the expected and actual results. The second fetchAll() returns an empty
array.
[2013-03-01 01:18:36] brad at wcubed dot net
Description:
Environment:
MS SQL Server 2008 R2
FreeTSD 0.64_9,1
No results are returned from dblib PDO::query() + PDOStatement::fetchAll() if
the same variable is re-used from a previous query/fetch.
If the variable is unset() before the second query, the behavior is as expected.
This problem is reproducible on both a fresh install of FreeBSD 9.1 and
longstanding 8.2 install. This behavior was not evident on the FreeBSD 8.2
install prior to a php upgrade from 5.3.8 to 5.4.12.
Test script:
---
$dbh = new PDO("dblib:host=$host;dbname=$dbname", $user, $pass);
$create = $dbh->exec('DROP TABLE foo');
$create = $dbh->exec('CREATE TABLE foo (ID int PRIMARY KEY IDENTITY (1,1) NOT
NULL, bar VARCHAR(10))');
$insert = $dbh->exec('INSERT INTO foo (bar) VALUES (\'baz\')');
$qry = 'select * from foo';
$stmt = $dbh->query($qry);
$results = $stmt->fetchAll(PDO::FETCH_NUM);
print_r($results);
$stmt = $dbh->query($qry);
$results = $stmt->fetchAll(PDO::FETCH_NUM);
print_r($results);
unset($stmt);
$stmt = $dbh->query($qry);
$results = $stmt->fetchAll(PDO::FETCH_NUM);
print_r($results);
Expected result:
Array
(
[0] => Array
(
[0] => 1
[1] => baz
)
)
Array
(
)
Array
(
[0] => Array
(
[0] => 1
[1] => baz
)
)
Actual result:
--
Array
(
[0] => Array
(
[0] => 1
[1] => baz
)
)
Array
(
[0] => Array
(
[0] => 1
[1] => baz
)
)
Array
(
[0] => Array
(
[0] => 1
[1] => baz
)
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64328&edit=1
Bug #64338 [Opn->Csd]: pdo_dblib can't connect to Azure SQL
Edit report at https://bugs.php.net/bug.php?id=64338&edit=1 ID: 64338 Updated by: ssuffic...@php.net Reported by:mah at everybody dot org Summary:pdo_dblib can't connect to Azure SQL -Status: Open +Status: Closed Type: Bug Package:MSSQL related Operating System: any PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: Automatic comment on behalf of ssufficool Revision: http://git.php.net/?p=php-src.git;a=commit;h=0e2bcf3373d914a215784c041a2a4c3b6afc2034 Log: FIX BUG #64338, #64808, #63638 Previous Comments: [2013-03-04 16:05:50] mah at everybody dot org Updated the patch to fix a segfault that I observed when I turned on FreeTDS' debug log. See http://lists.ibiblio.org/pipermail/freetds/2013q1/028280.html [2013-03-02 19:36:53] mah at everybody dot org Yes, this is on Linux. If you're using Azure to host your Linux machine (which I am), it makes sense to use the Azure-hosted SQL database if you can. I've already attached a patch and tested the patch that does exactly what you suggest. [2013-03-02 17:30:56] paj...@php.net btw, DBSETLDBNAME could be easily added in pdo_dblib_handle_factory (ext/pdo_dblib/dblib_driver.c). Can you test it pls? if you could create a patch and test it, even better :) [2013-03-02 16:56:05] paj...@php.net I suppose you are on Linux as dblib is not supported anymore on windows since quite a while. If you are on win usw sqlsrv, works out of the box. [2013-03-02 15:57:16] mah at everybody dot org Originally reported to Debian: http://bugs.debian.org/702079 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 https://bugs.php.net/bug.php?id=64338 -- Edit this bug report at https://bugs.php.net/bug.php?id=64338&edit=1
Bug #64808 [Asn->Csd]: FreeTDS PDO getColumnMeta on a prepared but not executed statement crashes
Edit report at https://bugs.php.net/bug.php?id=64808&edit=1
ID: 64808
Updated by: ssuffic...@php.net
Reported by:chris dot kings-lynne at navitas dot com
Summary:FreeTDS PDO getColumnMeta on a prepared but not
executed statement crashes
-Status: Assigned
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Debian
PHP Version:5.4.15
Assigned To:ssufficool
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2013-06-01 05:58:55] ssuffic...@php.net
Automatic comment on behalf of ssufficool
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=0e2bcf3373d914a215784c041a2a4c3b6afc2034
Log: FIX BUG #64338, #64808, #63638
[2013-05-10 06:13:21] chris dot kings-lynne at navitas dot com
Not that useful without debug symbols, but at least shows the crash is in dblib:
(gdb) bt
#0 0x7fffeb0817e6 in ?? () from /usr/lib/php5/20100525/pdo_dblib.so
#1 0x73e5de15 in ?? () from /usr/lib/php5/20100525/pdo.so
#2 0x7407906b in xdebug_execute_internal () from
/usr/lib/php5/20100525/xdebug.so
#3 0x00746e18 in ?? ()
#4 0x00734438 in execute ()
#5 0x74079449 in xdebug_execute () from
/usr/lib/php5/20100525/xdebug.so
#6 0x006c9630 in zend_execute_scripts ()
#7 0x0066bba8 in php_execute_script ()
#8 0x00776553 in ?? ()
#9 0x00776d18 in ?? ()
#10 0x74a52c8d in __libc_start_main () from /lib/libc.so.6
#11 0x00430359 in _start ()
[2013-05-10 06:01:25] chris dot kings-lynne at navitas dot com
Description:
If you attempt to use getColumnMeta() on a prepared but not yet executed
PDOStatement, using the dblib driver, you get a segmentation fault.
FreeTDS library version 0.82-7
Test script:
---
prepare('SELECT * FROM users');
$meta = $result->getColumnMeta(1);
Expected result:
I would expect to get the column metadata just as it as after execution, as in
this code sample:
prepare('SELECT * FROM users');
$result->execute();
$meta = $result->getColumnMeta(1);
var_dump($meta);
Gives:
array(8) {
'max_length' =>
int(8)
'precision' =>
int(0)
'scale' =>
int(0)
'column_source' =>
string(4) "mode"
'native_type' =>
string(7) "unknown"
'name' =>
string(4) "mode"
'len' =>
int(8)
'pdo_type' =>
int(2)
}
Actual result:
--
Segmentation fault
Don't have debugging symbols or gdb on the machine sorry :(
--
Edit this bug report at https://bugs.php.net/bug.php?id=64808&edit=1
Bug #63638 [Asn->Csd]: Cannot connect to SQL Server 2008 with PDO dblib
Edit report at https://bugs.php.net/bug.php?id=63638&edit=1 ID: 63638 Updated by: ssuffic...@php.net Reported by:pmeunier at cybergeneration dot com Summary:Cannot connect to SQL Server 2008 with PDO dblib -Status: Assigned +Status: Closed Type: Bug Package:PDO related Operating System: Linux Slackware 13 PHP Version:5.4.9 Assigned To:laruence Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2013-06-01 05:58:56] ssuffic...@php.net Automatic comment on behalf of ssufficool Revision: http://git.php.net/?p=php-src.git;a=commit;h=0e2bcf3373d914a215784c041a2a4c3b6afc2034 Log: FIX BUG #64338, #64808, #63638 [2013-03-20 19:01:12] jwatson at fh dot org A second pull request was submitted to merge to the PHP-5.4.13 branch, which is the latest branch for PHP 5.4. The original pull request above was for master. https://github.com/php/php-src/pull/308 [2013-03-20 18:43:00] jwatson at fh dot org A pull request was submitted with this patch. Please see the link below. https://github.com/php/php-src/pull/306 [2013-01-19 03:14:03] ssuffic...@php.net Looks like a Microsoft DBLIB versus FreeTDS issue. MS DBLIB requires the parameter to be NULL (per MSDN, possibly incorrect docs) while FreeTDS does not like the NULL parameter, thus I guess why I used "1" originally. The patch from 1 to NULL should be reverted. [2012-12-07 16:37:58] wdmeldon at gmail dot com I've tested this in SQL Server 2012, 2008 and 2005 with similar results. The warnings do not always manifest however. I've noticed returning output will prevent the warning as will calling other functions, but it's a crap shoot. The connection seems to be fine and the data returned is as well, so more annoying than anything else. Running Ubuntu Server 12.04 with PHP 5.4.9. 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 https://bugs.php.net/bug.php?id=63638 -- Edit this bug report at https://bugs.php.net/bug.php?id=63638&edit=1
Bug #61900 [Opn->Csd]: Cannot use PDO (dblib) and mssql_ (FreeTDS) in the same script
Edit report at https://bugs.php.net/bug.php?id=61900&edit=1
ID: 61900
Updated by: ssuffic...@php.net
Reported by:stasismedia at gmail dot com
Summary:Cannot use PDO (dblib) and mssql_ (FreeTDS) in the
same script
-Status: Open
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Ubuntu 12.04
PHP Version:5.3.11
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of ssufficool
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=317653e694c8cd3a3cc4c12c527af584726a66c7
Log: FIX BUG #61900
Previous Comments:
[2012-05-02 12:28:17] stasismedia at gmail dot com
Description:
When using PDO (dblib) and mssql_ (FreeTDS) in the same script, PDO will not
throw any Exceptions.
This is apparently due to the calls to 'dberrhandle' in the FreeTDS library:
https://github.com/php/php-src/blob/master/ext/mssql/php_mssql.c#L598
https://github.com/php/php-src/blob/master/ext/pdo_dblib/pdo_dblib.c#L205
Regardless of the order in the PHP Script, php_mssql is executed last, which
will replace any error handler function that pdo_dblib has set.
This also seems to be the case when 'forcing' the use of multiple connections.
Whilst using both functions is a silly thing to do, we are migrating a 9 year
old project over to PDO in a number of phases.
Test script:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
try
{
$pdo->query('INSERT INTO incorrecttable (abc) VALUES (123)');
echo "Exception not thrown\n";
}
catch(\PDOException $exception)
{
echo "Exception caught\n";
}
Expected result:
Exception caught
Actual result:
--
Warning: PDO::query(): message: Invalid object name 'incorrecttable'. (severity
16) in /tmp/php-test/pdotest.php on line 15
Call Stack:
0.0001 631912 1. {main}() /tmp/php-test/pdotest.php:0
0.0557 633632 2. PDO->query() /tmp/php-test/pdotest.php:15
Warning: PDO::query(): General SQL Server error: Check messages from the SQL
Server (severity 16) in /tmp/php-test/pdotest.php on line 15
Call Stack:
0.0001 631912 1. {main}() /tmp/php-test/pdotest.php:0
0.0557 633632 2. PDO->query() /tmp/php-test/pdotest.php:15
Exception not thrown
--
Edit this bug report at https://bugs.php.net/bug.php?id=61900&edit=1
Bug #60512 [Opn->Csd]: pdo_dblib - Seg Fault error on user/pass exceeds 30 chars
Edit report at https://bugs.php.net/bug.php?id=60512&edit=1
ID: 60512
Updated by: ssuffic...@php.net
Reported by:paul dot visco at roswellpark dot org
Summary:pdo_dblib - Seg Fault error on user/pass exceeds 30
chars
-Status: Open
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Centos 5.5/Fedora 16
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of ssufficool
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=3b54de3db008490eeae8fba2e471a41906d1eae5
Log: FIX BUG #60512
Previous Comments:
[2012-06-15 22:22:52] bmherold at gmail dot com
Created a gist of my crash log at: https://gist.github.com/2938986
[2012-06-15 22:06:01] bmherold at gmail dot com
Has there been any movement on this bug? I'm using freetds 0.91 on OS X 10.7.4
and
php 5.3.13. HTTPD crashes when using a password of over 30 characters as seen
in
the console logs. I can also tail freetds.log and it doesnt even make it in
here -
but only when the password is over 30 chars.
[2011-12-13 16:21:35] paul dot visco at roswellpark dot org
Description:
LIB: freetds-0.91-1
PHP: php 5.3.8
EXT: pdo_dblib from /ext folder of php 5.3.8 source
OS: Fedora 16/Centos 5
I was using pdo_dblib to connect to a MSSQL server db. When the password or
username is longer than 30 chars, a segmentation fault occurrs, crashing PHP.
It would be ideal to instead throw the catchable error from freetds which is
"20042 Name too long for LOGINREC field (severity 2)"
The problem is that the code is not checking to make sure dbproc is not NULL
before processing the error info further. In the case of the password being
longer than 30 chars it is NULL, which then causes the seg fault.
Test script:
---
$db = new PDO("dblib:host=someserver;", "uname",
'31charpasswordpasswordpasswordp');
Expected result:
20042 Name too long for LOGINREC field (severity 2)
Actual result:
--
segmentation fault
OUTPUT FROM gdb:
Program received signal SIGSEGV, Segmentation fault.
0x00390502b0ff in __dcigettext () from /lib64/libc.so.6
(gdb) bt
#0 0x00390502b0ff in __dcigettext () from /lib64/libc.so.6
#1 0x003905079b3c in strerror_r () from /lib64/libc.so.6
#2 0x00390507997e in strerror () from /lib64/libc.so.6
#3 0x2aaab26a6815 in ?? () from /usr/lib64/libsybdb.so.5
#4 0x2aaab26a7aa9 in dbgetuserdata () from /usr/lib64/libsybdb.so.5
#5 0x2aaab3bc2c59 in error_handler (dbproc=0x39051200a9,
severity=85066262, dberr=0, oserr=0, dberrstr=0x0, oserrstr=0x5 )
at /home/ROSWELL/visco/php-5.3.8/ext/pdo_dblib/pdo_dblib.c:98
--
Edit this bug report at https://bugs.php.net/bug.php?id=60512&edit=1
Bug #64161 [Opn->Csd]: PDO::__construct(): Called dbsetopt with parameter 3 NULL (severity 11)
Edit report at https://bugs.php.net/bug.php?id=64161&edit=1
ID: 64161
Updated by: ssuffic...@php.net
Reported by:sivavivekanantha at gmail dot com
Summary:PDO::__construct(): Called dbsetopt with parameter 3
NULL (severity 11)
-Status: Open
+Status: Closed
Type: Bug
Package:PDO related
Operating System: linux centos 6
PHP Version:5.4.11
-Assigned To:
+Assigned To:ssufficool
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
This is related to the quoted identifier passing NULL to FreeTDS. This has been
fixed in git master.
Previous Comments:
[2013-03-20 18:41:09] jwatson at fh dot org
This may be a duplicate of issue #63638.
If so, a patch/pull request was submitted at https://github.com/php/php-
src/pull/306. Waiting on php developers to roll this into their release.
[2013-02-06 04:52:28] sivavivekanantha at gmail dot com
Description:
PDO::__construct(): Called dbsetopt with parameter 3 NULL (severity 11)
/var/www/framework/db/CDbConnection.php(423)
411 protected function createPdoInstance()
412 {
413 $pdoClass=$this->pdoClass;
414 if(($pos=strpos($this->connectionString,':'))!==false)
415 {
416 $driver=strtolower(substr($this->connectionString,0,$pos));
417 if($driver==='mssql' || $driver==='dblib')
418 $pdoClass='CMssqlPdoAdapter';
419 elseif($driver==='sqlsrv')
420 $pdoClass='CMssqlSqlsrvPdoAdapter';
421 }
422 return new $pdoClass($this->connectionString,$this->username,
423 $this->password,$this->_attributes);
Test script:
---
$sql = "[sp_Language] :Language_Code, :Language_Name, :Active, :Disp_Order,
:Action ";
$command = $this->createCommand($sql);
$command->bindParam(":Language_Code",$languageCode,
PDO::PARAM_INT);
$command->bindParam(":Language_Name",$language,
PDO::PARAM_STR);
$command->bindParam(":Active", $active,
PDO::PARAM_STR);
$command->bindParam(":Disp_Order", $displayOrder,
PDO::PARAM_INT);
$command->bindParam(":Action", $action,
PDO::PARAM_INT);
try {
$this->msg = '';
$command->execute();
}
catch(Exception $e)
{
//$this->msg = substr($ex->getMessage(),0,-30);
$this->msg = $e->getMessage();
// $this->msg = substr($e->errorInfo[2],0,-30);
}
Expected result:
PDO::__construct(): Called dbsetopt with parameter 3 NULL (severity 11)
Actual result:
--
Language Name Already Exists..this custom Exception shown in my UI
(I'm Using Sql stored procedure, that procedure throw custom message use
Raiserror command. That custom exception shown in my yii UI.)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64161&edit=1
Bug #55647 [Opn->Csd]: PDOStatement::execute() returns false when executing an UPDATE stored procedure
Edit report at https://bugs.php.net/bug.php?id=55647&edit=1 ID: 55647 Updated by: ssuffic...@php.net Reported by:rcavicchioni at gmail dot com Summary:PDOStatement::execute() returns false when executing an UPDATE stored procedure -Status: Open +Status: Closed Type: Bug Package:PDO related Operating System: CentOS 5.6 & 6 PHP Version:trunk-SVN-2011-09-08 (SVN) Block user comment: N Private report: N New Comment: Automatic comment on behalf of ssufficool Revision: http://git.php.net/?p=php-src.git;a=commit;h=c34a2757db80ee2a2f35583a73899330397cb35c Log: FIX BUG #55647 Previous Comments: [2011-09-08 18:38:34] rcavicchioni at gmail dot com Description: When using PDO dblib, PDOStatement::execute() is returning false with a stored procedure that only contains an UPDATE statement. The procedure actually succeeds and modifies the data as expected. I discovered this issue because we upgraded to PHP 5.3.8 from 5.3.6 using the RPMs from the Remi repository. I looked at the RPM spec file and this patch is being applied for PHP bug #50755: https://raw.github.com/remicollet/remirepo/master/php/php-5.3.7-pdo-dblib-50755.patch According to the comments in the spec file, the patch is based off the following commits: http://svn.php.net/viewvc?view=revision&revision=32 http://svn.php.net/viewvc?view=revision&revision=300089 http://svn.php.net/viewvc?view=revision&revision=300646 http://svn.php.net/viewvc?view=revision&revision=300791 Before reporting a bug to the Remi repository, I decided that I would try to duplicate the bug in PHP-trunk and I was able to. Our environment: MSSQL 2008 FreeTDS 0.82 (from the EPEL repo) PHP-trunk CentOS 5.6 Here is a simple example of the type of stored procedure that we are using. CREATE PROCEDURE [dbo].[TestProc] @iID integer, @sFoo varchar(max) AS BEGIN UPDATE TestTable SET foo = @sFoo WHERE id = @iID; END The stored procedure does not return any results, yet is executed successfully. PDOStatement::execute() returns false, but it returns true in vanilla PHP 5.3.8. It seems that since the procedure does not return any results, it causes PDOStatement::execute() to return false not true. Test script: --- setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $sql = 'EXEC TestProc ?, ?'; $stmt = $db->prepare($sql); $id = 123; $foo = 'Hello ...'; $stmt->bindParam(1, $id, PDO::PARAM_INT); $stmt->bindParam(2, $foo, PDO::PARAM_STR); $ret = $stmt->execute(); var_dump($ret); ?> Expected result: bool(true) Actual result: -- bool(false) -- Edit this bug report at https://bugs.php.net/bug.php?id=55647&edit=1
Bug #58198 [Opn->Fbk]: PDO 1.0.3 fails to build
Edit report at https://bugs.php.net/bug.php?id=58198&edit=1 ID: 58198 Updated by: ssuffic...@php.net Reported by:jnugent at unb dot ca Summary:PDO 1.0.3 fails to build -Status: Open +Status: Feedback Type: Bug -Package:PDO +Package:*General Issues Operating System: SuSE Linux Enterprise PHP Version:5.1.3 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2008-05-21 17:42:55] jnugent at unb dot ca Description: PDO 1.0.3 fails to build under SuSE Linux Enterprise 10.1. Reproduce: cd /usr/local/src/PDO-1.0.3 phpize ./configure make ... generates following error: eclipse:/usr/local/src/PDO-1.0.3 # make /bin/sh /usr/local/src/PDO-1.0.3/libtool --mode=compile gcc -I. -I/usr/local/src/PDO-1.0.3 -DPHP_ATOM_INC -I/usr/local/src/PDO-1.0.3/include -I/usr/local/src/PDO-1.0.3/main -I/usr/local/src/PDO-1.0.3 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -DHAVE_CONFIG_H -g -O2 -c /usr/local/src/PDO-1.0.3/pdo.c -o pdo.lo gcc -I. -I/usr/local/src/PDO-1.0.3 -DPHP_ATOM_INC -I/usr/local/src/PDO-1.0.3/include -I/usr/local/src/PDO-1.0.3/main -I/usr/local/src/PDO-1.0.3 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -DHAVE_CONFIG_H -g -O2 -c /usr/local/src/PDO-1.0.3/pdo.c -fPIC -DPIC -o pdo.lo In file included from /usr/local/src/PDO-1.0.3/pdo.c:32: /usr/local/src/PDO-1.0.3/php_pdo_driver.h:605: error: expected specifier-qualifier-list before 'zend_fcall_info' /usr/local/src/PDO-1.0.3/php_pdo_driver.h:612: error: expected specifier-qualifier-list before 'zend_fcall_info' In file included from /usr/local/src/PDO-1.0.3/pdo.c:33: /usr/local/src/PDO-1.0.3/php_pdo_int.h:34: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pdo_dbh_new' /usr/local/src/PDO-1.0.3/php_pdo_int.h:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pdo_dbstmt_new' /usr/local/src/PDO-1.0.3/php_pdo_int.h:43: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token /usr/local/src/PDO-1.0.3/php_pdo_int.h:44: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pdo_dbstmt_object_handlers' /usr/local/src/PDO-1.0.3/php_pdo_int.h:48: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pdo_row_new' /usr/local/src/PDO-1.0.3/php_pdo_int.h:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pdo_row_object_handlers' /usr/local/src/PDO-1.0.3/php_pdo_int.h:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token /usr/local/src/PDO-1.0.3/pdo.c:147: error: 'OnUpdateLong' undeclared here (not in a function) /usr/local/src/PDO-1.0.3/pdo.c: In function 'zm_startup_pdo': /usr/local/src/PDO-1.0.3/pdo.c:325: error: 'ZEND_ACC_PUBLIC' undeclared (first use in this function) /usr/local/src/PDO-1.0.3/pdo.c:325: error: (Each undeclared identifier is reported only once /usr/local/src/PDO-1.0.3/pdo.c:325: error: for each function it appears in.) make: *** [pdo.lo] Error 1 Using GCC version 4.1.2. -- Edit this bug report at https://bugs.php.net/bug.php?id=58198&edit=1
Bug #56683 [Opn->Fbk]: PDO_PGSQL cannot be upgraded
Edit report at https://bugs.php.net/bug.php?id=56683&edit=1 ID: 56683 Updated by: ssuffic...@php.net Reported by:mdv at inyourpocket dot com Summary:PDO_PGSQL cannot be upgraded -Status: Open +Status: Feedback Type: Bug -Package:PDO_PGSQL +Package:*General Issues Operating System: debian PHP Version:5.1.1 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2006-02-08 15:13:04] m dot regner at larkos dot de Sorry i missed somthing in my description of my solution: I only copied the link and not the full command so here it is: pear install -f http://pecl.php.net/get/PDO_PGSQL-1.0.1.tgz The -f overruns the dependency-testing of pear. Greetings again [2006-02-08 15:10:03] m dot regner at larkos dot de I don't get this error during update but when i tried to install pdo and pdo_pgsql. I got it running now and maybe someone can put some light in this matter. I discovered while crawling through the configure file of the pdo_pgsql package, that it seems to pretend, that pdo is build statically. It checkes a variable called: PHP_PDO_SHARED So when i do: export PHP_PDO_SHARED="true" and than do http://pecl.php.net/get/PDO_PGSQL-1.0.1.tgz everything installs and works fine. I don't know, if this is a bug or if i have overseen some other configuration step. However for everybody who needs to get this stuff running fast, this is hopefully a interim solution Greetings so far [2006-01-27 02:17:50] mastabog at hotmail dot com Join the club :( Following a hint from #6117 I converted the package.xml to package2.xml (pecl convert) and tried inserting a bogus dependency and provider ... no luck. Tried removing the pdo dependency ... no luck with that either. This definitely needs to be addressed. I'm surprised though because it has been reported 2 months ago ... [2006-01-17 09:00:14] miki at canaan dot co dot il Reinstalled pdp 1.0.2 easily. then I added extension=pdo.so to both: /etc/php5/apache/php.ini & /etc/php5/cli/php.ini phpinfo(); showed that: the configure was with --disable-pdo but later on i see the PDO is enabled. referance: http://www.canaan-net.com/test.phtml and still im getting the folloing error: ( now with all the buid info ) # pear install http://pecl.php.net/get/PDO_PGSQL-1.0.1.tgz downloading PDO_PGSQL-1.0.1.tgz ... Starting to download PDO_PGSQL-1.0.1.tgz (13,308 bytes) .done: 13,308 bytes 7 source files, building running: phpize Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20050922 Zend Extension Api No: 220051025 building in /var/tmp/pear-build-root/PDO_PGSQL-1.0.1 running: /tmp/tmpYiSIwo/PDO_PGSQL-1.0.1/configure checking for egrep... grep -E checking for a sed that does not truncate output... /bin/sed checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking whether gcc and cc understand -c and -o together... yes checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for PHP prefix... /usr checking for PHP includes... -I/usr/include/php5 -I/usr/include/php5/main -I/usr/include/php5/TSRM -I/usr/include/php5/Zend -I/usr/include/php5/ext checking for PHP extension directory... /usr/lib/php5/20050922 checking for PHP installed headers prefix... /usr/include/php5 checking for re2c... no configure: WARNING: You will need re2c 0.9.11 or later if you want to regenerate PHP parsers. checking for gawk... no checking for nawk... nawk checking if nawk is broken... no checking for PostgreSQL support for PDO... yes, shared checking for pg_config... /usr/bin/pg_config checking for openssl dependencies... yes checking for PQescapeString in -lpq... yes checking for PQsetnonblocking in -lpq... yes checking for PQcmdTuples in -lpq... yes checking for PQoidValue in -lpq... yes checking for PQclientEncoding in -lpq... yes checking for PQparameterStatus in -lpq... yes checking for PQprotocolVersion in -lpq... yes checking for PQtransactionStatus in -lpq... y
Bug #56685 [Opn->Fbk]: PDO shared fails to allow pecl to install
Edit report at https://bugs.php.net/bug.php?id=56685&edit=1
ID: 56685
Updated by: ssuffic...@php.net
Reported by:phyre at rogers dot com
Summary:PDO shared fails to allow pecl to install
-Status: Open
+Status: Feedback
Type: Bug
-Package:PDO
+Package:*General Issues
Operating System: Debian Linux 3.1
PHP Version:5_1 CVS-2005-11-30
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-05-31 21:51:13] Jakub at Horky dot earth
Here is a fix.
You don't need to install PDO extension provided by pecl if
pdo package is contained in your distribution (e.g. Debian)
itself.
In PEAR directory, edit your Dependency2.php file - add this
line at the beginning of extension_loaded() function:
---
dl("$name.so");
---
Or, if you want to be more precisious, you can add these
lines instead:
---
if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') {
$prefix = 'php_';
$suffix = '.' . ( defined('PHP_SHLIB_SUFFIX') ?
PHP_SHLIB_SUFFIX : 'dll' );
} else {
$prefix = '';
$suffix = '.' . ( defined('PHP_SHLIB_SUFFIX') ?
PHP_SHLIB_SUFFIX : 'so' );
}
@dl($prefix . $name . $suffix);
---
Have a nice day
[2007-11-21 14:16:30] anonymous_two at example dot com
Had problems with shared module for PDO, was googling around and found this
page ;) This worked for me:
1. pecl uninstall PDO_MYSQL
2. PHP_PDO_SHARED=1 pecl install PDO_MYSQL
[2007-08-09 16:34:04] nlgordon at gmail dot com
With php 5.2.0 and higher this becomes more troublesome in that doing `pecl
upgrade pdo` will always downgrade the pdo extension. This removes the
ATTR_DEFAULT_FETCH_MODE constant from the class as well as other fixes in the
latest version of the PDO module. Updating pecl with the latest version of
what is in the stable 5.2.x tree would solve this problem.
[2007-06-29 15:39:33] c_petro at yahoo dot com
sometimes configure cannot find the mysql_config file. Try doing:
#ln -s /path/to/mysql/bin/mysql_config /usr/bin/mysql_config
#pecl install pdo_mysql
that's it
[2007-01-25 22:15:09] sean at the-murrays dot net
I tried PHP_PDO... but it didn't like the fact I wasn't root. Using Ubuntu, I
naturaly put sudo in front of it, but that failed. The trick I did here was to
put the line in a file i.e. pdo_sqlite, then I entered
sudo sh pdo_sqlite ... which worked.
Thanks for the help
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
https://bugs.php.net/bug.php?id=56685
--
Edit this bug report at https://bugs.php.net/bug.php?id=56685&edit=1
Req #56723 [Opn->Fbk]: Privileged connection
Edit report at https://bugs.php.net/bug.php?id=56723&edit=1
ID: 56723
Updated by: ssuffic...@php.net
Reported by:s dot zurnieden at media-control dot com
Summary:Privileged connection
-Status: Open
+Status: Feedback
Type: Feature/Change Request
-Package:PDO_OCI
+Package:*General Issues
Operating System: Linux 32 (SuSE)
PHP Version:5.1.1
Block user comment: N
Private report: N
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
It looks like there may be a workaround at the server level. Will this work for
you?
https://forums.oracle.com/thread/1135635
Previous Comments:
[2007-06-28 16:37:34] christopher dot jones at oracle dot com
Adding privileged connections opens a potential security hole. If the
webserver runs as an OS user with Oracle dba or oinstall privilges it could be
possible a hacker to gain high level access to the database.
The oci8 extension added a php.ini parameter to allow privileged connections
for users who want to take the risk.
PDO_OCI patches for something similar are welcome, as are a list of use cases
where you would find the feature beneficial.
[2007-05-14 12:47:58] ludovico dot caldara at gmail dot com
hi, since Zend Framework provides Zend_DB class based on PDO, it would be very
cool to have privileged sessions implemented.
It should be quite simple adding a new variable to the DSN:
struct pdo_data_src_parser vars[] = {
{ "charset", NULL, 0 },
{ "dbname", "", 0 },
{ "credentials", "OCI_DEFAULT", 0 }
};
and passing the correct parameter to OciSessionBegin() call...
kind regards
--
Ludovico Caldara
[2005-12-14 04:43:52] s dot zurnieden at media-control dot com
Description:
PDO_OCI 1.0
Oracle 10GR2(x86_64)
For the moment it seems that it isn't possible to connect to an oracle database
with a priviledged connection (as sysdba).
In some cases this could be very useful to connect as sysdba.
Maybe this can be done via a connection dsn paramter like session_mode=sysdba
or something like that.
So a full connection dsn could be:
oci:dbname=myoraclesid;session_mode=sysdba
Kind regards,
Sven Zurnieden
Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$database->setAttribute(PDO::ATTR_CASE, PDO::CASE_LOWER);
$database->setAttribute(PDO::ATTR_ORACLE_NULLS, true);
$database->setAttribute(PDO::ATTR_PREFETCH, 1000);
}
catch(PDOException $e){
echo $e->getMessage() . ' in ' . $e->getFile() . ' on line ' .
$e->getLine() . "\n";
}
?>
Expected result:
Connection as sysdba to an oracle database.
Actual result:
--
SQLSTATE[HY000]: OCISessionBegin:: ORA-28009: connection as SYS should be as
SYSDBA or SYSOPER (/root/install/php/php-5.1.1/ext/pdo_oci/oci_driver.c:514) in
/usr/local/httpd/htdocs/ora_mgmt/pdo_connect.php on line 30
--
Edit this bug report at https://bugs.php.net/bug.php?id=56723&edit=1
Bug #60515 [Opn->Fbk]: PDO_MYSQL: "Invalid parameter number" although it is correct
Edit report at https://bugs.php.net/bug.php?id=60515&edit=1
ID: 60515
Updated by: ssuffic...@php.net
Reported by:phoenixseve at freenet dot de
-Summary:"Invalid parameter number" although it is correct
+Summary:PDO_MYSQL: "Invalid parameter number" although it is
correct
-Status: Open
+Status: Feedback
Type: Bug
Package:PDO related
Operating System: archlinux x86_64
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
I don't think the assoc array is supposed to include the ":"
try:
$stmt->execute(array('p0'=>'2', 'p1'=>'b2' ));
Previous Comments:
[2012-09-17 20:55:02] phoenixseve at freenet dot de
You're right, using WHERE `id`=24 works.
But the following query works on the command line client of MySQL:
mysql> UPDATE `edtable` SET`id`=1 WHERE `id`='24';
Query OK, 1 row affected (0.19 sec)
Rows matched: 1 Changed: 1 Warnings: 0
Same is true for Postgres 9.1:
postgres=# UPDATE "edtable" SET "id"=1 WHERE "id"='24';
UPDATE 1
As I can read from
http://dev.mysql.com/doc/refman/5.5/en/comparison-operators.html#operator_equal
`id`='24' is actually valid, at least in MySQL.
Who imposes the limitation that quotes are not valid here when using PDO?
[2012-09-17 20:12:42] willfi...@php.net
After removing the invalid quote from your SQL statement, there is no issue
here.
I tried this with MySQL and PostgreSQL drivers. Please confirm.
[2012-05-02 11:21:11] u...@php.net
$stmt = $pdo->prepare("UPDATE `edtable` SET `id`=:p0, `coun't()`= :p1 WHERE
`id`='24'");
Your SQL is invalid.
Whatever is behind, parsing is done by the PDO core. Thus, this is most
unlikely to be MySQL specific. Parsing needs to be done as a syntax is used
that is not supported by MySQL. Replace MySQL here with any other DB that does
not support named parameters or do the same with questionmarks and a DB that
does support named parameters only but no questionmarks.
[2012-03-06 02:35:34] jeffvanb at u dot washington dot edu
This misleading error message is also thrown when you include a single-line
comment that contains a single-quote.
Example:
SELECT something
-- This valid SQL syntax shouldn't be a problem
FROM somewhere
WHERE value = :v;
PDO will tell you the parameter count is mismatched and you will pull your hair
out wondering what is wrong.
[2011-12-13 20:57:47] phoenixseve at freenet dot de
Description:
When I execute the attached test script an exception is thrown with the message:
SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not
match number of tokens
The exception is raised in the execute() line.
If you change the WHERE clause to `id`=24 there is no error message.
The same is true for this query: UPDATE `edtable` SET `id`=:p0 WHERE `id`='24'
The generated error message is obviously not correct. I don't even see why an
error message is generated as the request seems valid (although strange) to me.
Test script:
---
$createTableSql = <<<'EOT'
DROP TABLE IF EXISTS `edtable`;
CREATE TABLE IF NOT EXISTS `edtable` (
`id` bigint(20) NOT NULL,
`coun't()` varchar(20) NOT NULL
);
EOT;
$pdo = new PDO('mysql:host=localhost;dbname=aynte','aynte','aynte');
$pdo->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$result = $pdo->query($createTableSql);
$result->closeCursor();
$stmt = $pdo->prepare("UPDATE `edtable` SET `id`=:p0, `coun't()`= :p1 WHERE
`id`='24'");
$stmt->execute(array(':p0'=>'2', ':p1'=>'b2' ));
Expected result:
No error message.
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not
match number of tokens' in /srv/http/test.php:19\nStack trace:\n#0
/srv/http/test.php(19): PDOStatement->execute(Array)\n#1 {main}\n thrown in
/srv/http/test.php on line 19
--
Edit this bug report at https://bugs.php.net/bug.php?id=60515&edit=1
Bug #52637 [Opn->Fbk]: bug in prepare statement
Edit report at https://bugs.php.net/bug.php?id=52637&edit=1 ID: 52637 Updated by: ssuffic...@php.net Reported by:angelo dot courtel at laposte dot net Summary:bug in prepare statement -Status: Open +Status: Feedback Type: Bug Package:PDO related Operating System: Debian Lenny PHP Version:5.2.6-1+lenny6 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Some drivers implement their own parameter binding. Which database driver does this pertain to? MySQL, PostrgreSQL, Oracle, DBLIB?? Previous Comments: [2010-10-12 12:09:23] ddebernardy at yahoo dot com I ran into this one too a long time ago, and it was due to the presence of multiple occurrences of named parameters in the query. If you change the two occurrences of :month to :month and :month2, then bind the parameters accordingly, the bug will go away. The workaround is not optimal, but it works. [2010-09-10 14:38:09] angelo dot courtel at laposte dot net I ve commented only first line of my sql statement, not entire statement. [2010-09-10 13:40:41] u...@php.net Your "//works fine" code sample should do exactly nothing because there is no SQL statement run. The SQL statement is commented out. No "predifining" of any kind should happen. [2010-09-07 21:44:13] angelo dot courtel at laposte dot net Well, but I want find a way to use a prepared statement, without need to predeclare all paramètres on a sql comment ! It s not a very optimized solution. [2010-09-06 15:13:59] u...@php.net Well, if you comment out your SQL statement, it should work fine regardless what it may look like... "-- " starts a single line SQL comment. 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 https://bugs.php.net/bug.php?id=52637 -- Edit this bug report at https://bugs.php.net/bug.php?id=52637&edit=1
Bug #61490 [Opn->Fbk]: Can't retrieve Out Parameter with PDO ODBC
Edit report at https://bugs.php.net/bug.php?id=61490&edit=1 ID: 61490 Updated by: ssuffic...@php.net Reported by:chris at chrisdoherty dot me dot uk Summary:Can't retrieve Out Parameter with PDO ODBC -Status: Open +Status: Feedback Type: Bug Package:PDO related Operating System: Windows XP PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Please provide the code you use to reproduce the error. Previous Comments: [2012-03-23 12:57:42] chris at chrisdoherty dot me dot uk Description: When trying to retrieve an OUT parameter after preparing and executing an SQL statement I cannot. Initially I created a stored procedure with a single OUT parameter and it was succesfull and I retrieved the parameter. When I added a second parameter (IN ONLY) the OUT parameter failed. The IN parameter was not used during the execution of the stored procedure yet it effects the OUT parameter... Expected result: The out parameter should change Actual result: -- The out parameter doesn't change. -- Edit this bug report at https://bugs.php.net/bug.php?id=61490&edit=1
Bug #55328 [Opn->Fbk]: bug in PDOStatement::bindColumn()
Edit report at https://bugs.php.net/bug.php?id=55328&edit=1 ID: 55328 Updated by: ssuffic...@php.net Reported by:filakhtov at gmail dot com Summary:bug in PDOStatement::bindColumn() -Status: Open +Status: Feedback Type: Bug Package:PDO related Operating System: debian squeeze PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. >From your last comment it appears you no longer see this as a bug? Did you >find that the method returns False when the column does not exist? Previous Comments: [2011-08-01 17:18:51] filakhtov at gmail dot com Forgot to notice, what FALSE will be returned if column not found in current rowset. [2011-07-31 19:50:46] filakhtov at gmail dot com Description: --- >From manual page: http://www.php.net/pdostatement.bindcolumn%23Parameters --- I'm trying to use PDOStatement::bindColumn() method, but it always return TRUE, if it bound variable to column, and even if it does not. Also it produce a WARNING, ignoring PDO::ATTR_ERRMODE value, but seems warning reporting is now fixed in snapshots. I think it should return FALSE on failure (that is what written in docs). P. S. Sorry me for my bad english... Expected result: return FALSE if column does not bound successfully Actual result: -- TRUE, if column is bound or if it is not -- Edit this bug report at https://bugs.php.net/bug.php?id=55328&edit=1
Bug #64483 [Opn]: PDO fetch method causes server reset
Edit report at https://bugs.php.net/bug.php?id=64483&edit=1
ID: 64483
Updated by: ssuffic...@php.net
Reported by:shrimpwagon at yahoo dot com
Summary:PDO fetch method causes server reset
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux 3.2.0-4-686-pae
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
I tried the current PHP5.4 branch and this seems to work. I get a row count of
"-1" using the CLI.
Linux 3.9.0-3-generic #8-Ubuntu SMP Tue May 28 18:40:41 UTC 2013 x86_64 x86_64
x86_64 GNU/Linux
FreeTDS 0.91-4
Previous Comments:
[2013-03-28 14:01:22] shrimpwagon at yahoo dot com
Anything? What's the status???
[2013-03-22 14:26:37] shrimpwagon at yahoo dot com
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb7ddfc16 in kill () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#2 0xb5ec0d9c in zend_mm_panic (message=0xb6494e70 "zend_mm_heap corrupted")
at /home/shawn/setup/php-5.4.13/Zend/zend_alloc.c:92
#3 0xb5ec204a in zend_mm_find_leaks (segment=0x88503f0, b=0x886edd0) at
/home/shawn/setup/php-5.4.13/Zend/zend_alloc.c:1250
#4 0xb5ec21d5 in zend_mm_check_leaks (heap=0x81077e0) at
/home/shawn/setup/php-5.4.13/Zend/zend_alloc.c:1304
#5 0xb5ec2d26 in zend_mm_shutdown (heap=0x81077e0, full_shutdown=0, silent=0)
at /home/shawn/setup/php-5.4.13/Zend/zend_alloc.c:1668
#6 0xb5ec4e5c in shutdown_memory_manager (silent=0, full_shutdown=0) at
/home/shawn/setup/php-5.4.13/Zend/zend_alloc.c:2664
#7 0xb5e794a5 in php_request_shutdown (dummy=0x0) at
/home/shawn/setup/php-5.4.13/main/main.c:1819
#8 0xb6007a66 in php_apache_request_dtor (r=0xb6fb7bf8) at
/home/shawn/setup/php-5.4.13/sapi/apache2handler/sapi_apache2.c:507
#9 0xb6008139 in php_handler (r=0xb6fb7bf8) at
/home/shawn/setup/php-5.4.13/sapi/apache2handler/sapi_apache2.c:679
#10 0x08090d6a in ap_run_handler ()
#11 0x080914f3 in ap_invoke_handler ()
#12 0x080a9a91 in ap_internal_redirect ()
#13 0xb7a0d5f5 in handler_redirect () from
/usr/local/apache2/modules/mod_rewrite.so
#14 0x08090d6a in ap_run_handler ()
#15 0x080914f3 in ap_invoke_handler ()
#16 0x080a8c87 in ap_process_async_request ()
#17 0x080a8d50 in ap_process_request ()
#18 0x080a54a8 in ap_process_http_sync_connection ()
#19 0x080a55b1 in ap_process_http_connection ()
#20 0x0809bebf in ap_run_process_connection ()
#21 0x0809c2f4 in ap_process_connection ()
#22 0x080b16f6 in child_main ()
#23 0x080b1809 in make_child ()
#24 0x080b1d8b in prefork_run ()
#25 0x08074b63 in ap_run_mpm ()
#26 0x0806e52a in main ()
[2013-03-22 04:12:02] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
sorry, don't have a mssql server
[2013-03-21 20:26:01] shrimpwagon at yahoo dot com
"AH00052: child pid 5808 exit signal Segmentation fault (11)". Also getting
"zend_mm_heap corrupted"
I'm not the only one having this issue:
http://serverfault.com/questions/490061/pdo-odbc-error-just-resets-connection
[2013-03-21 19:30:18] shrimpwagon at yahoo dot com
Description:
I can connect fine. The PDOStatement::fetch method causes a web server
connection reset when another method is called after the PDOStatement::execute
method and before the PDOStatement::fetch. See test script.
- Linux version 3.2.0-4-686-pae (debian-ker...@lists.debian.org) (gcc version
4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2
- FreeTDS 0.91
- Apache/2.4.4 (Unix) OpenSSL/1.0.1c
- Connecting to a Microsoft SQL Server 2005 - 9.00.5000.00 (X64)
apt-get install freetds-common freetds-dev freetds-bin tdsodbc unixodbc-dev
./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-zlib
--enable-sockets --with-openssl --with-mysql --with-mcrypt --enable-mbstring
--enable-bcmath --enable-calendar --with-curl --with-gd --with-bz2
--enable-exif --enable-ftp --with-gettext --with-mhash --with-mysqli
--enable-soap --enable-wddx --enable-zip --with-pdo-mysql
--with-pdo-odbc=unixODBC,/usr
Test script:
---
$db = new PDO('odbc:Driver=FreeTDS; Server=127.0.0.1; Port=1433;
Database=mssqldb', 'mssqluser', 'mssqlpass');
$statement = $db->prepare('SELECT * FROM table');
$statement->ex
Bug #55826 [Ana->Fbk]: Multiple PDORow's
Edit report at https://bugs.php.net/bug.php?id=55826&edit=1 ID: 55826 Updated by: ssuffic...@php.net Reported by:grinyad at mail dot ru Summary:Multiple PDORow's -Status: Analyzed +Status: Feedback Type: Bug Package:PDO related Operating System: Windows XP PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2013-06-12 05:01:36] ssuffic...@php.net The rows in your test script return distinct values for PDO_DBLIB in PHP5.4. Which specific PDO driver are you having problems with? [2011-12-24 06:16:13] ssufficool at gmail dot com Another issue with "fixing" this is that many databases (SQLServer) do not support multiple active statements per a database handle/connection. It will throw an error stating there is another active resultset. So, 2 statements requires 2 connections. [2011-09-30 23:07:50] johan...@php.net The issue here is that PDORow contains a pointer to the actual statement instance which is used to receive the data and is then shared over the PDOStatement instance and all PDORows created from there. Changing this is a large change wa can't do for 5.4, which is in beta. Given other issues in there (see recent bug about serialization) I tend to removing it in 5.5, but am not sure if it might bring notable benefits with some database drivers ... [2011-09-30 22:52:32] grinyad at mail dot ru Description: You cant use multiple PDORow's at the same time. Test script: --- fetch(PDO::FETCH_LAZY); print_r($row); $row2 = $stmt->fetch(PDO::FETCH_LAZY); print_r($row); print_r($row2); ?> `$row` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 2 [Title] => Banned ) `$row` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 3 [Title] => Member ) `$row2` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 3 [Title] => Member ) `$row` and `$row2` are the same as last fetch result `$row2`.I mean that every PDORow Object will have the last fetch values. I think this is a bug. -- Edit this bug report at https://bugs.php.net/bug.php?id=55826&edit=1
Bug #65219 [Asn->Csd]: PDO/dblib not working anymore ("use dbName" not sent)
Edit report at https://bugs.php.net/bug.php?id=65219&edit=1
ID: 65219
Updated by: ssuffic...@php.net
Reported by:f dot marquis at of2m dot fr
Summary:PDO/dblib not working anymore ("use dbName" not
sent)
-Status: Assigned
+Status: Closed
Type: Bug
Package:PDO related
Operating System: CentOS 6.4
PHP Version:5.4.17
Assigned To:ssufficool
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of ssufficool
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=d012bdca0319e225435430f89446828642b9810d
Log: Fix Bug #65219 DBSETLDBNAME should be called before login to set DBNAME in
login record
Previous Comments:
[2013-07-08 13:37:43] f dot marquis at of2m dot fr
Description:
All queries to our MSSQL 2008 database (PDO_dblib with freeTDS) are failing
since PHP 5.4.17 (same code)
setting freeTDS into debug mode seems to indicate that the SQL queries are not
sent to the correct database, but to 'master' database, so
queried object are not found.
FreeTDS log with PHP 5.4.17 :
...
(dblib.c:239):dblib_add_connection(0x7f001af738e0, 0x7f002be94540)
(dblib.c:4317):dbsetopt(0x7f002be93a00, 7, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 7)
(dblib.c:4317):dbsetopt(0x7f002be93a00, 17, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 17)
(dblib.c:4317):dbsetopt(0x7f002be93a00, 35, 1, -1)
(dblib.c:761):dbsetlname(0x7f002be93850, Emploi, 14)
(dblib.c:5762):dbsetuserdata(0x7f002be93a00, 0x7f002a851fa0)
(dblib.c:3196):dbcancel(0x7f002be93a00)
(query.c:2155):tds_send_cancel: not in_cancel and idle
(dblib.c:1312):dbcmd(0x7f002be93a00, SELECT col FROM table WHERE id = 1 )
...
FreeTDS log with PHP 5.4.11 (working) :
...
(dblib.c:239):dblib_add_connection(0x7fbc5d3d68e0, 0x7fbc6ec007f0)
(dblib.c:4317):dbsetopt(0x7fbc6ebffe30, 7, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 7)
(dblib.c:4317):dbsetopt(0x7fbc6ebffe30, 17, 2147483647, -1)
(dblib.c:4432):UNIMPLEMENTED dbsetopt(option = 17)
(dblib.c:4317):dbsetopt(0x7fbc6ebffe30, 35, (null), -1)
(dblib.c:7929):dbperror(0x7fbc6ebffe30, 20176, 0)
(dblib.c:7981):20176: "Called dbsetopt with parameter 3 NULL"
(dblib.c:5780):dbgetuserdata(0x7fbc6ebffe30)
(dblib.c:8002):"Called dbsetopt with parameter 3 NULL", client returns 2
(INT_CANCEL)
(dblib.c:1398):dbuse(0x7fbc6ebffe30, Emploi)
(dblib.c:1312):dbcmd(0x7fbc6ebffe30, use [Emploi])
(dblib.c:1319):dbcmd() bufsz = 0
(dblib.c:1369):dbsqlexec(0x7fbc6ebffe30)
(dblib.c:6862):dbsqlsend(0x7fbc6ebffe30)
(mem.c:615):tds_free_all_results()
(util.c:156):Changed query state from IDLE to QUERYING
(write.c:140):tds_put_string converting 12 bytes of "use [Emploi]"
(write.c:168):tds_put_string wrote 24 bytes
(util.c:156):Changed query state from QUERYING to PENDING
(net.c:741):Sending packet
...
You can see that the "use [dbName]" is not sent with the same way. The query is
executed in "master" context, and that's why it's failing.
regression from https://bugs.php.net/bug.php?id=64338 "pdo_dblib can't connect
to Azure SQL"
Test script:
---
$pdo = new \PDO('dblib:host=hostname;dbname=dbname', 'username', 'password');
$stmt = $pdo->query('SELECT col FROM table WHERE id = 1');
var_dump($stmt);
Expected result:
PDOStatement with the matching line from existing table
Actual result:
--
false, with this error : General SQL Server error: Check messages from the SQL
Server [208] (severity 16) => Invalid object name
--
Edit this bug report at https://bugs.php.net/bug.php?id=65219&edit=1
Bug #62803 [Opn->Fbk]: nextRowset not returning false
Edit report at https://bugs.php.net/bug.php?id=62803&edit=1
ID: 62803
Updated by: ssuffic...@php.net
Reported by:jackspr at hotmail dot com
Summary:nextRowset not returning false
-Status: Open
+Status: Feedback
Type: Bug
Package:PDO related
Operating System: Windows Server 2008
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Which PDO driver are you using? I.e. MySQL, MSSQL, DBLIB, PGSQL
Previous Comments:
[2012-08-12 16:09:02] jackspr at hotmail dot com
update
[2012-08-12 16:06:11] jackspr at hotmail dot com
Description:
---
>From manual page: http://www.php.net/pdostatement.nextrowset#refsect1-
pdostatement.nextrowset-seealso
---
nextRowset is not returning false. The code below causes an exception in the
fetchAll line because it is trying to access a result set does not exist.
$r=0
$qy = "CALL getAllInfo()";
$istmt = $con->prepare($qy);
if ($istmt->execute())
{
$outcome = self::SUCCESS;
do
{
$result[$r] = $istmt->fetchAll(PDO::FETCH_ASSOC);
$r++;
}
while($istmt->nextRowset());
}
Test script:
---
$r=0
$qy = "CALL getAllInfo()";
$istmt = $con->prepare($qy);
if ($istmt->execute())
{
$outcome = self::SUCCESS;
do
{
$result[$r] = $istmt->fetchAll(PDO::FETCH_ASSOC);
$r++;
}
while($istmt->nextRowset());
}
Expected result:
Clean exit with all possible resultsets in the result array.
Actual result:
--
exception 'PDOException' with message 'SQLSTATE[HY000]: General error'
--
Edit this bug report at https://bugs.php.net/bug.php?id=62803&edit=1
Bug #61123 [Opn->Nab]: PDO_DBLIB out of memory
Edit report at https://bugs.php.net/bug.php?id=61123&edit=1 ID: 61123 Updated by: ssuffic...@php.net Reported by:guillaume dot gruson at gmail dot com Summary:PDO_DBLIB out of memory -Status: Open +Status: Not a bug Type: Bug Package:PDO related Operating System: debian squeeze 2.6.32-5 PHP Version:5.3SVN-2012-02-17 (SVN) Block user comment: N Private report: N New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Sorry to close this with a canned response, but you need to update to a newer version of PHP to fix this bug. Previous Comments: [2012-02-17 14:17:44] guillaume dot gruson at gmail dot com Description: Hi i meet same problem as this "old" report : https://bugs.php.net/bug.php?id=50755 When querying huge table, i get out of memory error. Seems the patch from this report has never been commited in any branches. I revert pdo_dblib directory to rev 297505 and gave a try to ssufficool's patch, and everything work like a charm with it. So, i didn't understand why it has never been commited ? a mistake ? Thanks. -- Edit this bug report at https://bugs.php.net/bug.php?id=61123&edit=1
Bug #38805 [Opn->Csd]: PDO Truncates Text from SQL Server Text Data Type Field
Edit report at https://bugs.php.net/bug.php?id=38805&edit=1
ID: 38805
Updated by: ssuffic...@php.net
Reported by:gkrajci at arescorporation dot com
Summary:PDO Truncates Text from SQL Server Text Data Type
Field
-Status: Open
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Windows NT PBMA-WB2 5.2 build 37
PHP Version:5.1.6
-Assigned To:
+Assigned To:ssufficool
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-12-04 02:48:51] ssuffic...@php.net
This bug has been fixed in SVN.
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.
[2010-12-17 21:07:48] ka...@php.net
.
[2010-03-04 20:55:06] juan dot pineda at resultstel dot com
I solved this problem by adding to my php script a TEXTSIZE that is less than
the allowed memory from the MSSQL server.
Remember, all the number are in Bytes, so I kept playing with the numbers,
until this worked:
// ranges from 0 - 3145728 = 3Megabytes. Default to 4096.
$sql = "SET TEXTSIZE 3145728";
mssql_query($sql, $db) or die(mssql_get_last_message());
Remember to always know what the allowed upload size for your server is.
I hope this helps someone
[2010-02-12 16:57:02] s...@php.net
Those changes are still in SVN. That means the TEXTLIMIT var is being set to
its highest possible value, which in turn means that truncation shouldn't be an
issue now.
$pdo->query('SET TEXTSIZE 30');
should work from PHP 5.2.11 up, it just needs doccing.
[2010-02-12 09:05:28] philipp at servicemail24 dot de
This problem is actually fixed in cvs:
http://www.mail-archive.com/php-cvs@lists.php.net/msg40731.html
http://www.mail-archive.com/php-cvs@lists.php.net/msg40711.html
Here is the working source code:
http://cvs.php.net/viewvc.cgi/php-src/ext/pdo_dblib/
I have no idea why these fixes aren't included in the 5.2 and 5.3 releases!
@sfox can you ensure that pdo_dblib is updated with the release of 5.2.13 and
5.3.2?
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
https://bugs.php.net/bug.php?id=38805
--
Edit this bug report at https://bugs.php.net/bug.php?id=38805&edit=1
Bug #50755 [Opn->Csd]: PDO DBLIB Fails with OOM
Edit report at http://bugs.php.net/bug.php?id=50755&edit=1
ID: 50755
Updated by: ssuffic...@php.net
Reported by: ssufficool at gmail dot com
Summary: PDO DBLIB Fails with OOM
-Status: Open
+Status: Closed
Type: Bug
Package: PDO related
Operating System: Linux 2.6.30-gentoo-r2
-PHP Version: 5.2 / 5.3 / 6
+PHP Version: 5.2 / 5.3
-Assigned To:
+Assigned To: ssufficool
New Comment:
Fixed in revision 32.
Previous Comments:
[2010-05-31 20:38:25] ssuffic...@php.net
Automatic comment from SVN on behalf of ssufficool
Revision: http://svn.php.net/viewvc/?view=revision&revision=32
Log: Fix bug #50755 & Enable multiple rowsets [DOC]
[2010-05-30 22:45:02] golgote at gmail dot com
This patch makes pdo_dblib finally usable with large databases, it would
be nice
if devs could review it. Eventually, I suggest you also post a bug
report on PECL
if you think you don't have enough visibility here.
[2010-03-29 07:22:14] ssufficool at gmail dot com
This has also been tested with latest and greatest FreeTDS 0,82 on
Ubuntu x86 & amd64. Same results, out of memory. The memory allocation
is on the PDO side, not libtds.
[2010-03-28 22:10:09] eric at pineconehill dot com
we use freetds on debian with sql server 2005, so i'm following this
patch with
some interest. just curious, why freetds 0.64? 0.82 is the latest stable
and fixes
quite a few issues. it's been out for almost 2 years now (whereas 0.63
is 5 years
old in a couple of weeks).
[2010-03-20 00:32:04] ssufficool at gmail dot com
Patch revised:
1. Reverted driver always registering as dblib.
Question: Should the user really have to know the library the extension
was compiled against? Seems like we should settle on a constant
registration since you really can't mix and match.
2. Reverted whitespace modifications. Removed spurrious comments.
Reverted DBSETOPT --> dbsetopt.
3. Reverted SYB* --> SQL* define deletions. These are required for
compile against the depreciated MS DBLIB.
4. Removed automagic compute column naming (which was clobbering library
memory). Just return what the server returns including empty strings.
The user will need to alias in their sql query as "select 1+1 as
oneplusone" instead of just "select 1+1" magically returning
array('compute1'=>'2').
Question: Who if anyone relies on this behavior? I don't see other
drivers doing this.
Some unrelated/unmentioned "fixes"
Allow multiple rowsets with varying column definitions. This was
implemented incorrectly.
Include the recent update to SQLMONEY formatting.
Tested against SQL Server 2008 Express, PHP-5.3 svn-296442, FreeTDS
0.64, Linux 2.6.30 - i686.
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/bug.php?id=50755
--
Edit this bug report at http://bugs.php.net/bug.php?id=50755&edit=1
Bug #47589 [Bgs->Csd]: PDO DBLIB Fails with OOM on large recordsets
Edit report at http://bugs.php.net/bug.php?id=47589&edit=1
ID: 47589
Updated by: ssuffic...@php.net
Reported by: ssufficool at gmail dot com
Summary: PDO DBLIB Fails with OOM on large recordsets
-Status: Bogus
+Status: Closed
Type: Bug
Package: PDO related
Operating System: Linux (Gentoo)
PHP Version: 5.2.9
-Assigned To:
+Assigned To: ssufficool
New Comment:
Fixed in revision 32.
Previous Comments:
[2010-01-14 18:52:49] ssufficool at gmail dot com
new e-mail
[2010-01-14 18:20:33] ssufficool at roadrunner dot com
Please re-open this bug. I understand that the behaviour is shared
across the PDO::DBLIB and MSSQL_* functions, however other PDO drivers
do not have this issue (I.E. PDO:POSTGRESQL) and the same query issued
on the command line via freetds (tsql) does not consume memory like
this.
I am using a CURSOR_FWDONLY and this should not require buffering all
the rows on the client.
[2009-03-06 17:04:47] ssufficool at roadrunner dot com
My understanding of Bogus is indeed Bogus. After setting batchsize to 0
in php.ini, mssql_query also barfs on large recordssets.
Apologies for the noise.
[2009-03-06 16:36:43] ssufficool at gmail dot com
Description:
When pulling large recordsets with PDO DBLIB I get out of memory.
This type of large recordset query works fine on mssql_* functions using
the freetds library. This issue has been marked "Bogus" in the past. But
since this works with other functions using FreeTDS, this issue may lie
in the PDO layer.
Correct me if my understanding of Bogus is Bogus.
Reproduce code:
---
$pdo_ms = new PDO('dblib: host=host', 'user','pass');
/* We die here */
$rs = $pdo_ms->query("SELECT TOP 5 from aVeryLargeTable");
Expected result:
A valid handle to a resultset in $rs
Actual result:
--
Available memory exhausted, tried to allocate
--
Edit this bug report at http://bugs.php.net/bug.php?id=47589&edit=1
Bug #43561 [Bgs->Csd]: Selecting large numbers of rows results in OOM
Edit report at http://bugs.php.net/bug.php?id=43561&edit=1 ID: 43561 Updated by: ssuffic...@php.net Reported by: php at seven dot net dot nz Summary: Selecting large numbers of rows results in OOM -Status: Bogus +Status: Closed Type: Bug Package: PDO related Operating System: Linux PHP Version: 5.2.5 -Assigned To: +Assigned To: ssufficool New Comment: Fixed in revision 32. Previous Comments: [2007-12-11 16:06:19] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The driver maybe pre-allocating memory at the time of the fetch, hence the OOM. [2007-12-11 07:56:06] php at seven dot net dot nz Description: Selecting a large number of rows in a prepared statement results in an OOM error after execute() is called. The SQL server is located on a different box. I have not been able to pinpoint the exact number of rows as it is a moving target. It has failed on as low as 20k and as high as 50k. Obviously it would result in OOM if I had selected everything into an array, but from what I gather results should not be being sent to PHP until the fetchXYZ functions are called. Or am I wrong? It worked with 5.2.0 on the same box. Reproduce code: --- prepare ($query); $statement->execute (); ?> Expected result: Query to execute Actual result: -- Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4 bytes) in /www/data/realestate-dev/scripts/htdocs/cron/rebuild_listings.php on line 12 -- Edit this bug report at http://bugs.php.net/bug.php?id=43561&edit=1
Req #45876 [Asn->Csd]: PDO: DBLIB does not support getColumnMeta
Edit report at http://bugs.php.net/bug.php?id=45876&edit=1
ID: 45876
Updated by: ssuffic...@php.net
Reported by: ssufficool at rov dot sbcounty dot gov
Summary: PDO: DBLIB does not support getColumnMeta
-Status: Assigned
+Status: Closed
Type: Feature/Change Request
Package: *General Issues
Operating System: Gentoo Linux
PHP Version: 5.2.6
Assigned To: ssufficool
New Comment:
Fixed in revision 300627.
Previous Comments:
[2010-06-21 08:54:12] ssuffic...@php.net
Automatic comment from SVN on behalf of ssufficool
Revision: http://svn.php.net/viewvc/?view=revision&revision=300627
Log: Fix bug #45876 adding get column meta
[2008-08-20 21:40:48] ssufficool at rov dot sbcounty dot gov
Description:
When using the mssql_* functions it is possible to read column meta data
using mssql_fetch_field in conjunction with the freetds library. However
it is not possible to use PDOStatement::getColumnMeta using the same
library.
The library must support this functionality in some way even if limited,
the additional attributes may be set to false or NULL.
Reproduce code:
---
$conn = new PDO("dblib:host=myhost","user","pass");
$rs = $conn->query("SELECT * FROM SOMETABLE");
print_r($rs->getColumnMeta(0));
Expected result:
Array(
"key" => "value",
"key" => "value",
"key" => "value",
"key" => "value"
);
Actual result:
--
Warning: PDOStatement::getColumnMeta() [pdostatement.getcolumnmeta]:
SQLSTATE[IM001]: Driver does not support this function: driver doesn't
support meta data
--
Edit this bug report at http://bugs.php.net/bug.php?id=45876&edit=1
Req #42403 [Opn->Dup]: Field Attributes
Edit report at http://bugs.php.net/bug.php?id=42403&edit=1
ID: 42403
Updated by: ssuffic...@php.net
Reported by: ssufficool at rov dot sbcounty dot gov
Summary: Field Attributes
-Status: Open
+Status: Duplicate
Type: Feature/Change Request
-Package: Feature/Change Request
+Package: *General Issues
Operating System: Linux
PHP Version: 5.2.3
New Comment:
Duplicate of bug #45876
Previous Comments:
[2007-08-23 21:28:28] ssufficool at rov dot sbcounty dot gov
Description:
The PDO getColumnMeta does not return all of the attributes that the
mssql_* functions return using FreeTDS or DBLIB.
Reproduce code:
---
query('SELECT fruit_name FROM fruit');
$meta = $select->getColumnMeta(0);
var_dump($meta);
?>
Expected result:
the proper length, not -1 and type of the character field along with
other attributes provided by mssql_field_* functions
Actual result:
--
field length of -1 along with other invalid/unknown attributes
--
Edit this bug report at http://bugs.php.net/bug.php?id=42403&edit=1
Req #38955 [Opn->Csd]: PDO DBLIB driver does not support transactions
Edit report at http://bugs.php.net/bug.php?id=38955&edit=1
ID: 38955
Updated by: ssuffic...@php.net
Reported by: remery at seminolesheriff dot org
Summary: PDO DBLIB driver does not support transactions
-Status: Open
+Status: Closed
Type: Feature/Change Request
-Package: Feature/Change Request
+Package: *General Issues
Operating System: Linux
PHP Version: 5.1.6
-Assigned To:
+Assigned To: ssufficool
New Comment:
This bug has been fixed in SVN.
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.
Fixed in revision 300628.
Previous Comments:
[2010-06-21 09:30:50] ssuffic...@php.net
Automatic comment from SVN on behalf of ssufficool
Revision: http://svn.php.net/viewvc/?view=revision&revision=300628
Log: Fix bug #38955 - add transaction support
[2006-09-26 08:46:57] tony2...@php.net
No bug here, reclassified as feature request.
[2006-09-25 18:43:10] remery at seminolesheriff dot org
Description:
I'm connecting from a Linux/Apache/PHP server to a Microsoft SQL Server
2000 database using PDO with the DBLIB driver. Attempting to use
transactions produces the exception 'This driver doesn't support
transactions'.
Reproduce code:
---
$dsn = 'dblib:host=' . $server . ';dbname=' . $dbName;
$user = 'tempUser';
$pwd = 'tmpPwd';
$table = 'sqlTable';
$column = 'colName';
$value = 'value';
$sql = 'Insert Into ' . $dbName;
$sql .= ' (' . $column . ')';
$sql .= ' Values ' . $value;
$conn = new PDO($dsn, $user, $pwd);
$conn->beginTransaction();
$conn->exec($sql);
$conn->commit();
Expected result:
The value should be inserted into the table.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message 'This driver
doesn't support transactions' in /var/www/html/business/entity.php:37
Stack trace: #0 /var/www/html/business/entity.php(37):
PDO->beginTransaction() #1 {main} thrown in
/var/www/html/business/entity.php on line 37
--
Edit this bug report at http://bugs.php.net/bug.php?id=38955&edit=1
Req #38955 [Csd]: PDO DBLIB driver does not support transactions
Edit report at http://bugs.php.net/bug.php?id=38955&edit=1
ID: 38955
Updated by: ssuffic...@php.net
Reported by: remery at seminolesheriff dot org
Summary: PDO DBLIB driver does not support transactions
Status: Closed
Type: Feature/Change Request
Package: *General Issues
Operating System: Linux
PHP Version: 5.1.6
Assigned To: ssufficool
New Comment:
Fixed in trunk.
revision 300628.
Previous Comments:
[2010-06-21 09:31:49] ssuffic...@php.net
This bug has been fixed in SVN.
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.
Fixed in revision 300628.
[2010-06-21 09:30:50] ssuffic...@php.net
Automatic comment from SVN on behalf of ssufficool
Revision: http://svn.php.net/viewvc/?view=revision&revision=300628
Log: Fix bug #38955 - add transaction support
[2006-09-26 08:46:57] tony2...@php.net
No bug here, reclassified as feature request.
[2006-09-25 18:43:10] remery at seminolesheriff dot org
Description:
I'm connecting from a Linux/Apache/PHP server to a Microsoft SQL Server
2000 database using PDO with the DBLIB driver. Attempting to use
transactions produces the exception 'This driver doesn't support
transactions'.
Reproduce code:
---
$dsn = 'dblib:host=' . $server . ';dbname=' . $dbName;
$user = 'tempUser';
$pwd = 'tmpPwd';
$table = 'sqlTable';
$column = 'colName';
$value = 'value';
$sql = 'Insert Into ' . $dbName;
$sql .= ' (' . $column . ')';
$sql .= ' Values ' . $value;
$conn = new PDO($dsn, $user, $pwd);
$conn->beginTransaction();
$conn->exec($sql);
$conn->commit();
Expected result:
The value should be inserted into the table.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message 'This driver
doesn't support transactions' in /var/www/html/business/entity.php:37
Stack trace: #0 /var/www/html/business/entity.php(37):
PDO->beginTransaction() #1 {main} thrown in
/var/www/html/business/entity.php on line 37
--
Edit this bug report at http://bugs.php.net/bug.php?id=38955&edit=1
Bug #52134 [Opn->Csd]: pdo_dblib returns 40 char strings for int
Edit report at http://bugs.php.net/bug.php?id=52134&edit=1
ID: 52134
Updated by: ssuffic...@php.net
Reported by: ssufficool at gmail dot com
Summary: pdo_dblib returns 40 char strings for int
-Status: Open
+Status: Closed
Type: Bug
Package: PDO related
Operating System: Linux
PHP Version: trunk-SVN-2010-06-21 (SVN)
-Assigned To:
+Assigned To: ssufficool
New Comment:
Fixed in trunk revision 300646.
Previous Comments:
[2010-06-22 04:09:58] ssuffic...@php.net
Automatic comment from SVN on behalf of ssufficool
Revision: http://svn.php.net/viewvc/?view=revision&revision=300646
Log: Fix bug #52134
[2010-06-21 22:52:48] ssufficool at gmail dot com
Description:
pdo_dblib is not returning the correct string length after converting
the data.
Test script:
---
$row = $stmt->fetch(PDO::FETCH_ASSOC);
var_dump($row);
Expected result:
array(2) {
["id"]=>
string(2) "13"
["flag"]=>
string(1) "0"
}
Actual result:
--
array(2) {
["id"]=>
string(40) "13 "
["flag"]=>
string(40) "0 "
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52134&edit=1
Bug->Req #47588 [Fbk->Opn]: PDO_DBLIB: barfs on quoted field names
Edit report at http://bugs.php.net/bug.php?id=47588&edit=1
ID: 47588
Updated by: ssuffic...@php.net
Reported by: ssufficool at roadrunner dot com
Summary: PDO_DBLIB: barfs on quoted field names
-Status: Feedback
+Status: Open
-Type: Bug
+Type: Feature/Change Request
Package: PDO related
Operating System: Linux Gentoo 2.6.x
PHP Version: 5.3-svn
-Assigned To:
+Assigned To: ssufficool
Previous Comments:
[2010-04-24 01:03:18] fel...@php.net
But this patch has a side effect, when using for example... 'where foo =
"bar"', the "bar" will be identified as an identifier, not a literal.
Right?
----
[2010-03-20 00:50:02] ssufficool at roadrunner dot com
Set quoted identifiers to allow "FIELD NAME" quoting style.
Index: ext/pdo_dblib/dblib_driver.c
===
--- ext/pdo_dblib/dblib_driver.c(revision 296453)
+++ ext/pdo_dblib/dblib_driver.c(working copy)
@@ -236,6 +236,9 @@
/* limit text/image from network */
DBSETOPT(H->link, DBTEXTSIZE, "2147483647");
+ /* Allow double quoted field and table names */
+ DBSETOPT(H->link, DBQUOTEDIDENT, NULL);
+
if (vars[3].optval && FAIL == dbuse(H->link, vars[3].optval)) {
goto cleanup;
}
----
[2009-05-15 19:43:17] ssufficool at roadrunner dot com
Solution:
tsql from freetds package set the following where PDO does not:
set quoted_identifier on
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
Since this is default behavior of FreeTDS (tsql) and NT DBLIB (isql), I
assume it should be for PDO dblib as well.
----
[2009-03-06 16:13:33] ssufficool at roadrunner dot com
Description:
When passing a query containing double quoted field names, the query
fails.
Reproduce code:
---
$pdo_ms = new PDO('dblib:host=db01;dbname=database',
$_SESSION['user'], $_SESSION['pass'], array(PDO::ATTR_ERRMODE =>
PDO::ERRMODE_EXCEPTION ) );
$rs = $pdo_ms->prepare('SELECT "myView"."FieldName" from "myView" order
by "Some Field"')
Expected result:
A valid handle to a stmt in $rs
Actual result:
--
SQLSTATE[HY000]: General error: 20018 Incorrect syntax near 'FieldName'.
[20018] (severity 5) [(null)]
--
Edit this bug report at http://bugs.php.net/bug.php?id=47588&edit=1
Req #52137 [Opn->Csd]: pdo_dblib does not implement lastInsertId
Edit report at http://bugs.php.net/bug.php?id=52137&edit=1 ID: 52137 Updated by: ssuffic...@php.net Reported by: ssuffic...@php.net Summary: pdo_dblib does not implement lastInsertId -Status: Open +Status: Closed Type: Feature/Change Request Package: PDO related Operating System: Linux PHP Version: trunk-SVN-2010-06-22 (SVN) -Assigned To: +Assigned To: ssufficool New Comment: This bug has been fixed in SVN. 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. Fixed in revision 300647. Previous Comments: [2010-06-22 04:59:54] ssuffic...@php.net Automatic comment from SVN on behalf of ssufficool Revision: http://svn.php.net/viewvc/?view=revision&revision=300647 Log: Fix bug #52137 - implement lastInsertId [2010-06-22 04:58:34] ssuffic...@php.net Description: sql server and sybase have @@IDENTITY function to return the last inserted id from a table but this is not implemented in pdo_dblib Test script: --- echo $pdo->lastInsertId() Expected result: a number Actual result: -- throws not implemented -- Edit this bug report at http://bugs.php.net/bug.php?id=52137&edit=1
Req #47588 [Asn->Csd]: PDO_DBLIB: barfs on quoted field names
Edit report at http://bugs.php.net/bug.php?id=47588&edit=1
ID: 47588
Updated by: ssuffic...@php.net
Reported by: ssufficool at roadrunner dot com
Summary: PDO_DBLIB: barfs on quoted field names
-Status: Assigned
+Status: Closed
Type: Feature/Change Request
Package: PDO related
Operating System: Linux Gentoo 2.6.x
PHP Version: 5.3-svn
Assigned To: ssufficool
New Comment:
This bug has been fixed in SVN.
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.
Fixed in trunk
Previous Comments:
[2010-06-23 03:29:03] ssuffic...@php.net
Automatic comment from SVN on behalf of ssufficool
Revision: http://svn.php.net/viewvc/?view=revision&revision=300685
Log: Fix Bug #47588 - Allow Quoted Identifiers
[2010-04-24 01:03:18] fel...@php.net
But this patch has a side effect, when using for example... 'where foo =
"bar"', the "bar" will be identified as an identifier, not a literal.
Right?
----
[2010-03-20 00:50:02] ssufficool at roadrunner dot com
Set quoted identifiers to allow "FIELD NAME" quoting style.
Index: ext/pdo_dblib/dblib_driver.c
===
--- ext/pdo_dblib/dblib_driver.c(revision 296453)
+++ ext/pdo_dblib/dblib_driver.c(working copy)
@@ -236,6 +236,9 @@
/* limit text/image from network */
DBSETOPT(H->link, DBTEXTSIZE, "2147483647");
+ /* Allow double quoted field and table names */
+ DBSETOPT(H->link, DBQUOTEDIDENT, NULL);
+
if (vars[3].optval && FAIL == dbuse(H->link, vars[3].optval)) {
goto cleanup;
}
----
[2009-05-15 19:43:17] ssufficool at roadrunner dot com
Solution:
tsql from freetds package set the following where PDO does not:
set quoted_identifier on
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
Since this is default behavior of FreeTDS (tsql) and NT DBLIB (isql), I
assume it should be for PDO dblib as well.
----
[2009-03-06 16:13:33] ssufficool at roadrunner dot com
Description:
When passing a query containing double quoted field names, the query
fails.
Reproduce code:
---
$pdo_ms = new PDO('dblib:host=db01;dbname=database',
$_SESSION['user'], $_SESSION['pass'], array(PDO::ATTR_ERRMODE =>
PDO::ERRMODE_EXCEPTION ) );
$rs = $pdo_ms->prepare('SELECT "myView"."FieldName" from "myView" order
by "Some Field"')
Expected result:
A valid handle to a stmt in $rs
Actual result:
--
SQLSTATE[HY000]: General error: 20018 Incorrect syntax near 'FieldName'.
[20018] (severity 5) [(null)]
--
Edit this bug report at http://bugs.php.net/bug.php?id=47588&edit=1
Bug #45951 [Opn->Csd]: PDO_MSSQL problem if query return no result
Edit report at http://bugs.php.net/bug.php?id=45951&edit=1
ID: 45951
Updated by: ssuffic...@php.net
Reported by: grzegorz at heex dot pl
Summary: PDO_MSSQL problem if query return no result
-Status: Open
+Status: Closed
Type: Bug
Package: PDO related
Operating System: Windows XP Sp3
PHP Version: 5.2.6
-Assigned To:
+Assigned To: ssufficool
New Comment:
Tried to reproduce with code in trunk, returns expected results.
$db->query("create table test (id int not null primary key)");
$db->query("insert into test(id) values(2)");
$sth = $db->prepare("SELECT id FROM test WHERE id=:parentId");
$sth->execute(array(':parentId'=>1));
$res1 = $sth->fetchAll();
var_dump($res1);
$sth->execute(array(':parentId'=>2));
$res2 = $sth->fetchAll();
var_dump($res2);
array(0) {
}
array(1) {
[0]=>
array(2) {
["id"]=>
string(1) "2"
[0]=>
string(1) "2"
}
}
Previous Comments:
[2009-06-11 07:56:54] grzegorz at heex dot pl
I couldn't connect to MSSQL so I've exchanged ntwdblib.dll (v.7.00.839)
to (v.8.00.194).
No result is:
$res1 = array[0] //empty
$res2 = array[
0 = array['[]' => null, 0 => null]
1 = array['[]' => null, 0 => null]
]
( [] = ASCII 0x11 )
and should be:
$res2 = array[
0 = array['value' => 3, 0 => 3]
1 = array['value' => 6, 0 => 6]
]
[2009-05-03 01:00:17] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-04-25 15:11:00] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-08-29 18:02:13] grzegorz at heex dot pl
Statetment should be:
$sth = $pdo->prepare("SELECT value FROM sometable WHERE id=:parentId");
[2008-08-29 17:55:31] grzegorz at heex dot pl
Description:
If PDO_MSSQL PDOStatement is called 2 times and the first returned no
result than second one return strange result.
PDO_MYSQL works fine.
Tested on Apache and IIS
Reproduce code:
---
$pdo = new PDO("mssql:host=[host];dbname=[base]",[user],[pass]);
$sth = $pdo->prepare("SELECT id FROM sometable WHERE id=:parentId");
$sth->execute(array(':parentId'=>1));
//or
//$sth->bindValue(':parentId',1,PDO::PARAM_INT);
$res1 = $sth->fetchAll();
$sth->closeCursor();
$sth->execute(array(':parentId'=>2));
//or
//$sth->bindValue(':parentId',2,PDO::PARAM_INT);
$res2 = $sth->fetchAll();
$sth->closeCursor();
Expected result:
$res1 = array[0] //empty
$res2 = array[
0 = array['value' => 3]
1 = array['value' => 6]
]
Actual result:
--
$res1 = array[0] //empty
$res2 = array[
0 = array['[]' => null]
1 = array['[]' => null]
]
--
Edit this bug report at http://bugs.php.net/bug.php?id=45951&edit=1
Bug #45951 [Csd]: PDO_MSSQL problem if query return no result
Edit report at http://bugs.php.net/bug.php?id=45951&edit=1
ID: 45951
Updated by: ssuffic...@php.net
Reported by: grzegorz at heex dot pl
Summary: PDO_MSSQL problem if query return no result
Status: Closed
Type: Bug
Package: PDO related
Operating System: Windows XP Sp3
PHP Version: 5.2.6
Assigned To: ssufficool
New Comment:
Please try version in SVN trunk. This bug cannot be reproduced with the
code in trunk,
Previous Comments:
[2010-07-12 05:30:13] ssuffic...@php.net
Tried to reproduce with code in trunk, returns expected results.
$db->query("create table test (id int not null primary key)");
$db->query("insert into test(id) values(2)");
$sth = $db->prepare("SELECT id FROM test WHERE id=:parentId");
$sth->execute(array(':parentId'=>1));
$res1 = $sth->fetchAll();
var_dump($res1);
$sth->execute(array(':parentId'=>2));
$res2 = $sth->fetchAll();
var_dump($res2);
array(0) {
}
array(1) {
[0]=>
array(2) {
["id"]=>
string(1) "2"
[0]=>
string(1) "2"
}
}
[2009-06-11 07:56:54] grzegorz at heex dot pl
I couldn't connect to MSSQL so I've exchanged ntwdblib.dll (v.7.00.839)
to (v.8.00.194).
No result is:
$res1 = array[0] //empty
$res2 = array[
0 = array['[]' => null, 0 => null]
1 = array['[]' => null, 0 => null]
]
( [] = ASCII 0x11 )
and should be:
$res2 = array[
0 = array['value' => 3, 0 => 3]
1 = array['value' => 6, 0 => 6]
]
[2009-05-03 01:00:17] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-04-25 15:11:00] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-08-29 18:02:13] grzegorz at heex dot pl
Statetment should be:
$sth = $pdo->prepare("SELECT value FROM sometable WHERE id=:parentId");
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/bug.php?id=45951
--
Edit this bug report at http://bugs.php.net/bug.php?id=45951&edit=1
Bug #50555 [Opn]: Cannot retrieve output parameter from stored procedure
Edit report at http://bugs.php.net/bug.php?id=50555&edit=1
ID: 50555
Updated by: ssuffic...@php.net
Reported by:david dot wright at opticsplanet dot com
Summary:Cannot retrieve output parameter from stored
procedure
Status: Open
Type: Bug
Package:PDO related
Operating System: 2.6.24-24-server
PHP Version:5.3.1
Block user comment: N
New Comment:
This requires that pdo_dblib pass params using the RPC mechanisms and
also to implement it's own driver level binding instead of relying on
the PDO param binding. This will require a rewrite of most of the
statement object.
Rest assured, it is being worked on but may take some time.
Previous Comments:
[2010-04-09 10:50:34] a at exampl dot com
For fucks sake would anybody already fix this? It's not the only report
about this issue in the tracker.
[2009-12-22 22:09:39] david dot wright at opticsplanet dot com
Description:
I cannot retrieve an output parameter from a stored procedure (in my
case on SQL Server 2005--am using PDO_DBLIB.
Reproduce code:
---
PHP Code:
---
/** SNIP. Set up a valid $db here! **/
$return_value = 999;
$sth = $db->prepare("EXEC dbo.opsp_Test ?");
$sth->bindParam(1, $return_value, PDO::PARAM_STR |
PDO::PARAM_INPUT_OUTPUT, 4);
$sth->execute();
echo "$return_value\n";
Stored Procedure
--
CREATE PROCEDURE opsp_Test
@TheOutputValue int OUTPUT
AS
BEGIN
SET @TheOutputValue = 11
END
Expected result:
output should be: 11
Actual result:
--
Output is 999 ($return_value unchanged)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50555&edit=1
Req #38955 [Csd]: PDO DBLIB driver does not support transactions
Edit report at http://bugs.php.net/bug.php?id=38955&edit=1 ID: 38955 Updated by: ssuffic...@php.net Reported by:remery at seminolesheriff dot org Summary:PDO DBLIB driver does not support transactions Status: Closed Type: Feature/Change Request Package:*General Issues Operating System: Linux PHP Version:5.1.6 Assigned To:ssufficool Block user comment: N Private report: N New Comment: The whole of the PDO DBLIB needs to me moved to a release. There are many fixes and features as well as new tests. I have lobbied for these changes several times, now it is up to the release manager. Previous Comments: [2011-04-29 22:36:14] urkle at outoforder dot cc What is the timeline for this getting into an official 5.3 release? I have manually patched my version and can confirm it works on Mac OS X 10.6.6 running PHP 5.3.3. (though compiled PDO_DBLIB with this patch from the 5.3.5 release) [2010-06-21 09:32:49] ssuffic...@php.net Fixed in trunk. revision 300628. [2010-06-21 09:31:49] ssuffic...@php.net This bug has been fixed in SVN. 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. Fixed in revision 300628. [2010-06-21 09:30:50] ssuffic...@php.net Automatic comment from SVN on behalf of ssufficool Revision: http://svn.php.net/viewvc/?view=revision&revision=300628 Log: Fix bug #38955 - add transaction support [2006-09-26 08:46:57] tony2...@php.net No bug here, reclassified as feature request. 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/bug.php?id=38955 -- Edit this bug report at http://bugs.php.net/bug.php?id=38955&edit=1
Req #38955 [Csd]: PDO DBLIB driver does not support transactions
Edit report at http://bugs.php.net/bug.php?id=38955&edit=1 ID: 38955 Updated by: ssuffic...@php.net Reported by:remery at seminolesheriff dot org Summary:PDO DBLIB driver does not support transactions Status: Closed Type: Feature/Change Request Package:*General Issues Operating System: Linux PHP Version:5.1.6 Assigned To:ssufficool Block user comment: N Private report: N New Comment: I do not see a practical way to PECL this because PDO is already core to PHP and marked depreciated in PECL. Previous Comments: [2011-04-30 20:32:05] paj...@php.net I don't see why you could do releases via PECL as well. That will free you from the slower PHP release cycles. [2011-04-30 17:48:38] ssuffic...@php.net The whole of the PDO DBLIB needs to me moved to a release. There are many fixes and features as well as new tests. I have lobbied for these changes several times, now it is up to the release manager. [2011-04-29 22:36:14] urkle at outoforder dot cc What is the timeline for this getting into an official 5.3 release? I have manually patched my version and can confirm it works on Mac OS X 10.6.6 running PHP 5.3.3. (though compiled PDO_DBLIB with this patch from the 5.3.5 release) [2010-06-21 09:32:49] ssuffic...@php.net Fixed in trunk. revision 300628. [2010-06-21 09:31:49] ssuffic...@php.net This bug has been fixed in SVN. 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. Fixed in revision 300628. 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/bug.php?id=38955 -- Edit this bug report at http://bugs.php.net/bug.php?id=38955&edit=1
Req #38955 [Csd]: PDO DBLIB driver does not support transactions
Edit report at http://bugs.php.net/bug.php?id=38955&edit=1 ID: 38955 Updated by: ssuffic...@php.net Reported by:remery at seminolesheriff dot org Summary:PDO DBLIB driver does not support transactions Status: Closed Type: Feature/Change Request Package:*General Issues Operating System: Linux PHP Version:5.1.6 Assigned To:ssufficool Block user comment: N Private report: N New Comment: No developer cares about it, but plenty of users have and do care. I don't use PHP much anymore, but that may change. When it does, I will consider maintaining this in two different places. Until then, the patches are here and the currently working and tested module resides in svn trunk. Previous Comments: [2011-04-30 21:19:14] paj...@php.net It is marked as such because nobody cares about it. And before you came in, it should have marked as such in core as well. Anyway, I do it for zip, enchant and planing to do so for more extensions as well. This is a very good way to provide more frequent releases to our users and especially to the distros. [2011-04-30 21:04:23] ssuffic...@php.net I do not see a practical way to PECL this because PDO is already core to PHP and marked depreciated in PECL. [2011-04-30 20:32:05] paj...@php.net I don't see why you could do releases via PECL as well. That will free you from the slower PHP release cycles. [2011-04-30 17:48:38] ssuffic...@php.net The whole of the PDO DBLIB needs to me moved to a release. There are many fixes and features as well as new tests. I have lobbied for these changes several times, now it is up to the release manager. [2011-04-29 22:36:14] urkle at outoforder dot cc What is the timeline for this getting into an official 5.3 release? I have manually patched my version and can confirm it works on Mac OS X 10.6.6 running PHP 5.3.3. (though compiled PDO_DBLIB with this patch from the 5.3.5 release) 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/bug.php?id=38955 -- Edit this bug report at http://bugs.php.net/bug.php?id=38955&edit=1
Bug #63258 [Asn]: seg fault with PDO and dblib using DBSETOPT(H->link, DBQUOTEDIDENT, 1);
Edit report at https://bugs.php.net/bug.php?id=63258&edit=1
ID: 63258
Updated by: ssuffic...@php.net
Reported by:paul dot visco at roswellpark dot org
Summary:seg fault with PDO and dblib using DBSETOPT(H->link,
DBQUOTEDIDENT, 1);
Status: Assigned
Type: Bug
Package:PDO related
Operating System: centos 5.8
PHP Version:5.4.7
Assigned To: ssufficool
Block user comment: N
Private report: N
New Comment:
The patch looks legit. I'm not sure why I used 1 instead of null for the
parameter value. I have not posted patches since the source was moved to git.
Please merge this change for me if possible.
Previous Comments:
[2012-10-11 10:23:57] larue...@php.net
ssufficool, do you have time to look into this?
seems you intentionally change the "NULL" to "1" in https://github.com/php/php-
src/commit/36b8c4cb
thanks
[2012-10-11 10:22:26] larue...@php.net
according to MSDN, the fix should be:
diff --git a/ext/pdo_dblib/dblib_driver.c b/ext/pdo_dblib/dblib_driver.c
index 77832f9..baf1dcc 100644
--- a/ext/pdo_dblib/dblib_driver.c
+++ b/ext/pdo_dblib/dblib_driver.c
@@ -315,7 +315,7 @@ static int pdo_dblib_handle_factory(pdo_dbh_t *dbh, zval
*driver_options TSRMLS_
DBSETOPT(H->link, DBTEXTSIZE, "2147483647");
/* allow double quoted indentifiers */
- DBSETOPT(H->link, DBQUOTEDIDENT, 1);
+ DBSETOPT(H->link, DBQUOTEDIDENT, NULL);
see: http://msdn.microsoft.com/en-us/library/aa937147(v=sql.80).aspx
"
Note When you use DBQUOTEDIDENT, you must set param to NULL.
"
[2012-10-10 22:25:17] paul dot visco at roswellpark dot org
Description:
revision #300716 to php source for /ext/pdo_dblib/ which adds support for
double quoted field values causes segfault on our system. According to
https://bugs.php.net/bug.php?id=47588 line 318 was added to support quoted
field names. If pdo_dblib is recompiled without line 318 it works fine, no
segfault. My patch is just commenting out the line, which is really not a
solution but it allows us to be able to use the driver again.
PHP: 5.4.7
SYSTEM: CentOS 5.8
TSQL:
Version: freetds v0.91
freetds.conf directory: /etc
MS db-lib source compatibility: yes
Sybase binary compatibility: yes
Thread safety: yes
iconv library: yes
TDS version: 4.2
iODBC: no
unixodbc: yes
SSPI "trusted" logins: no
Kerberos: yes
Test script:
---
$db = new PDO('dblib:host=somehost.somesite.org;charset=UTF-8;','username',
'password');
Expected result:
Segmentation fault
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x0036b68788e0 in strlen () from /lib64/libc.so.6
(gdb) bt
#0 0x0036b68788e0 in strlen () from /lib64/libc.so.6
#1 0x0036b6846e77 in vfprintf () from /lib64/libc.so.6
#2 0x0036b68e74a7 in __vfprintf_chk () from /lib64/libc.so.6
#3 0x2aaab1e6ece5 in ?? () from /usr/lib64/libsybdb.so.5
#4 0x2aaab1e43dd8 in dbsetopt () from /usr/lib64/libsybdb.so.5
#5 0x2aaab2e51447 in pdo_dblib_handle_factory (dbh=0x2ab0c298,
driver_options=)
at /home/visco/php-5.4.7/ext/pdo_dblib_orig/dblib_driver.c:318
#6 0x2aaab2c40099 in zim_PDO_dbh_constructor (ht=,
return_value=,
return_value_ptr=, this_ptr=0x2ab0a8f0,
return_value_used=)
at /home/visco/php-5.4.7/ext/pdo/pdo_dbh.c:380
#7 0x2e23df42 in xdebug_execute_internal
(current_execute_data=0x2aad5060, return_value_used=0)
at /tmp/tmpBeyREt/xdebug-2.2.1/xdebug.c:1483
#8 0x006008e7 in ?? ()
#9 0x0060680e in execute ()
#10 0x2e24061f in xdebug_execute (op_array=0x2ab0b160) at
/tmp/tmpBeyREt/xdebug-2.2.1/xdebug.c:1391
#11 0x005d1dbe in zend_execute_scripts ()
#12 0x005770d8 in php_execute_script ()
#13 0x006789cd in ?? ()
#14 0x0067934d in ?? ()
#15 0x0036b681d994 in __libc_start_main () from /lib64/libc.so.6
#16 0x004239c9 in _start ()
--
Edit this bug report at https://bugs.php.net/bug.php?id=63258&edit=1
Bug #63258 [Csd]: seg fault with PDO and dblib using DBSETOPT(H->link, DBQUOTEDIDENT, 1);
Edit report at https://bugs.php.net/bug.php?id=63258&edit=1 ID: 63258 Updated by: ssuffic...@php.net Reported by:paul dot visco at roswellpark dot org Summary:seg fault with PDO and dblib using DBSETOPT(H->link, DBQUOTEDIDENT, 1); Status: Closed Type: Bug Package:PDO related Operating System: centos 5.8 PHP Version:5.4.7 Assigned To: ssufficool Block user comment: N Private report: N New Comment: Are you compiling against FreeTDS or Sybase libs? It looks like the segfault is in the DB LIB, not PHP. FreeTDS is passing a null pointer (or something invalid) to the libc strlen() function. To further debug this issue, FreeTDS will need to be recompiled with debug symbols intact, php recompiled and the segfault back trace reproduced. This will give better insight to the code generating the error. Previous Comments: [2013-01-18 13:03:08] f dot marquis at of2m dot fr this patch seems to cause an error : #63638 Cannot connect to SQL Server 2008 with PDO dblib [2012-10-12 02:39:42] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=0c0b5a3543f37dc3dfe7fa55629f2749c0b05294 Log: Fixed bug #63258 (seg fault with PDO and dblib using DBSETOPT(H->link, DBQUOTEDIDENT, 1)) [2012-10-12 02:38:28] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=0c0b5a3543f37dc3dfe7fa55629f2749c0b05294 Log: Fixed bug #63258 (seg fault with PDO and dblib using DBSETOPT(H->link, DBQUOTEDIDENT, 1)) [2012-10-11 16:21:34] ssuffic...@php.net The patch looks legit. I'm not sure why I used 1 instead of null for the parameter value. I have not posted patches since the source was moved to git. Please merge this change for me if possible. [2012-10-11 10:23:57] larue...@php.net ssufficool, do you have time to look into this? seems you intentionally change the "NULL" to "1" in https://github.com/php/php- src/commit/36b8c4cb thanks 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 https://bugs.php.net/bug.php?id=63258 -- Edit this bug report at https://bugs.php.net/bug.php?id=63258&edit=1
Req #46575 [Com]: NULL comparison when using "not in" not consistent with Windows SQL
Edit report at https://bugs.php.net/bug.php?id=46575&edit=1
ID: 46575
Comment by: ssufficool at gmail dot com
Reported by:ben at thelocust dot org
Summary:NULL comparison when using "not in" not consistent
with Windows SQL
Status: Open
Type: Feature/Change Request
Package:MSSQL related
Operating System: *
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
This is a behavior set by the MSSQL "ANSI NULLS" setting. Depending if ANSI
NULLS is on or off, it will return the NULL for the NOT IN selection.
This is a server setting, not a PHP setting.
Try issuing a "SET ANSI_NULLS ON" before the query using both VBScript and PHP.
The behavior should then be the same.
Previous Comments:
[2009-01-07 18:17:08] ka...@php.net
I don't see the error here, your asking SQL server to return 'test_id' from the
table 'test' where 'test_number' doesn't even to 1 or 2, and since NULL is
different from 1 and 2 then why shouldn't it be returned? I see that more of a
bug in the ASP/VBScript drivers, and I don't think we should put such an
inconsistency into because others do it.
I changed the category of this to a Feature/Change request, letting the
extension maintainer decided whenever to do it or not :)
[2008-11-14 16:35:50] ben at thelocust dot org
Description:
When querying a MSSQL database table, and using the "not in" syntax, PHP's
mssql_query will also return rows with NULL in the field specified.
Reproduce code:
---
SQL Server 2000 or 2005
Table "test"
test_id (int) test_name (vchar)test_number (int)
1 Foo 1
2 Bar 2
3 3
4 Baz
$sql = "select test_id from test where test_number not in (1,2)";
$res = mssql_query($sql);
while ($row = mssql_fetch_array($res)) {
?>
https://bugs.php.net/bug.php?id=46575&edit=1
Bug #55826 [Com]: Multiple PDORow's
Edit report at https://bugs.php.net/bug.php?id=55826&edit=1 ID: 55826 Comment by: ssufficool at gmail dot com Reported by:grinyad at mail dot ru Summary:Multiple PDORow's Status: Analyzed Type: Bug Package:PDO related Operating System: Windows XP PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Another issue with "fixing" this is that many databases (SQLServer) do not support multiple active statements per a database handle/connection. It will throw an error stating there is another active resultset. So, 2 statements requires 2 connections. Previous Comments: [2011-09-30 23:07:50] johan...@php.net The issue here is that PDORow contains a pointer to the actual statement instance which is used to receive the data and is then shared over the PDOStatement instance and all PDORows created from there. Changing this is a large change wa can't do for 5.4, which is in beta. Given other issues in there (see recent bug about serialization) I tend to removing it in 5.5, but am not sure if it might bring notable benefits with some database drivers ... [2011-09-30 22:52:32] grinyad at mail dot ru Description: You cant use multiple PDORow's at the same time. Test script: --- fetch(PDO::FETCH_LAZY); print_r($row); $row2 = $stmt->fetch(PDO::FETCH_LAZY); print_r($row); print_r($row2); ?> `$row` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 2 [Title] => Banned ) `$row` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 3 [Title] => Member ) `$row2` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 3 [Title] => Member ) `$row` and `$row2` are the same as last fetch result `$row2`.I mean that every PDORow Object will have the last fetch values. I think this is a bug. -- Edit this bug report at https://bugs.php.net/bug.php?id=55826&edit=1
#47588 [Opn]: PDO_DBLIB: barfs on quoted field names
ID: 47588
User updated by: ssufficool at roadrunner dot com
Reported By: ssufficool at roadrunner dot com
Status: Open
Bug Type: PDO related
Operating System: Linux Gentoo 2.6.x
PHP Version: 5.2.9
New Comment:
Solution:
tsql from freetds package set the following where PDO does not:
set quoted_identifier on
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
Since this is default behavior of FreeTDS (tsql) and NT DBLIB (isql), I
assume it should be for PDO dblib as well.
Previous Comments:
[2009-03-06 16:13:33] ssufficool at roadrunner dot com
Description:
When passing a query containing double quoted field names, the query
fails.
Reproduce code:
---
$pdo_ms = new PDO('dblib:host=db01;dbname=database',
$_SESSION['user'], $_SESSION['pass'], array(PDO::ATTR_ERRMODE =>
PDO::ERRMODE_EXCEPTION ) );
$rs = $pdo_ms->prepare('SELECT "myView"."FieldName" from "myView" order
by "Some Field"')
Expected result:
A valid handle to a stmt in $rs
Actual result:
--
SQLSTATE[HY000]: General error: 20018 Incorrect syntax near
'FieldName'. [20018] (severity 5) [(null)]
--
Edit this bug report at http://bugs.php.net/?id=47588&edit=1
#47588 [NEW]: DBLIB barfs on quoted field names
From: ssufficool at roadrunner dot com
Operating system: Linux Gentoo 2.6.x
PHP version: 5.2.9
PHP Bug Type: PDO related
Bug description: DBLIB barfs on quoted field names
Description:
When passing a query containing double quoted field names, the query
fails.
Reproduce code:
---
$pdo_ms = new PDO('dblib:host=db01;dbname=database',
$_SESSION['user'], $_SESSION['pass'], array(PDO::ATTR_ERRMODE =>
PDO::ERRMODE_EXCEPTION ) );
$rs = $pdo_ms->prepare('SELECT "myView"."FieldName" from "myView" order by
"Some Field"')
Expected result:
A valid handle to a stmt in $rs
Actual result:
--
SQLSTATE[HY000]: General error: 20018 Incorrect syntax near 'FieldName'.
[20018] (severity 5) [(null)]
--
Edit bug report at http://bugs.php.net/?id=47588&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47588&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47588&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47588&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47588&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47588&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47588&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47588&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47588&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47588&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47588&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47588&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47588&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47588&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47588&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47588&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47588&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47588&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47588&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47588&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47588&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47588&r=mysqlcfg
#47589 [NEW]: PDO DBLIB Fails with OOM on large recordsets
From: ssufficool at roadrunner dot com
Operating system: Linux (Gentoo)
PHP version: 5.2.9
PHP Bug Type: PDO related
Bug description: PDO DBLIB Fails with OOM on large recordsets
Description:
When pulling large recordsets with PDO DBLIB I get out of memory.
This type of large recordset query works fine on mssql_* functions using
the freetds library. This issue has been marked "Bogus" in the past. But
since this works with other functions using FreeTDS, this issue may lie in
the PDO layer.
Correct me if my understanding of Bogus is Bogus.
Reproduce code:
---
$pdo_ms = new PDO('dblib: host=host', 'user','pass');
/* We die here */
$rs = $pdo_ms->query("SELECT TOP 5 from aVeryLargeTable");
Expected result:
A valid handle to a resultset in $rs
Actual result:
--
Available memory exhausted, tried to allocate
--
Edit bug report at http://bugs.php.net/?id=47589&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47589&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47589&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47589&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47589&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47589&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47589&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47589&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47589&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47589&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47589&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47589&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47589&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47589&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47589&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47589&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47589&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47589&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47589&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47589&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47589&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47589&r=mysqlcfg
#47589 [Opn->Bgs]: PDO DBLIB Fails with OOM on large recordsets
ID: 47589
User updated by: ssufficool at roadrunner dot com
Reported By: ssufficool at roadrunner dot com
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Linux (Gentoo)
PHP Version: 5.2.9
New Comment:
My understanding of Bogus is indeed Bogus. After setting batchsize to 0
in php.ini, mssql_query also barfs on large recordssets.
Apologies for the noise.
Previous Comments:
[2009-03-06 16:36:43] ssufficool at roadrunner dot com
Description:
When pulling large recordsets with PDO DBLIB I get out of memory.
This type of large recordset query works fine on mssql_* functions
using the freetds library. This issue has been marked "Bogus" in the
past. But since this works with other functions using FreeTDS, this
issue may lie in the PDO layer.
Correct me if my understanding of Bogus is Bogus.
Reproduce code:
---
$pdo_ms = new PDO('dblib: host=host', 'user','pass');
/* We die here */
$rs = $pdo_ms->query("SELECT TOP 5 from aVeryLargeTable");
Expected result:
A valid handle to a resultset in $rs
Actual result:
--
Available memory exhausted, tried to allocate
--
Edit this bug report at http://bugs.php.net/?id=47589&edit=1
[PHP-BUG] Bug #52134 [NEW]: pdo_dblib returns 40 char strings for int
From:
Operating system: Linux
PHP version: trunk-SVN-2010-06-21 (SVN)
Package: PDO related
Bug Type: Bug
Bug description:pdo_dblib returns 40 char strings for int
Description:
pdo_dblib is not returning the correct string length after converting the
data.
Test script:
---
$row = $stmt->fetch(PDO::FETCH_ASSOC);
var_dump($row);
Expected result:
array(2) {
["id"]=>
string(2) "13"
["flag"]=>
string(1) "0"
}
Actual result:
--
array(2) {
["id"]=>
string(40) "13 "
["flag"]=>
string(40) "0 "
}
--
Edit bug report at http://bugs.php.net/bug.php?id=52134&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52134&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52134&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52134&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52134&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52134&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52134&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52134&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52134&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52134&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52134&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52134&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52134&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52134&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52134&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52134&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52134&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52134&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52134&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52134&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52134&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52134&r=mysqlcfg
Bug #48877 [Com]: "bindValue" and "bindParam" do not work for PDO Firebird
Edit report at http://bugs.php.net/bug.php?id=48877&edit=1
ID: 48877
Comment by: ssufficool at gmail dot com
Reported by: siegmar at siegmar dot com dot br
Summary: "bindValue" and "bindParam" do not work for PDO
Firebird
Status: Open
Type: Bug
Package: PDO related
Operating System: Windows
PHP Version: 5.2.10
New Comment:
Try changing the :empno to just empno in bind* it is not expected or
needed:
$command = $connection->prepare('SELECT EMP_NO FROM EMPLOYEE WHERE
EMP_NO = :empno');
$command->bindParam('empno', $value, PDO::PARAM_STR); // does not work
$command->bindValue('empno', $value, PDO::PARAM_STR); // does not work
Previous Comments:
[2009-07-10 02:35:29] siegmar at siegmar dot com dot br
Description:
The "bindValue" and "bindParam" do not work for PDO Firebird if we use
named parameters (:parameter) but do work for question marks parameters
(?).
Reproduce code:
---
prepare('SELECT EMP_NO FROM EMPLOYEE WHERE
EMP_NO = :empno');
//$command->bindParam(':empno', $value, PDO::PARAM_STR); // does not
work
//$command->bindValue(':empno', $value, PDO::PARAM_STR); // does not
work
$command = $connection->prepare('SELECT EMP_NO FROM EMPLOYEE WHERE
EMP_NO = ?');
$command->bindParam('1', $value, PDO::PARAM_STR); // works
//$command->bindValue('1', $value, PDO::PARAM_STR); // works
$command->execute();
$dataset = $command->fetchAll();
foreach($dataset as $record)
echo $record[0] . "";
?>
The same code works perfectly for MySQL.
Expected result:
Using the example database "EMPLOYEE.FDB" you sould see:
2
Actual result:
--
nothing
--
Edit this bug report at http://bugs.php.net/bug.php?id=48877&edit=1
Bug #45951 [Com]: PDO_MSSQL problem if query return no result
Edit report at http://bugs.php.net/bug.php?id=45951&edit=1
ID: 45951
Comment by: ssufficool at gmail dot com
Reported by: grzegorz at heex dot pl
Summary: PDO_MSSQL problem if query return no result
Status: Closed
Type: Bug
Package: PDO related
Operating System: Windows XP Sp3
PHP Version: 5.2.6
Assigned To: ssufficool
New Comment:
Please try latest code in trunk. I cannot reproduce with the latest
code.
Previous Comments:
[2010-07-12 05:31:34] ssuffic...@php.net
Please try version in SVN trunk. This bug cannot be reproduced with the
code in trunk,
[2010-07-12 05:30:13] ssuffic...@php.net
Tried to reproduce with code in trunk, returns expected results.
$db->query("create table test (id int not null primary key)");
$db->query("insert into test(id) values(2)");
$sth = $db->prepare("SELECT id FROM test WHERE id=:parentId");
$sth->execute(array(':parentId'=>1));
$res1 = $sth->fetchAll();
var_dump($res1);
$sth->execute(array(':parentId'=>2));
$res2 = $sth->fetchAll();
var_dump($res2);
array(0) {
}
array(1) {
[0]=>
array(2) {
["id"]=>
string(1) "2"
[0]=>
string(1) "2"
}
}
[2009-06-11 07:56:54] grzegorz at heex dot pl
I couldn't connect to MSSQL so I've exchanged ntwdblib.dll (v.7.00.839)
to (v.8.00.194).
No result is:
$res1 = array[0] //empty
$res2 = array[
0 = array['[]' => null, 0 => null]
1 = array['[]' => null, 0 => null]
]
( [] = ASCII 0x11 )
and should be:
$res2 = array[
0 = array['value' => 3, 0 => 3]
1 = array['value' => 6, 0 => 6]
]
[2009-05-03 01:00:17] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-04-25 15:11:00] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
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/bug.php?id=45951
--
Edit this bug report at http://bugs.php.net/bug.php?id=45951&edit=1
#47589 [Bgs]: PDO DBLIB Fails with OOM on large recordsets
ID: 47589
User updated by: ssufficool at roadrunner dot com
Reported By: ssufficool at roadrunner dot com
Status: Bogus
Bug Type: PDO related
Operating System: Linux (Gentoo)
PHP Version: 5.2.9
New Comment:
Please re-open this bug. I understand that the behaviour is shared
across the PDO::DBLIB and MSSQL_* functions, however other PDO drivers
do not have this issue (I.E. PDO:POSTGRESQL) and the same query issued
on the command line via freetds (tsql) does not consume memory like
this.
I am using a CURSOR_FWDONLY and this should not require buffering all
the rows on the client.
Previous Comments:
[2009-03-06 17:04:47] ssufficool at roadrunner dot com
My understanding of Bogus is indeed Bogus. After setting batchsize to 0
in php.ini, mssql_query also barfs on large recordssets.
Apologies for the noise.
[2009-03-06 16:36:43] ssufficool at roadrunner dot com
Description:
When pulling large recordsets with PDO DBLIB I get out of memory.
This type of large recordset query works fine on mssql_* functions
using the freetds library. This issue has been marked "Bogus" in the
past. But since this works with other functions using FreeTDS, this
issue may lie in the PDO layer.
Correct me if my understanding of Bogus is Bogus.
Reproduce code:
---
$pdo_ms = new PDO('dblib: host=host', 'user','pass');
/* We die here */
$rs = $pdo_ms->query("SELECT TOP 5 from aVeryLargeTable");
Expected result:
A valid handle to a resultset in $rs
Actual result:
--
Available memory exhausted, tried to allocate
--
Edit this bug report at http://bugs.php.net/?id=47589&edit=1
#47589 [Bgs]: PDO DBLIB Fails with OOM on large recordsets
ID: 47589
User updated by: ssufficool at gmail dot com
-Reported By: ssufficool at roadrunner dot com
+Reported By: ssufficool at gmail dot com
Status: Bogus
Bug Type: PDO related
Operating System: Linux (Gentoo)
PHP Version: 5.2.9
New Comment:
new e-mail
Previous Comments:
[2010-01-14 18:20:33] ssufficool at roadrunner dot com
Please re-open this bug. I understand that the behaviour is shared
across the PDO::DBLIB and MSSQL_* functions, however other PDO drivers
do not have this issue (I.E. PDO:POSTGRESQL) and the same query issued
on the command line via freetds (tsql) does not consume memory like
this.
I am using a CURSOR_FWDONLY and this should not require buffering all
the rows on the client.
[2009-03-06 17:04:47] ssufficool at roadrunner dot com
My understanding of Bogus is indeed Bogus. After setting batchsize to 0
in php.ini, mssql_query also barfs on large recordssets.
Apologies for the noise.
[2009-03-06 16:36:43] ssufficool at gmail dot com
Description:
When pulling large recordsets with PDO DBLIB I get out of memory.
This type of large recordset query works fine on mssql_* functions
using the freetds library. This issue has been marked "Bogus" in the
past. But since this works with other functions using FreeTDS, this
issue may lie in the PDO layer.
Correct me if my understanding of Bogus is Bogus.
Reproduce code:
---
$pdo_ms = new PDO('dblib: host=host', 'user','pass');
/* We die here */
$rs = $pdo_ms->query("SELECT TOP 5 from aVeryLargeTable");
Expected result:
A valid handle to a resultset in $rs
Actual result:
--
Available memory exhausted, tried to allocate
--
Edit this bug report at http://bugs.php.net/?id=47589&edit=1
#50755 [NEW]: PDO DBLIB Fails with OOM
From: ssufficool at gmail dot com
Operating system: Linux 2.6.30-gentoo-r2
PHP version: 5.3.1
PHP Bug Type: PDO related
Bug description: PDO DBLIB Fails with OOM
Description:
When querying large tables (> 800,000 rows) with PDO DBLIB I get out of
memory.
The same select query works fine using:
linux# tsql -H host -U user -P pass
SELECT * from aVeryLargeTable
go
quit
on the command line using the freetds (dblib) library without consuming
client-side memory.
Reproduce code:
---
$pdo = new PDO('dblib:host=host','user','pass');
echo "Creating table...\n";
$pdo->query("CREATE TABLE large_table (field_1 nvarchar(4000))");
$pdo->query("DECLARE @n int;
set @n = 0;
WHILE (@n < 5) BEGIN
insert into large_table values( replicate(4000,'-') );
set @n = @n + 1;
END");
echo "Prepare\n";
$rs = $pdo->prepare("SELECT * FROM large_table");
echo "Execute\n";
/*OOM HERE**/
$rs->execute( );
Expected result:
A valid handle to a resultset in $rs
Actual result:
------
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 48 bytes) in /home/ssufficool/tds_test.php on line 12
It looks like the guts of
ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_execute()
at "/* let's fetch all the data */"
Should be moved to:
pdo_dblib_stmt_fetch()
and only when a scrollable cursor is requested should the data be buffered
at the client (not required for ct-lib)
--
Edit bug report at http://bugs.php.net/?id=50755&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50755&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50755&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50755&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50755&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50755&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50755&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50755&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50755&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50755&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50755&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50755&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50755&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50755&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50755&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50755&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50755&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50755&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50755&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50755&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50755&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50755&r=mysqlcfg
#50755 [Opn]: PDO DBLIB Fails with OOM
ID: 50755
User updated by: ssufficool at gmail dot com
Reported By: ssufficool at gmail dot com
Status: Open
Bug Type: PDO related
Operating System: Linux 2.6.30-gentoo-r2
PHP Version: 5.3.1
New Comment:
I have a patch that removes client side buffering and allows for large
rowset queries without memory consumption. Compiled and tested
http://svn.php.net/repository/php/php-src/branches/PHP_5_2
SVN Revision: 293557
I can send patch via e-mail.
Previous Comments:
[2010-01-14 19:09:48] ssufficool at gmail dot com
Description:
When querying large tables (> 800,000 rows) with PDO DBLIB I get out of
memory.
The same select query works fine using:
linux# tsql -H host -U user -P pass
SELECT * from aVeryLargeTable
go
quit
on the command line using the freetds (dblib) library without consuming
client-side memory.
Reproduce code:
---
$pdo = new PDO('dblib:host=host','user','pass');
echo "Creating table...\n";
$pdo->query("CREATE TABLE large_table (field_1 nvarchar(4000))");
$pdo->query("DECLARE @n int;
set @n = 0;
WHILE (@n < 5) BEGIN
insert into large_table values( replicate(4000,'-') );
set @n = @n + 1;
END");
echo "Prepare\n";
$rs = $pdo->prepare("SELECT * FROM large_table");
echo "Execute\n";
/*OOM HERE**/
$rs->execute( );
Expected result:
A valid handle to a resultset in $rs
Actual result:
------
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 48 bytes) in /home/ssufficool/tds_test.php on line 12
It looks like the guts of
ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_execute()
at "/* let's fetch all the data */"
Should be moved to:
pdo_dblib_stmt_fetch()
and only when a scrollable cursor is requested should the data be
buffered at the client (not required for ct-lib)
--
Edit this bug report at http://bugs.php.net/?id=50755&edit=1
#50755 [Opn]: PDO DBLIB Fails with OOM
ID: 50755
User updated by: ssufficool at gmail dot com
Reported By: ssufficool at gmail dot com
Status: Open
Bug Type: PDO related
Operating System: Linux 2.6.30-gentoo-r2
PHP Version: 5.3.1
New Comment:
Patch sent to w...@php.net waiting response
Previous Comments:
[2010-01-15 00:21:48] ssufficool at gmail dot com
I have a patch that removes client side buffering and allows for large
rowset queries without memory consumption. Compiled and tested
http://svn.php.net/repository/php/php-src/branches/PHP_5_2
SVN Revision: 293557
I can send patch via e-mail.
[2010-01-14 19:09:48] ssufficool at gmail dot com
Description:
When querying large tables (> 800,000 rows) with PDO DBLIB I get out of
memory.
The same select query works fine using:
linux# tsql -H host -U user -P pass
SELECT * from aVeryLargeTable
go
quit
on the command line using the freetds (dblib) library without consuming
client-side memory.
Reproduce code:
---
$pdo = new PDO('dblib:host=host','user','pass');
echo "Creating table...\n";
$pdo->query("CREATE TABLE large_table (field_1 nvarchar(4000))");
$pdo->query("DECLARE @n int;
set @n = 0;
WHILE (@n < 5) BEGIN
insert into large_table values( replicate(4000,'-') );
set @n = @n + 1;
END");
echo "Prepare\n";
$rs = $pdo->prepare("SELECT * FROM large_table");
echo "Execute\n";
/*OOM HERE**/
$rs->execute( );
Expected result:
A valid handle to a resultset in $rs
Actual result:
------
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 48 bytes) in /home/ssufficool/tds_test.php on line 12
It looks like the guts of
ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_execute()
at "/* let's fetch all the data */"
Should be moved to:
pdo_dblib_stmt_fetch()
and only when a scrollable cursor is requested should the data be
buffered at the client (not required for ct-lib)
--
Edit this bug report at http://bugs.php.net/?id=50755&edit=1
#38805 [Com]: PDO Truncates Text from SQL Server Text Data Type Field
ID: 38805
Comment by: ssufficool at gmail dot com
Reported By: gkrajci at arescorporation dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows NT PBMA-WB2 5.2 build 37
PHP Version: 5.1.6
Assigned To: sfox
New Comment:
I imagine the problem is that PDO DBLIB just mem-copies the first
packet of TEXT without calling dbgettext() to retrieve the remainder.
MSSQL handles TEXT fields using dbconvert() which may call dbgettext()
downstream.
Possible fix: remove "case SQLTEXT" from
ext/pdo_dblib/dblib_stmt.c:execute and let it fall though to default.
Previous Comments:
[2010-01-10 23:22:50] ka...@php.net
Steph, does this need any additional changes to pdo_mssql/pdo_dblib?
And what exactly should be documented?
[2009-09-02 15:28:50] aballard at gmail dot com
According to the SQL Server documenation, SET TEXTSIZE { number } by
itself is not sufficient. That's why the original mssql library has two
configuration directives: mssql.textlimit and mssql.textsize
Since PDO is configured not to use configuration directives, it would
be nice if the pdo_mssql driver added two driver_options to configure
these values.
A quote from SQL Server Books Online:
Setting SET TEXTSIZE affects the @@TEXTSIZE function.
The DB-Library variable DBTEXTLIMIT also limits the size of text data
returned with a SELECT statement. If DBTEXTLIMIT is set to a smaller
size than TEXTSIZE, only the amount specified by DBTEXTLIMIT is
returned. For more information, see "Programming DB-Library for C" in
SQL Server Books Online.
The SQL Server ODBC driver and Microsoft OLE DB Provider for SQL Server
automatically set TEXTSIZE to 2147483647 when connecting.
The setting of set TEXTSIZE is set at execute or run time and not at
parse time.
[2009-07-27 10:52:45] danhen at web dot de
When using PDO_MSSQL with PHP 5.3 (Not PDO_ODBC - queries aren't
compatible in many cases - especially those with placeholders)
pdo::query(SET TEXTSIZE 2147483647) works fine with MSSQL 2008. PDO_ODBC
isn't a good replacement.
[2009-03-20 22:17:01] s...@php.net
Should all work as advertised from 5.2.10 up.
Now to go change the advertising ;)
- Steph
[2009-02-15 22:30:36] janpolsen at gmail dot com
Thanks for the fast response.
I will try to see how my scripts run when using the ODBC driver instead
:).
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/38805
--
Edit this bug report at http://bugs.php.net/?id=38805&edit=1
Bug #50755 [Opn]: PDO DBLIB Fails with OOM
Edit report at http://bugs.php.net/bug.php?id=50755&edit=1
ID: 50755
User updated by: ssufficool at gmail dot com
Reported by: ssufficool at gmail dot com
Summary: PDO DBLIB Fails with OOM
Status: Open
Type: Bug
Package: PDO related
Operating System: Linux 2.6.30-gentoo-r2
-PHP Version: 5.3.1
+PHP Version: 5.2 / 5.3 / 6
New Comment:
Affects all versions of PHP, patches attached.
Previous Comments:
[2010-01-20 20:50:56] ssufficool at gmail dot com
Patch sent to w...@php.net waiting response
[2010-01-15 00:21:48] ssufficool at gmail dot com
I have a patch that removes client side buffering and allows for large
rowset queries without memory consumption. Compiled and tested
http://svn.php.net/repository/php/php-src/branches/PHP_5_2
SVN Revision: 293557
I can send patch via e-mail.
[2010-01-14 19:09:48] ssufficool at gmail dot com
Description:
When querying large tables (> 800,000 rows) with PDO DBLIB I get out of
memory.
The same select query works fine using:
linux# tsql -H host -U user -P pass
SELECT * from aVeryLargeTable
go
quit
on the command line using the freetds (dblib) library without consuming
client-side memory.
Reproduce code:
---
$pdo = new PDO('dblib:host=host','user','pass');
echo "Creating table...\n";
$pdo->query("CREATE TABLE large_table (field_1 nvarchar(4000))");
$pdo->query("DECLARE @n int;
set @n = 0;
WHILE (@n < 5) BEGIN
insert into large_table values( replicate(4000,'-') );
set @n = @n + 1;
END");
echo "Prepare\n";
$rs = $pdo->prepare("SELECT * FROM large_table");
echo "Execute\n";
/*OOM HERE**/
$rs->execute( );
Expected result:
A valid handle to a resultset in $rs
Actual result:
------
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 48 bytes) in /home/ssufficool/tds_test.php on line 12
It looks like the guts of
ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_execute()
at "/* let's fetch all the data */"
Should be moved to:
pdo_dblib_stmt_fetch()
and only when a scrollable cursor is requested should the data be
buffered at the client (not required for ct-lib)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50755&edit=1
Bug #50755 [Opn]: PDO DBLIB Fails with OOM
Edit report at http://bugs.php.net/bug.php?id=50755&edit=1
ID: 50755
User updated by: ssufficool at gmail dot com
Reported by: ssufficool at gmail dot com
Summary: PDO DBLIB Fails with OOM
Status: Open
Type: Bug
Package: PDO related
Operating System: Linux 2.6.30-gentoo-r2
PHP Version: 5.2 / 5.3 / 6
New Comment:
Patch revised:
1. Reverted driver always registering as dblib.
Question: Should the user really have to know the library the extension
was compiled against? Seems like we should settle on a constant
registration since you really can't mix and match.
2. Reverted whitespace modifications. Removed spurrious comments.
Reverted DBSETOPT --> dbsetopt.
3. Reverted SYB* --> SQL* define deletions. These are required for
compile against the depreciated MS DBLIB.
4. Removed automagic compute column naming (which was clobbering library
memory). Just return what the server returns including empty strings.
The user will need to alias in their sql query as "select 1+1 as
oneplusone" instead of just "select 1+1" magically returning
array('compute1'=>'2').
Question: Who if anyone relies on this behavior? I don't see other
drivers doing this.
Some unrelated/unmentioned "fixes"
Allow multiple rowsets with varying column definitions. This was
implemented incorrectly.
Include the recent update to SQLMONEY formatting.
Tested against SQL Server 2008 Express, PHP-5.3 svn-296442, FreeTDS
0.64, Linux 2.6.30 - i686.
Previous Comments:
----
[2010-03-09 23:48:39] ssufficool at gmail dot com
Affects all versions of PHP, patches attached.
----
[2010-01-20 20:50:56] ssufficool at gmail dot com
Patch sent to w...@php.net waiting response
----
[2010-01-15 00:21:48] ssufficool at gmail dot com
I have a patch that removes client side buffering and allows for large
rowset queries without memory consumption. Compiled and tested
http://svn.php.net/repository/php/php-src/branches/PHP_5_2
SVN Revision: 293557
I can send patch via e-mail.
----
[2010-01-14 19:09:48] ssufficool at gmail dot com
Description:
When querying large tables (> 800,000 rows) with PDO DBLIB I get out of
memory.
The same select query works fine using:
linux# tsql -H host -U user -P pass
SELECT * from aVeryLargeTable
go
quit
on the command line using the freetds (dblib) library without consuming
client-side memory.
Reproduce code:
---
$pdo = new PDO('dblib:host=host','user','pass');
echo "Creating table...\n";
$pdo->query("CREATE TABLE large_table (field_1 nvarchar(4000))");
$pdo->query("DECLARE @n int;
set @n = 0;
WHILE (@n < 5) BEGIN
insert into large_table values( replicate(4000,'-') );
set @n = @n + 1;
END");
echo "Prepare\n";
$rs = $pdo->prepare("SELECT * FROM large_table");
echo "Execute\n";
/*OOM HERE**/
$rs->execute( );
Expected result:
----
A valid handle to a resultset in $rs
Actual result:
--
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 48 bytes) in /home/ssufficool/tds_test.php on line 12
It looks like the guts of
ext/pdo_dblib/dblib_stmt.c:pdo_dblib_stmt_execute()
at "/* let's fetch all the data */"
Should be moved to:
pdo_dblib_stmt_fetch()
and only when a scrollable cursor is requested should the data be
buffered at the client (not required for ct-lib)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50755&edit=1
Bug #47588 [Opn]: PDO_DBLIB: barfs on quoted field names
Edit report at http://bugs.php.net/bug.php?id=47588&edit=1
ID: 47588
User updated by: ssufficool at roadrunner dot com
Reported by: ssufficool at roadrunner dot com
Summary: PDO_DBLIB: barfs on quoted field names
Status: Open
Type: Bug
Package: PDO related
Operating System: Linux Gentoo 2.6.x
-PHP Version: 5.2.9
+PHP Version: 5.3-svn
New Comment:
Set quoted identifiers to allow "FIELD NAME" quoting style.
Index: ext/pdo_dblib/dblib_driver.c
===
--- ext/pdo_dblib/dblib_driver.c(revision 296453)
+++ ext/pdo_dblib/dblib_driver.c(working copy)
@@ -236,6 +236,9 @@
/* limit text/image from network */
DBSETOPT(H->link, DBTEXTSIZE, "2147483647");
+ /* Allow double quoted field and table names */
+ DBSETOPT(H->link, DBQUOTEDIDENT, NULL);
+
if (vars[3].optval && FAIL == dbuse(H->link, vars[3].optval)) {
goto cleanup;
}
Previous Comments:
----
[2009-05-15 19:43:17] ssufficool at roadrunner dot com
Solution:
tsql from freetds package set the following where PDO does not:
set quoted_identifier on
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
Since this is default behavior of FreeTDS (tsql) and NT DBLIB (isql), I
assume it should be for PDO dblib as well.
----
[2009-03-06 16:13:33] ssufficool at roadrunner dot com
Description:
When passing a query containing double quoted field names, the query
fails.
Reproduce code:
---
$pdo_ms = new PDO('dblib:host=db01;dbname=database',
$_SESSION['user'], $_SESSION['pass'], array(PDO::ATTR_ERRMODE =>
PDO::ERRMODE_EXCEPTION ) );
$rs = $pdo_ms->prepare('SELECT "myView"."FieldName" from "myView" order
by "Some Field"')
Expected result:
A valid handle to a stmt in $rs
Actual result:
--
SQLSTATE[HY000]: General error: 20018 Incorrect syntax near 'FieldName'.
[20018] (severity 5) [(null)]
--
Edit this bug report at http://bugs.php.net/bug.php?id=47588&edit=1
Bug #51274 [Com]: Integer overflow does not cast as float
Edit report at http://bugs.php.net/bug.php?id=51274&edit=1 ID: 51274 Comment by: ssufficool at gmail dot com Reported by: cduncan at regatta dot com Summary: Integer overflow does not cast as float Status: Open Type: Bug Package: *General Issues Operating System: Linux PHP Version: 5.3.2 New Comment: 64 bit ubuntu 10.04 PHP 5.3 SVN: int(2147483647) int(2147483648) 32 bit machine and OS PHP 5.2.10: int(2147483647) float(2147483648) Previous Comments: [2010-03-11 19:05:31] cduncan at regatta dot com 64bit machine, 32bit OS. Also, wouldn't we expect a 64bit to return: int(2147483647) int(2147483648) [2010-03-11 17:58:30] j...@php.net Could it possibly be that you're running this on 64bit machine? :) [2010-03-11 15:15:38] cduncan at regatta dot com Description: The manual (http://php.net/manual/pl/language.types.integer.php) includes the following segment to cover integer overflow: However when I try this on my recently upgraded server they are both output as int(2147483647) Test script: --- $large_number = 2147483647; var_dump($large_number); $large_number = 2147483648; var_dump($large_number); Expected result: I expect to see; int(2147483647) float(2147483648) As I do on my box running 5.3.1 Actual result: -- int(2147483647) int(2147483647) -- Edit this bug report at http://bugs.php.net/bug.php?id=51274&edit=1
Bug #50755 [Opn]: PDO DBLIB Fails with OOM
Edit report at http://bugs.php.net/bug.php?id=50755&edit=1
ID: 50755
User updated by: ssufficool at gmail dot com
Reported by: ssufficool at gmail dot com
Summary: PDO DBLIB Fails with OOM
Status: Open
Type: Bug
Package: PDO related
Operating System: Linux 2.6.30-gentoo-r2
PHP Version: 5.2 / 5.3 / 6
New Comment:
This has also been tested with latest and greatest FreeTDS 0,82 on
Ubuntu x86 & amd64. Same results, out of memory. The memory allocation
is on the PDO side, not libtds.
Previous Comments:
[2010-03-28 22:10:09] eric at pineconehill dot com
we use freetds on debian with sql server 2005, so i'm following this
patch with
some interest. just curious, why freetds 0.64? 0.82 is the latest stable
and fixes
quite a few issues. it's been out for almost 2 years now (whereas 0.63
is 5 years
old in a couple of weeks).
[2010-03-20 00:32:04] ssufficool at gmail dot com
Patch revised:
1. Reverted driver always registering as dblib.
Question: Should the user really have to know the library the extension
was compiled against? Seems like we should settle on a constant
registration since you really can't mix and match.
2. Reverted whitespace modifications. Removed spurrious comments.
Reverted DBSETOPT --> dbsetopt.
3. Reverted SYB* --> SQL* define deletions. These are required for
compile against the depreciated MS DBLIB.
4. Removed automagic compute column naming (which was clobbering library
memory). Just return what the server returns including empty strings.
The user will need to alias in their sql query as "select 1+1 as
oneplusone" instead of just "select 1+1" magically returning
array('compute1'=>'2').
Question: Who if anyone relies on this behavior? I don't see other
drivers doing this.
Some unrelated/unmentioned "fixes"
Allow multiple rowsets with varying column definitions. This was
implemented incorrectly.
Include the recent update to SQLMONEY formatting.
Tested against SQL Server 2008 Express, PHP-5.3 svn-296442, FreeTDS
0.64, Linux 2.6.30 - i686.
----
[2010-03-09 23:48:39] ssufficool at gmail dot com
Affects all versions of PHP, patches attached.
----
[2010-01-20 20:50:56] ssufficool at gmail dot com
Patch sent to w...@php.net waiting response
----
[2010-01-15 00:21:48] ssufficool at gmail dot com
I have a patch that removes client side buffering and allows for large
rowset queries without memory consumption. Compiled and tested
http://svn.php.net/repository/php/php-src/branches/PHP_5_2
SVN Revision: 293557
I can send patch via e-mail.
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/bug.php?id=50755
--
Edit this bug report at http://bugs.php.net/bug.php?id=50755&edit=1
Bug #52885 [Com]: PDO_DBLIB does not properly quote char(0)
Edit report at http://bugs.php.net/bug.php?id=52885&edit=1
ID: 52885
Comment by: ssufficool at gmail dot com
Reported by:ssuffic...@php.net
Summary:PDO_DBLIB does not properly quote char(0)
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3SVN-2010-09-19 (SVN)
Block user comment: N
New Comment:
There is a larger issue here to do with unicode code page conversions
and the such.
What really needs to be done is to implement the native dblib parameter
bindings to stop the encoding of all parameters as strings which are
then interpreted by iconv to the server charset which may not suport the
full range of characters from 0-255.
Previous Comments:
[2010-09-19 02:34:18] ssuffic...@php.net
Description:
When using bound parameter with char(0), the parameter is truncated.
This is a possible SQL injection flaw in the dblib quote implementation.
Test script:
---
$stmt = $pdo->prepare("insert into test(image_field) values(?)");
$blob = file_get_contents("test.jpg");
$stmt->execute(array($blob));
Expected result:
No error
Actual result:
--
invalid statement due to truncation of ASCIIZ string in
dblib_handle_quoter
--
Edit this bug report at http://bugs.php.net/bug.php?id=52885&edit=1
Bug #54648 [Com]: PDO::MSSQL forces format of datetime fields
Edit report at https://bugs.php.net/bug.php?id=54648&edit=1
ID: 54648
Comment by: ssufficool at gmail dot com
Reported by:mail at tomsommer dot dk
Summary:PDO::MSSQL forces format of datetime fields
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
It seems the standard ANSI SQL date/time format should be -MM-DD HH:MM:SS.F
The PDO and MSSQL conversions drop the fraction. Unfortunately this cause major
breakage if it were "standardized" since php does not convert fractional times.
IMHO, all PDO drivers should return the date/time & interval values in
-MM-DD HH:MM:SS format.
Previous Comments:
[2011-05-02 10:06:25] mail at tomsommer dot dk
Description:
The PDO::MSSQL layer forces a format upon datetime fields, which cannot be
altered. The MSSQL extension does not.
mssql.datetimeconvert apparently has no effect on PDO.
Test script:
---
ini_set('mssql.datetimeconvert', 0);
$sql = mssql_query("SELECT GETDATE()");
var_dump(mssql_fetch_assoc($sql));
var_dump($mssql->query("SELECT GETDATE()")->fetch());
Expected result:
array
'computed' => string '2011-05-02 10:02:08' (length=19)
array
'computed' => string '2011-05-02 10:02:08' (length=19)
0 => string '2011-05-02 10:02:08' (length=19)
Actual result:
--
array
'computed' => string '2011-05-02 10:02:08' (length=19)
array
'computed' => string 'maj 02 2011 10:02:08' (length=20)
0 => string 'maj 02 2011 10:02:08' (length=20)
--
Edit this bug report at https://bugs.php.net/bug.php?id=54648&edit=1
#45876 [NEW]: DBLIB does not support getColumnMeta
From: ssufficool at rov dot sbcounty dot gov
Operating system: Gentoo Linux
PHP version: 5.2.6
PHP Bug Type: PDO related
Bug description: DBLIB does not support getColumnMeta
Description:
When using the mssql_* functions it is possible to read column meta data
using mssql_fetch_field in conjunction with the freetds library. However it
is not possible to use PDOStatement::getColumnMeta using the same library.
The library must support this functionality in some way even if limited,
the additional attributes may be set to false or NULL.
Reproduce code:
---
$conn = new PDO("dblib:host=myhost","user","pass");
$rs = $conn->query("SELECT * FROM SOMETABLE");
print_r($rs->getColumnMeta(0));
Expected result:
Array(
"key" => "value",
"key" => "value",
"key" => "value",
"key" => "value"
);
Actual result:
--
Warning: PDOStatement::getColumnMeta() [pdostatement.getcolumnmeta]:
SQLSTATE[IM001]: Driver does not support this function: driver doesn't
support meta data
--
Edit bug report at http://bugs.php.net/?id=45876&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45876&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45876&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45876&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45876&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45876&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45876&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45876&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45876&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45876&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45876&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45876&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45876&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45876&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45876&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45876&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45876&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45876&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45876&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45876&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45876&r=mysqlcfg
#42403 [NEW]: Field Attributes
From: ssufficool at rov dot sbcounty dot gov
Operating system: Linux
PHP version: 5.2.3
PHP Bug Type: Feature/Change Request
Bug description: Field Attributes
Description:
The PDO getColumnMeta does not return all of the attributes that the
mssql_* functions return using FreeTDS or DBLIB.
Reproduce code:
---
query('SELECT fruit_name FROM fruit');
$meta = $select->getColumnMeta(0);
var_dump($meta);
?>
Expected result:
the proper length, not -1 and type of the character field along with other
attributes provided by mssql_field_* functions
Actual result:
--
field length of -1 along with other invalid/unknown attributes
--
Edit bug report at http://bugs.php.net/?id=42403&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42403&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42403&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42403&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42403&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42403&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42403&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42403&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42403&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42403&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42403&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42403&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42403&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42403&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42403&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42403&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42403&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42403&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42403&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42403&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42403&r=mysqlcfg
