FreeTDS Development Group

[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
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds