Skip to Content.
Sympa Menu

freetds - Re: timestamp data types (also DBLib Connections)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Brian Bruns" <camber AT ais.org>
  • To: freetds
  • Subject: Re: timestamp data types (also DBLib Connections)
  • Date: Mon, 13 Dec 1999 14:8:7


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




Archive powered by MHonArc 2.6.24.

Top of Page