Req #63105 [Com]: Default transanction isolation level in PHP for Firebird in php.ini
Edit report at https://bugs.php.net/bug.php?id=63105&edit=1 ID: 63105 Comment by: ssuffic...@php.net Reported by:mar...@php.net Summary:Default transanction isolation level in PHP for Firebird in php.ini Status: Assigned Type: Feature/Change Request Package:InterBase related Operating System: All PHP Version:Irrelevant Assigned To:mariuz Block user comment: N Private report: N New Comment: If this option could apply to multiple database drivers, I would remove the FB_ prefix and translate to the driver specific implementations transparently. An abstraction should not be specific to an implementation. The driver could throw a catchable "not supported" PDOException if transaction isolation is not suported by the driver or the requested isolation level is not supported. Previous Comments: [2013-09-25 04:59:36] slavb18 at gmail dot com examples: $pdo->setAttribute(PDO::ATTR_READONLY, FALSE); // read-write transaction (Default) $pdo->setAttribute(PDO::ATTR_READONLY, TRUE); // readonly transaction $pdo->setAttribute(PDO::ATTR_TIMEOUT, 0); // no_wait $pdo->setAttribute(PDO::ATTR_TIMEOUT, -1); // wait $pdo->setAttribute(PDO::ATTR_TIMEOUT, 4); // wait timeout 4 seconds $pdo->setAttribute(PDO::FB_TRANS_ISOLATION_LEVEL, PDO::FB_TRANS_COMMITTED); //read committed (default) ... etc FB_TRANS_COMMITTED_NO_REC_VERSION, FB_TRANS_CONCURRENCY, FB_TRANS_CONCURRENCY [2012-09-18 07:52:40] mar...@php.net Discussion on firebird php list http://tech.groups.yahoo.com/group/firebird-php/message/3758 [2012-09-18 07:18:47] mar...@php.net Description: If you start a new transaction (or if one is started internally, where you cannot change the isolation level) where you donât explicitly specify isolation level the IBASE_DEFAULT is used. But this is IBASE_WRITE|IBASE_CONCURRENCY|IBASE_WAIT. This is read-write wait transaction in concurrency mode. This mode is most restrictive, nothing close to read committed. And to make it worse, thereâs no way to change this default value in runtime. You can only do it recompiling sources, nothing to be viable in most cases. http://blog.cincura.net/233007-default-transanction-isolation-level-in-php-for- firebird/ -- Edit this bug report at https://bugs.php.net/bug.php?id=63105&edit=1
Req #48431 [Com]: Support PDO::PARAM_STMT
Edit report at https://bugs.php.net/bug.php?id=48431&edit=1
ID: 48431
Comment by: ssuffic...@php.net
Reported by:candrews at integralblue dot com
Summary:Support PDO::PARAM_STMT
Status: Open
Type: Feature/Change Request
Package:PDO related
Operating System: *
PHP Version:5.2.9
Block user comment: N
Private report: N
New Comment:
I believe the correct syntax would be:
prepare("SELECT * FROM users
JOIN :usernames as mytab
on users.name = mytab.username");
$sth2 = $dbh2->execute("select username, userid, accesslevel from permissions
where accesslevel='admin'")
$sth->bindParam(":usernames", $sth2, PDO::PARAM_STMT);
$sth->execute();
?>
PDO::PARAM_ARRAY would make more sense for an associative array argument, which
could be used in the same way.
An example prepared statement for either case would be:
SELECT * FROM users
JOIN (
SELECT 'user1' as username, 1 as userid, 'admin' as accesslevel
UNION ALL SELECT 'user5' as username, 5 as userid, 'admin' as accesslevel
) as mytab
on users.name = mytab.username
Previous Comments:
[2009-05-29 20:08:26] candrews at integralblue dot com
Description:
According to the PDO constants page at
http://us3.php.net/manual/en/pdo.constants.php , PDO::PARAM_STMT "Represents a
recordset type. Not currently supported by any drivers." It would be nice if
PDO supported this type for all drivers in that don't directly support it using
emulation, and for drivers do, using the driver implementation (just like how
all the other prepared statement parameter types work).
Reproduce code:
---
Right now, implementing a prepared statement query involving arrays is (I
believe) impossible.
prepare('SELECT *
FROM users
WHERE username in :usernames);
$sth->bindParam(":usernames", array("alice","bob","dave"), PDO::PARAM_STMT);
$sth->execute();
?>
That would be very nice to be able to do - and I believe that is the correct
syntax.
--
Edit this bug report at https://bugs.php.net/bug.php?id=48431&edit=1
Bug #64522 [PATCH]: 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
Patch added 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
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 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
Previous Comments:
[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))
[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.
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 [Com]: Include default column value in PDO::getColumnMeta
Edit report at https://bugs.php.net/bug.php?id=37223&edit=1 ID: 37223 Comment 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 Type: Feature/Change Request Package:PDO related Operating System: * PHP Version:5.1.2 Block user comment: N Private report: N New Comment: Which driver? The getColumnMeta method is specific to each driver. Previous Comments: [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
Bug #40913 [Com]: PDO::PARAM_LOB does not bind to a stream for fetching a BLOB
Edit report at https://bugs.php.net/bug.php?id=40913&edit=1 ID: 40913 Comment by: ssuffic...@php.net Reported by:dennis at inmarket dot lviv dot ua Summary:PDO::PARAM_LOB does not bind to a stream for fetching a BLOB Status: Re-Opened Type: Bug Package:PDO related Operating System: Win XP PHP Version:5.2.6 Block user comment: N Private report: N New Comment: PGSQL binds to a stream object for a LOB. Which PDO driver is this referring to? Previous Comments: [2012-11-07 12:15:02] johan...@php.net The implementation for this is broken in PDO core. For PGSQL there is a workaround documented: Since information about the columns is not always available to PDO until the statement is executed, portable applications should call this function after PDOStatement::execute(). However, to be able to bind a LOB column as a stream when using the PgSQL driver, applications should call this method before calling PDOStatement::execute(), otherwise the large object OID will be returned as an integer. http://www.php.net/manual/en/pdostatement.bindcolumn.php This works neither works with sqlite nor mysql drivers. After research I assume it won't work with other drivers either. The LOB-handling happens in the param_hook for PDO_PARAM_EVT_EXEC_PRE. But this event only happens if there are bound parameters during execute. But result columns are bound after execute ... The support for this feature has do be redesigned in PDO core ... as MySQL has no native stream support I don't support adding a hack for this. [2012-11-07 08:55:18] vicrry at yahoo dot com dot hk As of PHP 5.3.15, this bug still exists. [2012-08-04 12:40:50] david dot palella at gmail dot com The problem is still present with PHP v. 5.3.10 and Ubuntu 12.10 [2011-10-20 09:48:17] oridan82 at gmail dot com PHP 5.3.5 PARAM_LOB is returning a string instead of a stream. Code: - $stmt = $conn->prepare($qry); $stmt->bindValue(1, $_GET['id']); $stmt->bindValue(2, $_GET['aid']); $stmt->execute(); $stmt->bindColumn(4, $mimeType, PDO::PARAM_STR, 256); $stmt->bindColumn(6, $lob, PDO::PARAM_LOB); $stmt->fetch(PDO::FETCH_BOUND); echo gettype($lob); Expected Result: resource Actual Result: -- string [2011-01-04 13:21:09] u...@php.net See last comment, works with 5.3.4 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=40913 -- Edit this bug report at https://bugs.php.net/bug.php?id=40913&edit=1
[PHP-BUG] Bug #64957 [NEW]: PDO_DBLIB returns unknown for native_type
From: ssuffic...@php.net
Operating system: Any
PHP version: master-Git-2013-06-01 (Git)
Package: PDO related
Bug Type: Bug
Bug description:PDO_DBLIB returns unknown for native_type
Description:
When testing against Sybase AS 12, varchar columns are described as
unknown.
Test script:
---
#!~/src/php-src/sapi/cli/php
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $pdo->query("SELECT cast('foo' as varchar(32)) as foo");
print_r($stmt->getColumnMeta(0));
?>
Expected result:
Array
(
[max_length] => 32
[precision] => 0
[scale] => 0
[column_source] => foo
[native_type] => varchar
[name] => foo
[len] => 32
[pdo_type] => 2
)
Actual result:
--
Array
(
[max_length] => 0
[precision] => 0
[scale] => 0
[column_source] => foo
[native_type] => unknown
[name] => foo
[len] => 0
[pdo_type] => 2
)
--
Edit bug report at https://bugs.php.net/bug.php?id=64957&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64957&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64957&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64957&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64957&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64957&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64957&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64957&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64957&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64957&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64957&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64957&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64957&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64957&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64957&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64957&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64957&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64957&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64957&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64957&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64957&r=mysqlcfg
Bug #55826 [Com]: Multiple PDORow's
Edit report at https://bugs.php.net/bug.php?id=55826&edit=1 ID: 55826 Comment by: ssuffic...@php.net 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: The rows in your test script return distinct values for PDO_DBLIB in PHP5.4. Which specific PDO driver are you having problems with? Previous Comments: [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
[PHP-BUG] Req #63078 [NEW]: Need Bug Tracker PDO Driver Specific Categories
From: ssufficool Operating system: Irrelevant PHP version: Irrelevant Package: *General Issues Bug Type: Feature/Change Request Bug description:Need Bug Tracker PDO Driver Specific Categories Description: Currently all PDO issues are lumped in the bug tracker under "PDOI Related". Each PDO driver has it's own maintainer(s) and it would be helpful to narrow which driver the bug is related to. Test script: --- Try to find a bug related to a specific PDO driver. Eyes start to bleed. Expected result: PDO Core PDO_DBLIB PDO_ODBC PDO_MYSQL PDO_OCI PDO_FIREBIRD PDO_SQLITE PDO Other Driver Actual result: -- PDO Related -- Edit bug report at https://bugs.php.net/bug.php?id=63078&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63078&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63078&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63078&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63078&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63078&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63078&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63078&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63078&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63078&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63078&r=support Expected behavior: https://bugs.php.net/fix.php?id=63078&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63078&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63078&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63078&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63078&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63078&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63078&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63078&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63078&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63078&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63078&r=mysqlcfg
[PHP-BUG] Req #52137 [NEW]: pdo_dblib does not implement lastInsertId
From: ssufficool Operating system: Linux PHP version: trunk-SVN-2010-06-22 (SVN) Package: PDO related Bug Type: Feature/Change Request Bug description:pdo_dblib does not implement lastInsertId 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 bug report at http://bugs.php.net/bug.php?id=52137&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52137&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52137&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52137&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52137&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52137&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52137&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52137&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52137&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52137&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52137&r=support Expected behavior: http://bugs.php.net/fix.php?id=52137&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52137&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52137&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52137&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52137&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52137&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52137&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52137&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52137&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52137&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52137&r=mysqlcfg
[PHP-BUG] Bug #52885 [NEW]: PDO_DBLIB does not properly quote char(0)
From: ssufficool
Operating system: Linux
PHP version: 5.3SVN-2010-09-19 (SVN)
Package: PDO related
Bug Type: Bug
Bug description:PDO_DBLIB does not properly quote char(0)
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 bug report at http://bugs.php.net/bug.php?id=52885&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52885&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52885&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52885&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52885&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52885&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52885&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52885&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52885&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52885&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52885&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52885&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52885&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52885&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52885&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52885&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52885&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52885&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52885&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52885&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52885&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52885&r=mysqlcfg
Bug #63638 [Com]: Cannot connect to SQL Server 2008 with PDO dblib
Edit report at https://bugs.php.net/bug.php?id=63638&edit=1
ID: 63638
Comment by: ssuffic...@php.net
Reported by:pmeunier at cybergeneration dot com
Summary:Cannot connect to SQL Server 2008 with PDO dblib
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux Slackware 13
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
[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.
[2012-12-05 16:49:09] f dot marquis at of2m dot fr
same problem here, but only from time to time (not all connections are failing
like with pmeunier)
seems related to #63258
[2012-11-28 21:43:00] pmeunier at cybergeneration dot com
We made a compare between the /ext/pdo_dblib/ php 5.4.7 and php 5.4.9 and found
only one file was changed. Line 318 in dblib_driver.c went from :
// In PHP 5.4.7
DBSETOPT(H->link, DBQUOTEDIDENT, 1);
To :
// In PHP 5.4.9
DBSETOPT(H->link, DBQUOTEDIDENT, NULL);
For fun, we tried to revert to passing 1 for the last parameter... and guess
what ? It worked. Since we don't actually understand what this function makes,
and why the parameter was changed, we don't find this solution very clean,
unless it is eventually confirmed by a PHP developper.
[2012-11-28 21:09:02] pmeunier at cybergeneration dot com
Description:
We are relying on PDO_DBLIB to connect to our SQL Server 2008 Server in PHP,
hosted on a Linux platform. We were running PHP 5.4.7 and everything was fine.
When we upgraded to 5.4.9, all connections to SQL Server were failing with the
following error : Warning: PDO::__construct(): Called dbsetopt with parameter 3
NULL (severity 11). We tried with different logins to be sure that it was not a
permission issue, but the bug also occurs when trying to log with 'sa'.
Test script:
---
$connection = new PDO('dblib:host=myServerHost;dbname=MyDatabase', 'username',
'pass');
Expected result:
We expect no warnings to be thrown and connection to SQL Server to work
Actual result:
--
A warning is thrown : Warning: PDO::__construct(): Called dbsetopt with
parameter
3 NULL (severity 11)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63638&edit=1
