FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

On 12/13/99, ""Geoff Winkless" <geoff AT farmline.com>" wrote:
> Brian, firstly thanks (again!) for all your development work and for
> responding (again!) so quickly...
> 
Why, thank you!

> Brian Bruns writes:
> > A good place to start would be to set a breakpoint in
> > tds_process_col_info() or tds7_process_results() (for 4.2 and 7.0
> > respectively) and see what the datatype is that is returned from the
> > server (should be SYBBINARY).
> 
> 45, so yes, SYBBINARY.
> 
> >  The -1 comes from a routine called either
> > tds_get_conversion_type() or _ct_get_server_type()
> 
> _ct_get_server_type() gets called with a value which seems to vary wildly
> (1095, 11197, 1073818557...) and returns -1 (no match).
> 
Ok, then it is probably something in ct_describe(), sqsh calls this to 
figure out a few things...it is probably giving sqsh the bad value (or sqsh 
is making it up...but i doubt that :-) )

> > set a break there and
> > determine what type is trying to be converted from/to.  This will be the
> > bind_type, such as CS_CHAR_TYPE as opposed to the server datatype SYBCHAR.
> > (CHAR types used as examples, not what you should actually see).  From
> > there it may be as simple as adding a case statement to
> > _ct_get_server_type() or if this is TDS 7.0 and MS put a whole new
> > datatype in, implementing that.
interesting.  When you tried it on Sybase did you use 4.2 or 5.0?  (I'm 
hoping 5.0, since I should be able to track it down easily then...)
 
> Nope, it's TDS4.2.
>
> > SQSH calls convert for each datatype just to check things out and decide
> > whether to use the convert functions or do it itself.  Never did quite
> > understand that.
> 
> Called within ct_fetch, _ct_bind_data
> 
> > DBDEAD() should be used to test the connections validity. However (there's
> > always a but...) our implementation is suboptimal.  it should look
> > something like:
> >
> > if (dbproc &&
> >     dbproc->tds_socket &&
> >     dbproc->tds_socket->s)
> > return FALSE;
> > else
> > return TRUE;
> 
> Does this actually check the connection or just see if it was working in the
> last call? The point being that I need a way of telling if the connection
> has died (eg server reboot etc)
> 
> > I'll fix it up and check it in a bit. I'm not sure why I never got
> > around to implementing it beyond the stub...probably 'cause no one ever
> > asked about it. :-)
> 
> Heh. Usually the way.
> 
There is no way to detect a dead connection unless a read is attempted.  
So, yes, in order for this to return a proper value some call must have 
been issued that will do a read (such as dbresults(), dbnextrow(), etc...). 
OTOH, FreeTDS lets you get to the file descriptor directly 
(dbproc->tds_socket->s) so you can perform whatever calls you want on that 
to determine its state.  This is not portable to Sybase/MS dblib however.

> Thanks again
> 
> Geoff


Cheers,

Brian