Re: 10.2.0.1 trace uncommitted inserts

On Apr 29, 12:47*pm, John Hurley wrote:
> Mladen:
>
> # Now this looks like an intelligent design! There are entities called
> "triggers" which can be made to fire on insert.
>
> ...
>
> So you have already been able to look inside from the little material
> supplied by the OP and guess that triggers are involved? *Your crystal
> ball must be working better than mine today.

That is not what Mladen said or implied. The intent here is to
suggest that the OP possibly create a trigger to capture insert
transactions into a separate table, with other information such as who
did the insert and when, to track what is or isn't happening. There
was no mention that the venedor is using triggers.


David Fitzjarrell

On Apr 29, 4:15*pm, ddf wrote:
> On Apr 29, 12:47*pm, John Hurley wrote:
>
> > Mladen:
>
> > # Now this looks like an intelligent design! There are entities called
> > "triggers" which can be made to fire on insert.
>
> > ...
>
> > So you have already been able to look inside from the little material
> > supplied by the OP and guess that triggers are involved? *Your crystal
> > ball must be working better than mine today.
>
> That is not what Mladen said or implied. *The intent here is to
> suggest that the OP possibly create a trigger to capture insert
> transactions into a separate table, with other information such as who
> did the insert and when, to track what is or isn't *happening. *There
> was no mention that the venedor is using triggers.
>
> David Fitzjarrell

David:

# That is not what Mladen said or implied.

So you are Mladen are twins that understand exactly what the other was
trying to convey in a newsgroup posting?

I did not realize that ...

#*The intent here is to suggest that the OP possibly create a trigger
to capture insert transactions into a separate table, with other
information such as who did the insert and when, to track what is or
isn't *happening.

That's such a better idea than getting a 10046 trace initially eh?

#*There was no mention that the venedor is using triggers.

Try reading the next several lines of Mladens reply that I left out a
couple of times. Do the shampoo thing ( rinse and repeat ) ...

On Fri, 29 Apr 2011 15:29:10 -0700, John Hurley wrote:

> So you are Mladen are twins that understand exactly what the other was
> trying to convey in a newsgroup posting?

You're beginning to bore me.



--
http://mgogala.byethost5.com

On Apr 29, 3:29*pm, John Hurley wrote:
> David:
>
> # That is not what Mladen said or implied.
>
> So you are Mladen are twins that understand exactly what the other was
> trying to convey in a newsgroup posting?
>
> I did not realize that ...
>
> #*The intent here is to suggest that the OP possibly create a trigger
> to capture insert *transactions into a separate table, with other
> information such as who did the insert and when, to track what is or
> isn't *happening.
>
> That's such a better idea than getting a 10046 trace initially eh?
>
> #*There was no mention that the venedor is using triggers.
>
> Try reading the next several lines of Mladens reply that I left out a
> couple of times. *Do the shampoo thing ( rinse and repeat ) ...

I have, but apparently you didn't comprehend the text. Read the post
prior to Mladen's stating that the vendor can't figure out why this
isn't working; any vendor that can't figure out their own product is
suspect in my book, too.


David Fitzjarrell

David:

# I have, but apparently you didn't comprehend the text. *Read the
post prior to Mladen's stating that the vendor can't figure out why
this isn't working; any vendor that can't figure out their own product
is suspect in my book, too.

We have one posting from someone "claims" the vendor cannot figure out
what is going on. Sometimes vendors are provided incomplete
information believe it or not. Sometimes vendors work with people
running applications on unsupported environments or old versions of
applications believe it or not. Running critical applications on
unpatched Oracle base releases is not always a good idea believe it or
not.

The original poster does not apparently know about setting a 10046
trace. More than one person implicated in not having the ability to
figure out what is going on at least in my mind.

Based on one limited posting jumping on the bandwagon claiming the
vendor cannot figure out what is going on seems a little hasty.

Recommending that people consider implementing triggers to help debug
a vendors application given the current amount of information in this
thread also seems a little hasty.

Just my opinion ...

On Fri, 29 Apr 2011 17:00:01 -0700, John Hurley wrote:

> The original poster does not apparently know about setting a 10046
> trace. More than one person implicated in not having the ability to
> figure out what is going on at least in my mind.

10046 trace has nothing to do with the problem. The original problem, at
least according to what I have read, is that the application log contains
the record of the transaction while the table doesn't. If that is a usual
3-tier application with an application server, client and a DB server,
tracing it will not be trivial as it may include many sessions that are
unrelated to the problem. If the vendor "cannot figure out what's
happening", the vendor is extremely unlikely to be using
DBMS_APPLICATION_INFO. The best bet is a trigger with an autonomous
transaction which will show what was fired and when. That is called
"debugging" and is usually done by the people who write the application.
If they are unable to do so, which is what the OP implied, then they are
not very competent, period.
Furthermore, your sanctimonious "I'm holier than thou" attitude is
beginning to bore the heck out of me, so I ignore majority of your posts.
You can shove your crystal ball where the sun doesn't shine.



--
http://mgogala.byethost5.com