FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2011/8/3 James K. Lowden <jklowden AT freetds.org>:
> On Thu, 28 Jul 2011 19:41:21 -0400
> Ken Collins <ken AT metaskills.net> wrote:
>
>> > It's not a db-lib issue.  It's a protocol issue: unless the client
>> > defines itself as using TDS 7.3, the server returns those types as
>> > varchar strings.  The client never sees tbem in binary form.
>>
>> That's fine. I can parse the strings and do something meaningful for
>> the time being, but I can not find a way to get the column type. For
>> instance, the dbprtype() just returns "char" for these columns and
>> dbcolutype() just returns 0/null. Any work arounds for a DBLIB
>> interface to get something back like "datetime2" for the column name
>> or something that let's me switch and parse the varchar string?
>
> The db-lib functions return to the application information in the
> client's possession; they do not interrogate the server.  Consequently,
> if the server transmits type A as type X, db-lib reports type X,
> irrespective of what one may find in sys.columns.
>
> That is absolutely the right answer for db-lib: the application needs
> to know what it in the library's buffers, not what is in the system
> catalog.
>
> One is always free to interrogate the catalog independently, or to cast
> the data to another type in SQL.  Unfortunately, though, the TDS
> protocol does not include explicit information tying the metadata of a
> result set to the catalog.  Consequently there is no systematic
> solution to do what you want.  :-(
>
> --jkl

I think that many people are asking some extension to dblib ABI in
order to support new types and so on.. a sort of "FreeTDS extensions".

Frediano