FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

One possibility is to split the processing of the login ack stream
from the tds_connect() function.  Seems to me the processing loop used to
be separate from the connection stuff, not sure why it was folded in
together. It breaks the libtds API, so dblib,ctlib, and ODBC will all have
to be touched, but we never claimed the libtds api was fixed, in fact
we've been pretty clear we will change it when circumstances dictate.

So you would have...

1. tds_connect()
2. check to see if the physical connection worked
3. set the parent and any other bookeeping
4. process the login acknowledgement
5. free tds_socket if login failed

I kind of like this because it would give a hook where the 
connect() failed so we could generate a more intelligent client error
message with the OS error (Connection refused, bad host, timeout,
whatever).  That would save a lot of questions on this list. ;-)

Anyway, I can't think of any solution that doesn't break the libtds API or
violate either dblib's or ctlib's API.

Brian

On Thu, 30 Aug 2001, Mark J. Lilback wrote:

> Error handlers are never called when a login fails using dblib (with
> TDS 4.2, but it looks like the same thing would happen with other
> versions).
> 
> tds_process_msg only calls the global error/message handler if
> tds->parent is set. But dbopen doesn't set the parent until after
> tds_connect is called, which is where the error happens.
> 
> Also, while looking at this problem, I noticed another problem.
> dbopen allocates memory for a dbproc structure, but if tds_connect
> fails, it just returns NULL, leaking the memory.
> 
> That's an easy fix, but I'm not sure what to do about the error
> message problem.  And that is something that has to get fixed --
> users need an explanation of why the login failed.
> 
> Any ideas on how to creatively work around this?
> 
> I can't think of an easy way to do this within the current API, and
> I'd prefer to find a solution that does so. (I don't mind hacking my
> own solution for my app, but I'd prefer a global solution.)
> 
>