Re: Newbie question - Oracle Trace Results

From: bdbafh <bdbafh_at_gmail.com>
Date: Wed, 9 Apr 2008 09:05:03 -0700 (PDT)
Message-ID: <dd9a21c7-d1f3-4adf-9e27-78d6407f494d@a23g2000hsc.googlegroups.com>


On Apr 9, 10:57 am, tony_auds..._at_hotmail.com wrote:
> Hi,
> First time post so be gentle :)
>
> When looking at a trace file, does the absence of an Exec, as in the
> following
>
> PARSING IN CURSOR #1 len=3523 dep=0 uid=32 oct=3 lid=32
> tim=30556916889618 hv=3499698552 ad='a6a67068'
> {SQL Select Statement - Not included due to length of 3000+ chars}
> END OF STMT
> PARSE
> #1:c=100000,e=148774,p=7,cr=425,cu=0,mis=1,r=0,dep=0,og=4,tim=30556916889610
>
> indicate that the SQL statement was not executed?? The PARSE..
> statement was the last line in the Trace file.
> If so, is there anyway to find out why?
>
> I have a Windows application that uses SQLExecDirect to execute SQL
> statement on a Oracle 8i dbase.
> It seems to be that when the SQL statement is of a certain size, the
> application just aborts.
>
> The issue is that we have identical Application, Oracle Client, Oracle
> server and drivers on different Customer sites and on some sites the
> application works and others it does not.
>
> Regards

I would expect to see an EXEC and a FETCH line, as well as numerous SQL*Net messages.

Is there any chance that the environment could be brought up to date from 8i R3 to 10g R2 with the current patchsets applied?

(good luck opening a support request on 8i)

If you're using ODBC, be careful with the 10.2.0.3 patchset, or the Oracle 10g R2 Client for MS Vista that has the 10.2.0.3 patchset built in. There is a patch available for the issue.

-bdbafh Received on Wed Apr 09 2008 - 11:05:03 CDT

Original text of this message