10.2.0.1 trace uncommitted inserts

#1

Hi,

I have an application written in .net, I have only the .exe, not the
source. It keeps processing data from an external source and inserting
on a table, but sometimes I can't see the data on the table. Sometimes
it inserts, sometimes doesn't. Vendor is taking too long to figure
that out, since the message that get inserted look like exactly like
the one that doesn't

I suspect it is trying to commit but something
wrong happens. App log doesn't show any error, external data source
says it sent the data correctly, App log says it received, but nothing
is inserted.

Is there a way to trace uncommited inserts? I would try to check if
the insert is happening at all, perhaps the App log isn't catching
something that could be a big error...

Thanks!

-- Tiago

#2

On Apr 28, 4:08*pm, Tiago <diariodastril... (AT) gmail (DOT) com> wrote:

Quote:

Hi,

* I have an application written in .net, I have only the .exe, not the
source. It keeps processing data from an external source and inserting
on a table, but sometimes I can't see the data on the table. Sometimes
it inserts, sometimes doesn't. Vendor is taking too long to figure
that out, since the message that get inserted look like exactly like
the one that doesn't

I suspect it is trying to commit but something
wrong happens. App log doesn't show any error, external data source
says it sent the data correctly, App log says it received, but nothing
is inserted.

Is there a way to trace uncommited inserts? I would try to check if
the insert is happening at all, perhaps the App log isn't catching
something that could be a big error...

Thanks!

-- Tiago

If you are really running on 10.2.0.1 ( not 10.2.0.4 or 10.2.0.5 )
then some really bad things could be happening with a ton of unapplied
oracle maintenance.

An Oracle 10046 trace is the usual recommended definitive way of
tracing what is going on with an application.

Can you work with a dba resource to get a trace done for you?

#3

On Thu, 28 Apr 2011 13:08:02 -0700, Tiago wrote:

Quote:

I have an application written in .net, I have only the .exe, not the
source. It keeps processing data from an external source and inserting
on a table, but sometimes I can't see the data on the table. Sometimes
it inserts, sometimes doesn't. Vendor is taking too long to figure that
out, since the message that get inserted look like exactly like the one
that doesn't

I suspect it is trying to commit but something wrong
happens. App log doesn't show any error, external data source says it
sent the data correctly, App log says it received, but nothing is
inserted.

Now this looks like an intelligent design! There are entities called
"triggers" which can be made to fire on insert. Also, the vendor looks
like a very competent application producer. Can you reveal us the name of
that brilliantly competent software company? The other users need to be
warned.

--
http://mgogala.byethost5.com

#4

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.

#5

On Apr 29, 12:47*pm, John Hurley <hurleyjo... (AT) yahoo (DOT) com> wrote:

Quote:

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

#6

On Apr 29, 4:15*pm, ddf <orat... (AT) msn (DOT) com> wrote:

Quote:

On Apr 29, 12:47*pm, John Hurley <hurleyjo... (AT) yahoo (DOT) com> 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

#7

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 ) ...

#8

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

Quote:

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

#9

On Apr 29, 3:29*pm, John Hurley <hurleyjo... (AT) yahoo (DOT) com> wrote:

Quote:

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

#10

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 ...