Re: Determining column type

Mumble mumble.

Personally I would check why BIGINT does not return a BIGINT...
Currently FreeTDS does NOT support protocol 7.3 (CVS version should),
that is DATE/TIME/DATETIME2/DATETIMEOFFSET are returned (at WIRE
level) as varchar. But configuring TDS protocol to 7.1 or 7.2 server
return BIGINT as... BIGINT!

Frediano

2011/11/24 Steve Teale <[email protected]>:
> Ken,
>
> So in other words I should parse the SQL at the client side, or build it
> there, which amounts to the same thing. Yes, that's one way to go, but
> for a long time it's then going to be full of bugs because of the many
> dialect differences in ODBC.
>
> There's a SQL server on the box next to me that knows how to parse its
> dialect of SQL. Why should I not expect it to share the information it
> gleans with me.
>
> As it turns out, if I build the same test app under Windows, with the
> Native Client driver, it gives me the information I need. I had been
> blaming the server, but it appears that the driver may be the culprit,
> with at least one data type that was introduced in SQL Server 2000.
>
> Steve
>
> On Thu, 2011-11-24 at 09:21 -0500, Ken Collins wrote:
>> > Can you think of any way that I can get SQL Server 2008 R2 to report the
>> > as-defined-in-table column type in the context of a just-executed
>> > SQLExecute() or SQLExecuteDirect().
>>
>> Seems to me that this should not be a concern of a protocol library like FreeTDS but some other higher framework like an ORM, ActiveRecord, CoreData, etc. Like those frameworks, the manage schema information at another layer either thru some object model or with schema reflection. Then as SQL is build there is all the information needed to knit things together.
>>
>>  - Ken
>>
_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds