Hmmm .... Tim, you really got me thinking ...
1. Support person ran the form.
2. Hit the error
3. Exited the form.
Now point 3, will issue a rollback (Oracle Forms) so is that why we see two rollbacks in the trace file? The SQL is part of a DB package used by the form. I seem to remember that Oracle Forms had a bug, that returned ORA-1403 when either there actually was ORA-1403 or there wasn't any error but DBMS_ERROR_CODE() returned 1403 error. The probably have fixed the bug by now.
But in this case, developer isn't checking the value of DBMS_ERROR_CODE(), for that matter developer is checking for no errors at all, and completely relying on Oracle to report these errors in the most obsecure way (sorry IMHO that's how Forms return server errors). They don't want to do too much coding (especially when it comes to exception handling).
That being said, this SQL is executed as implicit cursor, so that might explain more than one row fetch and thus 1403. The worst part is I don't see the second fetch in the trace file.
Slightly off topic:
I'd also like to take this opportunity to say that today we have for the 2nd time (two separate issues) logged a bug report to fix the patch that OWS provided to fix a bug that we reported earlier.
So we are requesting a patch to fix a patch to fix a bug ... to quote Yogi Berra ... "It's Deja vu all over again !!"
I get to go home 1/2 day today .... conditions permitting ... but my boss is on vacation, so conditions are perfect.
Raj
______________________________________________________
Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN Inc.
QOTD: Any clod can have facts, but having an opinion is an art!
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 31, 2002 9:24 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Tales Of Big Hammer #10046 (AKA event 10046)
Raj,
The application may have interpreted this as ORA-01403, but
I've no clue as to why the "SQL*Net break/reset to client"
occurred. You can see about 7 seconds of wait for response
from the client, after which a rollback occurs...
The FETCH shows "r=1" indicating that at least one row was
returned. Was the application doing "array fetches" for
that statement? Was a row returned? Is this PL/SQL or ???
It is interesting how these traces feel very much like
archaeology; just have to use a delicate hammer to knock
the bits loose...
-Tim
*********************************************************************This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*********************************************************************1
