I would place this all in capital letters



D. DISABLE TRACING ON THE TRACING TAB.





Don't forget to disable this - it could have a huge impact on performance





-----Original Message-----

From: owner-informix-list@iiug.org [mailtowner-informix-list@iiug.org] On Behalf Of Netrista Khatam

Sent: Tuesday, January 27, 2004 9:37 PM

To: informix-list@iiug.org

Subject: Re: How to trace ODBC connection?



miyaki <lcib@yahoo.com> wrote in message news:<bv245a$f5m$1@terabinaries.xmission.com>...

> Hi all,

>

> Most of our applicatoins were developed in Windows/Web

> platform and they are accessing my database via ODBC

> type of connection. I found that it's very difficult

> to trace the problem caused by the ODBC connection,

> especially from the Web based application. From the

> output of onstat -u, i can only see the tty and login

> id. However, the tty and login id is the same for all

> the connections from a particular Web application. For

> instance, i have over 100 concurrent users using a web

> application that connected to my database via a Web

> server. During that time, a LONG Transaction occured

> which is caused by one of the 100 concurrent users. In

> this case, I'm not able to catch the the real user

> that causing the problem as the output of onstat -u is

> showing the same login id and tty. I believe some of

> you guys also experience this type of situation

> before. Hence, apppreciate that if you could share

> with me how you handle this type of problem.

>

> BTW, here's some info pertaining to my database

> server.

>

> OS = Solaris 2.7 (x86 platform)

> IDS = 7.31UC2

>

> Thanks,

> Miyaki

>

> __________________________________

> Do you Yahoo!?

> Yahoo! SiteBuilder - Free web site building tool. Try it!

> http://webhosting.yahoo.com/ps/sb/

> sending to informix-list





Hello Miyaki,



Theoretically, you should be able to trace the ODBC calls by

activating tracing with the driver manager. For instance, these

instructions would help you on Windows:





A. Open your ODBC Data Sources utility.

B. Enable tracing on the tracing tab.

C. Recreate the error condition.

D. Disable tracing on the tracing tab.

E. Locate the file indicated in the log file path on the tracing tab.



That said, this could seriously impact performance. It is likely that

you would also generate a file running into the thousands of pages.



At this point, are you altogether certain that the problem stems from

specific ODBC API calls or SQL statements? Could it be a kernel tuning

revealed by heavy load or some other situation for which a trace would

not be needed? In general, what is the error message or defining

symptoms of the problem? What appears in the Informix error log?



Netrista Khatam

Technical Services Manager

OpenLink Software

http://www.openlinksw.com

Product Weblogs:

Virtuoso: http://www.openlinksw.com/weblogs/virtuoso

UDA: http://www.openlinksw.com/weblogs/uda

Universal Data Access & Virtual Database Technology




________________________________

<< ella for Spam Control >> has removed 985 Spam messages and set aside 167 Newsletters for me
You can use it too - and it's FREE! www.ellaforspam.com

sending to informix-list