timestamp data types (also DBLib Connections)

Brian Bruns camber at ais.org
Mon Dec 13 14:08:07 EST 1999

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



More information about the FreeTDS mailing list