FreeTDS Development Group

["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