FreeTDS Development Group

["Lowden, James K" <james.k.lowden AT alliancebernstein.com>]

> From: Xu Behoneo
> Sent: Thursday, November 30, 2006 1:53 AM
> 
> I'm using ODBC API to query a MSSQL database with FreeTDS as the
> driver, the timeout issue was brought when I calling SQLExecDirect
> and at such time the server is down, the SQLExecDirect will be
> blocked. I think maybe I need to set some timeout attributes, I
> look into the ODBC API documents, and find SQLSetConnectAttr can
> set timeout for a dbc handle, and SQLSetStmtAttr can set timeout
> for a statement handle. I set both, but the SQLExecDirect still
> block, I look into the freetds code and find that, I'm not sure
> whether this timeout should be apply to the driver. As you have
> said, maybe my application need to take some special operation for
> this case.

Are you saying: 

1.  you call SQLSetConnectAttr passing SQL_ATTR_CONNECTION_TIMEOUT as
the attribute, and
2.  you call SQLExecDirect while not connected to the network, and
3.  when the network is down, the timeout you set is not honored (i.e.
you don't get HYT01, "Connection timeout expired")?  

According to Microsoft's documentation, SQL_ATTR_CONNECTION_TIMEOUT
certainly applies to SQLExecDirect.  The documentation does not say what
the state of the connection is after the timeout.  

As I understood your original message, a question arises over how the
driver should handle the timeout.  To remain synchronized with the
server, it sends a cancel message, and it waits for an acknowledgement.
If the connection is to be useable after the timeout, it *must* receive
that acknowledgement.  

Should the driver wait patiently for the server's acknowledgement, and
return a working connection to the application if at all possible, or
should it honor the timeout and abandon the connection?  

The docs seem to say you're right: it should give up and return a
non-working connection.  

        "SQL_ATTR_CONNECTION_TIMEOUT
(ODBC 3.0) An SQLUINTEGER value corresponding to the number of seconds
to wait for any request on the connection to complete before returning
to the application. The driver should return SQLSTATE HYT00 (Timeout
expired) anytime that it is possible to time out in a situation not
associated with query execution or login."

That seems to say we should issue the request and close the connection.


IMHO that's not a good spec.  *Network* problems should be handled by
the network and the application, that the driver's timeout should apply
only to *server* delays.  That's what Frediano's code does.  It assumes
it can communicate with the server, and tries to return a working
connection.  IMHO that's a good assumption, because a slow server is
more common than a broken network.  Usually the driver can return a
useable connection.  

But I didn't write the spec or the code.  We can't change the spec.
Maybe we should change the code.  

--jkl

-----------------------------------------
The information contained in this transmission may be privileged and
confidential and is intended only for the use of the person(s) named
above. If you are not the intended recipient, or an employee or agent 
responsible
for delivering this message to the intended recipient, any review, 
dissemination,
distribution or duplication of this communication is strictly prohibited. If 
you are
not the intended recipient, please contact the sender immediately by reply 
e-mail
and destroy all copies of the original message. Please note that we do not 
accept
account orders and/or instructions by e-mail, and therefore will not be 
responsible
for carrying out such orders and/or instructions.  If you, as the intended 
recipient
of this message, the purpose of which is to inform and update our clients, 
prospects
and consultants of developments relating to our services and products, would 
not
like to receive further e-mail correspondence from the sender, please "reply" 
to the
sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New 
York,
NY 10105.