Edit report at https://bugs.php.net/bug.php?id=44643&edit=1
ID: 44643
Updated by: git@php.net
Reported by: ethan dot nelson at ltd dot org
Summary: bound parameters ignore explicit type definitions
-Status: Verified
+Status: Closed
Type: Bug
Package: PDO ODBC
Operating System: *
PHP Version: 7.4
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of cmb69
Revision: https://github.com/php/php-src/commit/23a3bbb468adb611150a51fe82f8e5a22fbfae5c
Log: Fix #44643: bound parameters ignore explicit type definitions
Previous Comments:
------------------------------------------------------------------------
[2021-05-11 12:51:25] cmb@php.net
The following pull request has been associated:
Patch Name: Fix #44643: bound parameters ignore explicit type definitions
On GitHub: https://github.com/php/php-src/pull/6973
Patch: https://github.com/php/php-src/pull/6973.patch
------------------------------------------------------------------------
[2021-05-11 12:46:21] cmb@php.net
While I cannot reproduce this with ODBC Driver 17 for SQL Server,
I consider it not unlikely that other still supported drivers have
that issue, and I agree that the fallback to either
SQL_LONGVARCHAR or SQL_LONGVARBINARY is very rough.
------------------------------------------------------------------------
[2020-09-28 13:37:18] cmb@php.net
Related To: Bug #48295
------------------------------------------------------------------------
[2014-03-09 01:50:20] wschalle at gmail dot com
As an addendum, I think pdo_sqlsrv has a very thorough implementation of type translation between
PHP and SQL types and back. It is exhaustively complete, but doesn't perform quite as well as
pdo_odbc's one-size-fits-all routine.
At least some of what pdo_sqlsrv is doing instead of calling SQLDescribeParam is an example of the
right general way to solve the issues in pdo_odbc that occur when SQLDescribeParam is not supported
or supported only partially.
------------------------------------------------------------------------
[2014-03-08 22:22:05] wschalle at gmail dot com
This isn't due to a SQL server bug but instead it is due to well-documented laziness on the sql
server developers part when writing the SQLDescribeParam function in the SQL Server ODBC driver.
Basically when parameters are within a subquery, SQLDescribeParam doesn't return data for them.
The fact that this breaks queries is actually pdo_odbc's fault though, for relying entirely on
the output (or lack thereof) of SQLDescribeParam to dictate how it then passes the PHP variable
through to the SQLBindParam function.
This issue doesn't just exist with the SQL Server driver either, there are several DBMS's
with issues with SQLDescribeParam, but sql server's behavior is the worst.
PDO's handling of a bad return from SQLDescribeParam is not quite where it should be - right
now if SQLDescribeParam doesn't work, the driver makes the strange assumption that the
parameter should be sent as either SQL_LONGVARBINARY in the case of a LOB or SQL_LONGVARCHAR in the
case of a non-LOB type.
The correct behavior would be at the very least to use the specified param_type and/or the PHP type
to make a better fallback guess. Bound parameters specified as PDO_PARAM_INT should absolutely be
cast to long and sent to the server as SQLINTEGER.
I'd really like to see this bug fixed, as it is one of the only things keeping PHP running on
linux from accessing SQL server properly. My app supports a variety of DBMS's, but if a company
has data in SQL Server and we need to access it, the app either has to run on a windows server (god
why), use non-parameterized queries, replace all parameter placeholders with CAST(CAST(?,
varchar),int), use parameterized queries without any subqueries, or use direct exec queries. Not the
best of situations.
PERL has had the same issues - see:
https://rt.cpan.org/Public/Bug/Display.html?id=64968https://rt.cpan.org/Public/Bug/Display.html?id=50852http://www.martin-evans.me.uk/node/50
------------------------------------------------------------------------
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=44643
--
Edit this bug report at https://bugs.php.net/bug.php?id=44643&edit=1