timeout using SDK 2.81 TC3 - .NET Managed Provider

[-=Eric=-]

We have a showstopper issue...after upgrading from SDK 2.7x to 2.81
TC3 (to get the .NET managed provider), we're occasionally running
into timeout errors in .NET applications. Specifically, the.NET code
is throwing this:

Error Message :
ERROR [HYT00] [Informix][Informix ODBC Driver]Timeout expired.
ERROR [HY008] [Informix][Informix ODBC Driver][Informix]Statement
interrupted by user.
Stack Trace= at Microsoft.Data.Odbc.OdbcConnection.HandleError(IntPtr
hHandle, SQL_HANDLE hType, RETCODE retcode)
at Microsoft.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior
behavior, String method)
at Microsoft.Data.Odbc.OdbcCommand.ExecuteNonQuery()
at OurCompany.WWWServices.Methodname(XmlNode inputDoc)
Source=iclit09b.dll

I've been unable to figure out, either in the documentation or on the
'net how to change the default timeout. I think it might be possible
within the code, but this is a major problem - we're not about to go
revamp our entire codebase.

If anyone has seen this or has suggestions, we're all ears. So far,
we've tried inserting various things into the connection string,
setting the CONTIME and CONRETRY environment variables in SetNet32.

Our platform is Informix 9.4O with application servers running Win 2k
and Win2k3 server.

[Tsutomu Ogiwara]

Hi Eric.

Make sure SQL_QUERY_TIMEOUT of SetStmtOption in M$ .NET manual.

I am not Windows familiar, sorry I can say the avobe all.
--
Tsutomu Ogiwara from Tokyo Japan.
ICQ#:168106592

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail

sending to informix-list

[-=Eric=-]

Apparently, this issue affects the .NET Managed Provider as well as
ODBC. The new driver works correctly, but there's been a change in
the default behavior. Previously, in SDK 2.7, commands did not time
out by default. Now in 2.81 TC3, commands time out after 30 seconds.

The big problem with this is that you must explicitly set the command
timeout in your code. If you have a large installed base of code
already, that's a lot of re-factoring, re-testing, and re-deploying
just to upgrade the driver.

And there appears to be no way to globally change the default timeout
value. If we could set the value to 0 (no timeout), then at least the
new driver's basic behavior would match the old one and save us a lot
of headache.

"Tsutomu Ogiwara" <tsutomu...@hotmail.com> wrote in message news:<ci6cjk$gl1$1...@news.xmission.com>...