FreeTDS Development Group

[Steve Teale <steve.teale AT britseyeview.com>]

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().

My objective is to automate _simple_ binding to an array of Variant type
objects (this is in D, with the D library implementation of Variant). In
the cases of the well-established SQL data types, this is
straightforward. After SQLExecute*(), I can get the number of columns in
the result set, then call SQLDescribeCol() for each. When I know the
type, I can initialize a Variant to the appropriate D type (bool, byte,
int, long, char[], byte[], SQL_TIME_STRUCT and so on), and get a pointer
to the Variant's buffer. I can get the maximum length from the column
description, or the D type, I can create a parallel array of int to
receive the strlen/ind information, then I am in a position to call
SQLBindCol(), and then hopefully good to call SQLFetch().

More complex bindings - as for instance when some chunked transfer was
required, or there was some specialized type conversion to be done,
would be dealt with by adding qualifications to the bindings - only as
and when required.

My problem is in determining the type. SQLDescribeCol() tells you the
type that you will get in the pending query results, as does
SQLColAttribute().

I suppose that I could query the column name, and then use some sort of
t-sql query to get the attributes of a column in that table outside the
context of the statement handle. But I'd probably have to do that in a
separate thread with a different connection, and in any case it seems
incredibly complex to accomplish something that should be quite simple.

As noted in a previous post, the column types causing the problem are
BIGINT, TIME, and DATE. For example if I have a table with columns
(FLOAT, BIGINT, VARCHAR, DATE, TIME), then the list of types that I get
through SQLColAttribute(hstmt, SQL_DESC_TYPE_NAME, ...) in protocol
version 7.2 will be (float, float, varchar, varchar, varchar) - which in
the context of what I want to do is not that helpful.

I have a feeling that there might be one or more of the SQL_DESC_XXX
column attributes that might allow me to further analyze the type, but
so far any combination has eluded me.

Thanks
Steve