Re: 2008 Data Types For DBLIB
"James K. Lowden" <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 28 Jul 2011 19:41:21 -0400 Ken Collins <[email protected]> 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