FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2010/4/19  <jklowden AT schemamania.org>:
> On Mon, Apr 19, 2010 at 11:00:05PM +0200, Frediano Ziglio wrote:
>> Il giorno lun, 19/04/2010 alle 12.04 -0400, jklowden AT schemamania.org ha
>> scritto:
>> > > > ??  For db-lib connections, the server converts varchar(max) to TEXT 
>> > > > (type 35).  Then the db-lib API can deal with it either by binding 
>> > > > it as a string or with dbmoretext().
>> > >
>> > > Yes, this is true with MS dblib cause MS dblib use only protocol 4.2. 
>> > > We
>> > > support protocol up to 7.1 under dblib :)
>>
>> Yes, cause you are using protocol 7.1 which does not support
>> varchar(max) so this type is returned as text :)
>> Protocol 7.2 support varchar(max) with different byte encoding.
>
> I see, finally.  I found this code in tds_connect_and_login():
>
>        /* disable tds9 if iconv wanted, currently not supported */
>        if (IS_TDS72(connection) && tds->use_iconv)
>                connection->tds_version = 0x701;
>
> So, no matter how I set TDSVER, I never get more than 7.1.  :-(
>

Yes, this code cause token.c code for varchar(max) does not convert so
upper library have to. But if dblib would support conversion the
problem would be text... protocol 7.2 send empty textptr for text
fields (don't ask me why... I think that long-term design is the
complete removal of textptr so to be able to store LOBs in main db
pages) so functions like dbmoretext won't work.

> I've come to understand that client encoding is properly a binding step: 
> the library should always keep an original as-received copy of the data, 
> and only when asked to convert to a "string" does it need to consult iconv. 
>  That's the only way to support binary bindings, and the best way to 
> support UTF-16 on a TDS 7+ connection.
>
> Not easy to fix, though.
>

Mmmm.... are you speaking about binary bindings in dblib ?? Currently
odbc works this way. Another way is to convert utf-16 to "normal"
characters directly in token.c (like (N)TEXT and normal (N)VARCHAR)
but there is no function to convert in a chunked way and after
discovering text problem with protocol 7.2 I just decided to limit
ctlib/dblib protocol to 7.1. dblib won't never support stuff like MARS
and UDT for .NET objects so there is no improves adding support for
7.2... perhaps it would be helpful to add support for ctlib, I don't
know.

freddy77