Title: RE: Tales Of Big Hammer #10046 (AKA event 10046)
Jonathan,
Yes this code is inside a function inside a pl/sql package. As it is an implicit select, with (of course) no exception handler (who needs extra code anyways), I believe your hypothesis is right. Maybe next week I'll take
I've been trying to emulate this on 9.2.0.2, but I can't.
The oddity (I think) is that your
WAIT #0: nam='SQL*Net break/reset to client' ela= 57 p1=675562835
p2=1 p3=0
is recorded against cursor #0, not cursor #54, so
it is cursor zero (whatever that is) that has failed
to return any data, not
I saw this thread for some time and wanted to add something that could help
but was not sure if I remember correctly or not.
This was in Forms 3.0 where I remember it had its own PL/SQL engine. So my
guess things will be different when traced on the server side. Is it still
the same in the new
Brings to mind some of the great hammer quotes:
When all you have is a hammer, everything tends to
look like a nail
When all you have is a hammer, maybe brain surgery is
not for you
:-)
Connor
--- Tim Gorman [EMAIL PROTECTED] wrote: Tales Of
Big Hammer #10046 (AKA event
10046)Generally
that of ESPN Inc.
QOTD: Any clod can have facts, but
having an opinion is an art!
-Original Message-From: Tim Gorman
[mailto:[EMAIL PROTECTED]]Sent: Monday, December 30, 2002 7:49
PMTo: Multiple recipients of list ORACLE-LSubject: Re:
Tales Of Big Hammer #10046 (AKA event 10046
e recipients of list ORACLE-L
Sent: Tuesday, December 31, 2002 7:58
AM
Subject: RE: Tales Of Big Hammer #10046
(AKA event 10046)
Tim,
I don't see that ... I know this sq
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, December 31, 2002 8:59
AMTo: Multiple recipients of list ORACLE-LSubject: Re:
Tales Of Big Hammer #10046 (AKA event 10046)
Raj,
Thanks for sharing this with us. In your original
post you mentioned that you saw a "rollback" right after th
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
Title: RE: Tales Of Big Hammer #10046 (AKA event 10046)
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
Title: Tales Of Big Hammer #10046 (AKA event 10046)
Generally you won't find "err=1403" text in the raw
".trc" file. Instead, if you carefully examine the FETCH lines, you'll see
"r=0" (i.e. zero rows returned) in amongst all the other statistics. Very
very difficult to catch and often
10 matches
Mail list logo