[freetds] [freetds-Patches-731907]Choosingdatalengthwhenbindi ngfixed types

Lowden, James K LowdenJK at bernstein.com
Wed May 7 11:15:34 EDT 2003


> From: Arnar Birgisson [mailto:arnarb at oddi.is]
> Sent: May 6, 2003 8:31 AM
> 
> I don't know the code enough, but could someone explain to me why it's
> neccessary to map XSYBVARCHAR to SYBVARCHAR, at least for tds 
> 7 and up.

It's just a matter of terminology and definitions.  

You define your parameter as "varchar".  You know that "varchar" has a limit
of 255 characters under Sybase and pre-7 Microsoft servers, and 8000 bytes
otherwise.  As far as the server's concerned, those are two different
datatypes, but you're not required (nor able) to distinguish them.  

The newer servers still accept the old datatype because they still
communicate with old clients.  What they don't accept is an old datatype
trying to shove in more data than its defined maximum size, which would
obviously be bogus.  Hence the error.  

Inside libtds, we see your varchar and know what protocol version we're
using, so we know your intentions.  Or can know, at any rate.  What you
stumbled on is that we reduced the new type to the old one (its "cardinal
type").  

Our philosophy is that the client doesn't know and doesn't care about the
TDS version.  The application is just trying to communicate with the server,
subject to what it knows as the server's limitations.  Any protocol magic
the library has to do to make that happen is our business.  That philosophy
is manifested in the design decision to push all protocol distinctions into
libtds; not even the client libraries need be involved.  You may find some
exceptions to that approach in the code, but I think everyone would say
they're warts, not gems.  

Hope that clears things up a bit.  :-)

--jkl





The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.





More information about the FreeTDS mailing list