FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: ZIGLIO, Frediano, VF-IT
> Sent: Monday, June 27, 2005 9:35 AM
>> 
>> Is there any way to detect server disconnection?
>> I have FreeTDS installed from ports on FreeBSD 5.3 (version 5.0 as
>> port says).
>> Everything working great, but in case network problems or SQL server
>> restart tds_submit_query simply returns 0 (TDS_FAIL) with no extra
>> information.
>> Can I handle such kind of situation?
>> Thank You!
>>  
> 
> I remember some (old) post on this subject... it seems that FreeTDS
> is too silent about connection closing. It close correctly connection
> and all future function should return failure condition however it
> do not launch any message to client. James, what do you think about?
> How do proprietary libraries behave? Do they continue informing
> client that connection is closed?

I don't know, because I keep my clients connected?  ;-)

Looking at the code, tds_write_packet() returns TDS_SUCCEED or TDS_FAIL.
No information is stashed in the TDSSOCKET about what's wrong.  I think
that's the OP's complaint: he can't discover what's going on.  (I don't
see even a log message, let alone anything being sent to the error
handler, btw.)  

The communication error messages, from doc/dblib_errors.txt:

Bad token from the server: Datastream processing out of sync.
DB-Library capabilities not accepted by the Server.
Unexpected capability type in CAPABILITY datastream. 392
Error in closing network connection.
Unable to connect: Adaptive Server is unavailable or does not exist.
Unsolicited event notification received.
Adaptive Server connection failed.
Negotiated login attempt failed.
Error in sending out-of-band data to the server.
Read from the server failed.
Unexpected EOF from the server.
Unable to open socket.
Read attempted while out of synchronization with Adaptive Server.
Unknown message-id in MSG datastream.
Unable to set communications timer.
Unrecognized TDS version received from the server.
Write to the server failed.

EXCOMM is described as "Failure in communication with Server -- the
DBPROCESS is dead."

When communication has been lost -- I'm not sure how we know when that
is -- I think the only thing to do is to set issue the error "Write to
the server failed" (differs by library) and set tds->state = TDS_DEAD.
That way the client libraries would know the TDSSOCKET is no good, and
should consistently refuse to use it.  

This is the reward for making timeouts work: now we have to tell the
client what's wrong, instead of just retrying forever!  

Of course, I'm just reasoning from the code and the documentation,
knowing, as an application programmer, how I'd like libsybdb to behave.
I'm not set up to test this with the vendors' libraries.  If someone
else would like to do that, I'm sure we'd learn something.  

HTH and regards, 

--jkl


-----------------------------------------
The information contained in this transmission may contain privileged and
confidential information 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.