Edit report at https://bugs.php.net/bug.php?id=13838&edit=1
ID: 13838
Updated by: krakjoe@php.net
Reported by: f dot glasner at feldmann-mg dot com
Summary: Default ODBC statement concurrency option does not
allow some queries on MSSQL
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package: ODBC related
Operating System: *
PHP Version: *
Block user comment: N
Private report: N
New Comment:
I think it's safe to assume that the implementation of this feature request that was being
worked on 18 years ago didn't pan out.
Since no other fixes have been proposed in the time since, I'm going to close this at wont fix,
as that seems to more accurately represent this bugs actual status.
Previous Comments:
------------------------------------------------------------------------
[2003-01-06 12:22:19] kalowsky@php.net
This is true for all versions of PHP really. The ODBC env needs to be delt with differently for
this to work. I've been working on a fix for this for awhile.
------------------------------------------------------------------------
[2001-10-26 10:55:48] f dot glasner at feldmann-mg dot com
I am using PHP 4.0.6 on WinNT4 SP5. The database is
MSSQL 7.0.
With the default ODBC statement concurrency option set
by PHP/ODBC some queries are not executed by SQL Server.
$conn = odbc_connect("MyDSN", "user", "pass");
odbc_exec($conn, "SELECT * FROM test1 WITH(UPDLOCK HOLDLOCK) WHERE ID=1");
results in this error:
[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot specify UPDLOCK or TABLOCKX with READ ONLY or
INSENSITIVE cursors.
Workaround:
Manually set a default ODBC statement option that
results in a cursor that is not read only:
$conn = odbc_connect("MyDSN", "user", "pass");
odbc_setoption($conn, 1, SQL_CONCURRENCY, SQL_CONCUR_VALUES);
odbc_exec($conn, "SELECT * FROM test1 WITH(UPDLOCK HOLDLOCK) WHERE ID=1");
The drawback of the workaround is that it does not work
for persistent connections.
But it would be nice to have persistent connections also.
So, I propose some extensions on the arguments of
odbc_connect/odbc_pconnect:
int odbc_connect (string dsn, string user, string password [, int cursor_type[, array
default_statement_options]])
So it could be used like this:
$dso = array(SQL_CURSOR_TYPE=>SQL_CURSOR_DYNAMIC,
SQL_CONCURRENCY=>SQL_CONCUR_VALUES);
$conn = odbc_connect("DSN", "user", "pass", SQL_CUR_USE_DRIVER,
$dso);
You could either set the defaults with SQLSetConnectOption
after SQLConnect or do a SQLSetStmtOption after allocating
an ODBC statement handle for all the items of the array.
Maybe it would be possible to change the signature of
odbc_connect/odbc_pconnect to:
int odbc_connect (string dsn, string user, string password [, mixed odbc_options])
where mixed means the (current) int or the proposed array.
Advantages:
- Persistent connections could be made to accept some
statement options because odbc_pconnect has all the
information for discriminating and selecting an
appropriate connection.
There seems to be a similar problem reported
with bug id #9738 (http://bugs.php.net/bug.php?id=9738).
But instead of providing some sort of "odbc_prepare_clean"
I would prefer to extend the capability of setting ODBC
statement options in a much more flexible way that can be
used for persistent connections also.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=13838&edit=1