FreeTDS Development Group

["Geoff Winkless" <geoff AT farmline.com>]

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 &&
>     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.

Thanks again

Geoff