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

Hi

Firstly, what type of ODBC connection are you using here. If using the
OpenLink ODBC driver for Informix, which is an alternative here to
your problem, there are two ways of tracing ODBC calls, either via the
Driver Manager trace option which is available via the ODBC
Administrator or tracing what the actual Driver is trying to
accomplish, which is done by the OpenLink Client Configurator utility.
You can then see what is been sent to the Database via ODBC.

HTH
Regard
Emmon Simbo
Technical Services Manager (UK)
http://www.openlinksw.com

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

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

Perhaps onstat -g sql or onstat -g ses may help. At least that will
show you the SQL statement that preceded the long transaction
rollback.

Andy


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