Oracle-L: RE: Tales Of Big Hammer #10046 (AKA event 10046)

From: Jamadagni, Rajendra <Rajendra.Jamadagni_at_espn.com>
Date: Tue, 31 Dec 2002 07:24:27 -0800
Message-ID: <F001.00524B0D.20021231072427@fatcity.com>

Hmmm .... Tim, you really got me thinking ...

Support person ran the form.
Hit the error
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-----
Sent: Tuesday, December 31, 2002 9:24 AM To: Multiple recipients of list ORACLE-L

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

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jamadagni, Rajendra
  INET: Rajendra.Jamadagni_at_espn.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).



text/plain attachment: ESPN_Disclaimer.txt

Received on Tue Dec 31 2002 - 09:24:27 CST