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
Title: Tales Of Big Hammer #10046 (AKA event 10046)
Tim,
I don't see that ... I know this sql caused the problem
...
===
PARSING IN CURSOR #54 len=238 dep=1 uid=44 oct=3 lid=44
tim
Title: 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 the "SQL*Net
break/reset to client" and that was how you figured out the 1403 error. I don't
see that
Title: Tales Of Big Hammer #10046 (AKA event 10046)
Arup,
Since I didn't see a line reporting error 1403, I was puzzled for a bit.
But here is the application knowledge came handy. I should have see a commit for
a successful operation. I didn't and instead saw a ROLLBACK. Immediately before
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)
On Friday our application support person called me and said User is getting a ORA-1403 error in one form. I should mention that this is complex. And I need a solution immediately.
So, I gave them the hammer (with the sql string to put
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
ver
11 matches
Mail list logo
