[freetds] [freetds-Patches-731907]Choosingdatalengthwhenbindingfixed types
James K. Lowden
jklowden at schemamania.org
Wed May 7 21:56:25 EDT 2003
On Wed, 7 May 2003 15:43:39 -0000, "Arnar Birgisson" <arnarb at oddi.is>
> > Hope that clears things up a bit. :-)
> It does indeed.. thanks.
> According to this though, is that tds_set_column_type should have
> checked to see if we're speaking tds 7+ and in that case map SYBVARCHAR
> to XSYBVARCHAR, and vice versa for lower versions of the protocol? Is
> there any reason to keep the ability to specify SYBVARCHAR (the old one)
> explicitly when talking tds 7+ ?
Things are slightly broken at the moment, for some value of "slightly".
Vendor docs both say that "SYBVARCHAR" is the constant that should be
passed to db-lib in e.g. dbconvert() and dbbind(). No mention is made of
"XSYBVARCHAR", and it's mere accident that your application found it
defined. We don't do as good a job as we should at limiting sybdb.h to
the set of symbols an application "deserves"; you get the whole of tds.h
in the bargain.
The upside is that you can get away with using XSYBVARCHAR for now. The
downside is that we've effectively make tds.h part of the public interface
to db-lib, even though that was never our intention.
In consequence, as we change tds.h, we really have to bump the .so number
of db-lib accordingly. We can't distinguish, you see, between
applications that stayed inside the boundaries of the real, vendor
defined, interface, and the one we exposed, so we force everyone to
At some point in the future, we should trim sybdb.h to something more
similar to what the vendors offer. We did that for ct-lib but never got
around to it with db-lib.
Before we do any trimming, though, I'm sure we'll properly map SYBVARCHAR
on the client to SYBVARCHAR/XSYBVARCHAR on the server.
Does that answer your question?
More information about the FreeTDS