ID: 36578
Updated by: [EMAIL PROTECTED]
Reported By: terry at bitsoup dot com
-Status: Closed
+Status: Bogus
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.2
Previous Comments:
------------------------------------------------------------------------
[2006-03-02 20:49:11] terry at bitsoup dot com
I'm just going to assume you don't want to fix broken functionality
with the way fetch() is handled. Since I can't convince you, you should
refer to the ANSI SQL standard to see how NO_DATA_FOUND is properly
handled.
In php_oci_error(), the case OCI_NO_DATA exists, but I can't see any
place it's being called from. I supplied the example code that shows
where it's being circumvented, though.
It makes sense to suppress the error when you don't have exception
handling, but it's being handled incorrectly in PHP5.
In oci8.c for 5.1.0-RC1, the TO-DO list has the line
* - Change return-value for OCIFetch*() (1-row read, 0-Normal end,
false-error) . That's why I mentioned being in the TO-DO list. It's no
longer there.
begin
select 1 from dual where 1=2;
exception
when NO_DATA_FOUND then
do_stuff();
end;
------------------------------------------------------------------------
[2006-03-02 19:58:01] [EMAIL PROTECTED]
> statement->error = 0; /* OCI_NO_DATA is NO error for us!!! */
This line talks for itself.
>You have it on the TODO list to handle the fetch case properly.
No, I don't have such item in my TODO list.
Please stop reopening this report.
If you consider such case as an error - you have to handle it yourself,
while others will continue using usual semantics - error is error and
"no data" is just no data.
------------------------------------------------------------------------
[2006-03-02 19:51:29] terry at bitsoup dot com
That's because you are currently discarding the error in oci8. You have
it on the TODO list to handle the fetch case properly.
if ((statement->error == OCI_NO_DATA) || (nrows == 0)) {
if (statement->last_query == 0) {
/* reset define-list for refcursors */
if (statement->columns) {
zend_hash_destroy(statement->columns);
efree(statement->columns);
statement->columns = 0;
statement->ncolumns = 0;
}
statement->executed = 0;
}
statement->error = 0; /* OCI_NO_DATA is NO error for us!!! */
statement->has_data = 0;
return 0;
}
------------------------------------------------------------------------
[2006-03-02 17:51:03] [EMAIL PROTECTED]
$s = oci_parse($c, "select 1 from dual where 1 = 2");
oci_execute($s);
var_dump(oci_fetch($s));
=>
bool(false) and no error.
------------------------------------------------------------------------
[2006-03-02 17:25:21] terry at bitsoup dot com
The empty resultset is not the error. Calling fetch() on an empty
resultset sets the error code to a warning and/or generates an
exception in every database engine I've seen.
In Oracle, it's error ORA-1403: no data found.
It's SQL_NODATA in ODBC drivers.
I believe it's Error 2053 in MySQL. mysql_stmt_fetch() returns
MYSQL_NO_DATA, and not 0 for success.
In it's current state, fetch() returning null without raising the
exception means we'll have to add the test and throw the exception
manually on every single query.
------------------------------------------------------------------------
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/36578
--
Edit this bug report at http://bugs.php.net/?id=36578&edit=1
