timestamp data types (also DBLib Connections)
geoff at farmline.com
Mon Dec 13 11:05:31 EST 1999
Brian, firstly thanks (again!) for all your development work and for
responding (again!) so quickly...
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).
> 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.
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 &&
> return FALSE;
> 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.
More information about the FreeTDS