FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> Freddy,
> 
> > I saw. I don't like dbtablecolinfo cause it's not a dblib 
> function but
> > an extension to ms and sybase libraries. Cannot this function be
> > implemented using dbcolinfo?
> 
> Alas no. dbcolinfo calls dbcoltype() and dbvarylen(). 
> Unfortunately the
> data returned by these functions does not allow the caller to 
> accurately
> determine the column type in order to construct a "create table"
> statement.
> Specifically, using these functions you cannot distinguish between the
> following column types:
> 
> CHAR(n) NULL
> 
> and
> 
> VARCHAR(n) [NOT] NULL
> 
> having run up against this issue, I tried to access the TDSCOLUMN
> information directly from my (otherwise db-library) program. 
> Doing this,
> I hit the same sort of issues as another poster last week. 
> I came to the conclusion that the addition of a freetds-specific
> dblibrary function was preferable to mixing dblibrary and tds-layer
> structures in the program.
> 
> I don't see why creating extra db-library functions should be  a bad
> thing, if they fill functional deficiencies in the existing dblibrary
> API, and do not compromise the behaviour of the existing functions.
> 
> Bill. 
> 

Ok. However dbtablecolinfo return information only from current result,
not taking into account cursors and/or compute results (as dbcolinfo
does). Another way to extend dbcolinfo is to add some fields at the end
of DBCOL defining a DBCOLFTDS (or whatever) and check SizeOfStruct
inside dbcolinfo. You could add for example if server type it's unicode,
real type or whatever. Or define others CI_* constants.

freddy77