FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Hi Sebastien, 

> When I print the client and the server charset in tds_convert_string()
> called from tds_put_data(), I see:
> 
>    char_conv->client_charset.name = "UTF-8"
>    char_conv->server_charset.name = "CP1252"
> 
> I expected UCS-2 for the server charset...????
> 
> Hence it's normal that the conversion of non-CP1252 compatible chars
> like é´» result in error...

That's OK.  I think you misunderstand the meaning of
client2server_chardata: "server_chardata" is the server's single-byte
encoding, used for char/varchar/text columns.  The server announces its
encoding as a message immediately after logon.  

(Off the top of my head, I can't think why we care about the server's
single-byte encoding.  Maybe for TDS 4.2.  TDS 7+ uses UCS-2; we never
send the server anything else IIRC.) 

As I said yesterday, CP1252 could explain your 2-byte/3-byte observation. 


First assertion: in unprefixed strings, *only* characters represented by
CP1252 will be stored correctly on your server.  All others will be
converted to CP1252 first by the server, with varying results.  Pick *any*
non-CP1252 character and see what happens.  

Second assertion: all prefixed strings embedded in SQL text will be
handled correctly on both ends.  

Final assertion: parameterized query buffers are not correctly converted
when sent to the server.  

That's where I think we are.  Agreed?  

Regards, 

--jkl