ID: 15141
Comment by: bergy at us dot ibm dot com
Reported By: cox at idecnet dot com
Status: No Feedback
Bug Type: ODBC related
Operating System: Linux
PHP Version: 4.1.1
New Comment:
I'm haveing a similar problem. I'm seeing the same "Option Value
Changed" warning, and by looking at the ODBC code, I see that only one
error/message is ever retrieved per attempt. There are comments in the
code (in odbc_sql_error) indicated a couple of loops, with the comment
that the loop would be endless for some ODBC drivers. My environment
is PHP 4.3.4 on RedHat Linux, IBM DB2 8.1, using unixODBC 2.2.2 (PHP is
configured without the "--with-db2"). In my case, I'm undable to
handle the actual error in my code because I cannont retrieve the
actual error -- only the warning.
I would suggest modifying the code to loop retrieving errors, but
either detect an endless loop (hard), or limit the number of errors
returned to some reasonable value (easy -- I would think 5 would be
more than enough).
Previous Comments:
------------------------------------------------------------------------
[2002-02-15 12:25:43] [EMAIL PROTECTED]
No feedback was provided for this bug, so it is being suspended.
If you are able to provide the information that was requested,
please do so and change the status of the bug back to "Open".
------------------------------------------------------------------------
[2002-01-22 19:11:57] [EMAIL PROTECTED]
Please try a recent CVS snapshot, a small change has been done to the
cursor handling which might change your behavior seen.
------------------------------------------------------------------------
[2002-01-21 07:46:14] cox at idecnet dot com
The PHP odbc driver doesn't manage errors correctly. Here is the
complete explanation the Easysoft team gave me:
From: Martin J. Evans <[EMAIL PROTECTED]>
"Tomas V.V.Cox" wrote:
>
> Hi,
>
> I'm getting a little bit crazy trying to figure out why I always get
the
> same unclear error: "01S02 Option Value Changed" when I do *any* bad
> action. Ie:
>
> "SELECT * FROM tableThatDoesNotExist"
> "SELECT e FROM phptest" (when the "e" field doesn't exist)
>
> instead of the native code/mesage. Note, that all works fine if there
is
> no "human" error.
> I'm using php 4.1.1, unixODBC 2.0.8 as client and OOB - Access as
> server.
>
> Thanks for any tip on how to solve this obscure problem.
>
> Tomas V.V.Cox
01S02 is the ODBC defined State and the text for that state is
"option value changed". PHP does not give you the context of the
diagnostic because PHP ignores SQL_SUCCESS_WITH_INFO when attempting
to change the cursor to a dynamic cursor.
i.e.
the following code in PHPs php_odbc.c causes it:
if (rc == SQL_SUCCESS) {
if ((result->fetch_abs = (scrollopts &
SQL_FD_FETCH_ABSOLUTE)))
{
/* Try to set CURSOR_TYPE to dynamic. Driver
will replace this with other
type if not possible.
*/
if (SQLSetStmtOption(result->stmt,
SQL_CURSOR_TYPE, SQL_CURSOR_DYNAMIC)
== SQL_ERROR) {
odbc_sql_error(conn, result->stmt, "
SQLSetStmtOption");
SQLFreeStmt(result->stmt, SQL_DROP);
efree(result);
RETURN_FALSE;
}
}
} else {
result->fetch_abs = 0;
}
As PHP uses SQLError() to get diags and PHP is an ODBC 2.0 app the
ODBC
spec says the diags stay in place until they are retrieved. So, what
happens is the above code is executed for each new statement and it
generates an informational diagnostic. Then, at some stage later
when you get an error, PHP pulls the first diag which is the one
above and not the one you want. In order to get the one you want you
will have to:
[1] Add a call to SQLError to the above code if SQLSetStmtOption
returns SQL_SUCCESS_WITH_INFO - this will clear this diag of
the ODBC driver (driver manager) stack.
[2] Change PHP to allow odbc_error etc to be called repeatedly
until all diagnostics are cunsumed and you get the one you want.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=15141&edit=1
