Skip to Content.
Sympa Menu

freetds - Re: [freetds] sqsh & freetds

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] sqsh & freetds
  • Date: Wed, 19 Sep 2007 12:17:26 -0400

Patrick Welche wrote:
>
> It seems the blk_alloc() page of that manual has some explanation of
> BLK_VERSION_* but it isn't clear what the differences are nor whether
> they matter!

This for sure: to FreeTDS, it doesn't matter.

The manual says the value is "checked for compatibility" with the ct-lib
version level. A quick look at src/ctlib/blk.c::blk_alloc() shows the
argument isn't checked or used.

It's easy enough to see why the argument is there: to allow the
application to make the assertion, "I expect behavior consistent with
version X". If it happens to be linked with an old library, the function
can fail and say, "I'm only version X - 2 and don't know what you'd
expect, goodbye." (Also, as entropy points out, a later-version library
can disable features for earlier-version assertions.)

FreeTDS doesn't do much to manipulate TDS 5.0 capabilities. If you ask
for a bulk copy operation that wasn't available once upon a time and is
now, you'll get it. E.g, if your program was designed for a 255-character
limit and the table now has a wider column and the protocol now supports
it, you'll get the full width and, if you're not careful, you'll overrun
your buffer.

To honor the limits and emulate the behavior of Sybase's implementation
for this parameter, we would need documentation. I'm not aware of any.
:-(

Regards,

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page