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
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 #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
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 #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
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
[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 #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 #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:
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 #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
#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
#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
#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 [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
#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
