[freetds] patch for new application program
ZIGLIO, Frediano, VF-IT
Frediano.Ziglio at vodafone.com
Tue Nov 16 07:57:29 EST 2004
> > 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
> determine the column type in order to construct a "create table"
> Specifically, using these functions you cannot distinguish between the
> following column types:
> CHAR(n) NULL
> 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.
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.
More information about the FreeTDS