freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Frediano Ziglio <freddy77 AT gmail.com>
- To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] Determining column type
- Date: Fri, 25 Nov 2011 15:41:19 +0100
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 <steve.teale AT britseyeview.com>:
> 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
>>
-
Re: [freetds] Determining column type
, (continued)
-
Re: [freetds] Determining column type,
James K. Lowden, 11/23/2011
-
Re: [freetds] Determining column type,
Steve Teale, 11/24/2011
-
Re: [freetds] Determining column type,
James K. Lowden, 11/29/2011
- Re: [freetds] Determining column type, Steve Teale, 11/29/2011
-
Re: [freetds] Determining column type,
Andrew H. Wakefield, 11/29/2011
-
Re: [freetds] Determining column type,
Steve Teale, 11/29/2011
-
Re: [freetds] Determining column type,
Konrad J Hambrick, 11/29/2011
- Re: [freetds] Determining column type, James K. Lowden, 11/29/2011
-
Re: [freetds] Determining column type,
Konrad J Hambrick, 11/29/2011
-
Re: [freetds] Determining column type,
Steve Teale, 11/29/2011
-
Re: [freetds] Determining column type,
James K. Lowden, 11/29/2011
-
Re: [freetds] Determining column type,
Steve Teale, 11/24/2011
-
Re: [freetds] Determining column type,
Ken Collins, 11/24/2011
-
Re: [freetds] Determining column type,
Steve Teale, 11/24/2011
-
Re: [freetds] Determining column type,
Frediano Ziglio, 11/25/2011
- Re: [freetds] Determining column type, Steve Teale, 11/26/2011
- Re: [freetds] Determining column type, Steve Teale, 11/26/2011
-
Re: [freetds] Determining column type,
Frediano Ziglio, 11/25/2011
-
Re: [freetds] Determining column type,
Steve Teale, 11/24/2011
- Re: [freetds] Determining column type, Konrad J Hambrick, 11/24/2011
-
Re: [freetds] Determining column type,
James K. Lowden, 11/23/2011
Archive powered by MHonArc 2.6.24.