FreeTDS Development Group

[Plot Lost <plot.lost AT gmail.com>]

On Sun, Dec 6, 2009 at 2:01 AM, James K. Lowden <jklowden AT freetds.org>wrote:
> The design intention: if the client and server have the same encoding,
> iconv doesn't engage.  If you find a case where that's not true, it would
> be considered a bug.
>
> For your purpose, that means setting the client to UCS-2LE.  The
> difficulty will likely be that you'll be on a weedy path, because no one's
> really done very much with UCS-2 clients.  Frediano has an interest in it
> for ODBC.  db-lib has some built-in restrictions that would require
> deviation from specified behavior in order to make UCS-2 work (and I have
> no particular use for that kind of extension).

> That leaves ct-lib, about which I don't know much.  From your description,
> it sounds like ct-lib's design handles UCS-2 fine.  From there, it's just
> a matter of implementation....
>
> HTH.
>
> --jkl
>
Problem is that then results in 8-bit strings being converted up to UCS2,
which is also not wanted.

I need something that just tells freetds to not convert anything regardless
of any character set, so that 8-bit char sets are left as 8-bit char sets,
and 16 bit ones left as 16 bit - with the appropriate datatype being
returned by ct_describe (e.g. CS_VARCHAR_TYPE and CS_UNICHAR_TYPE)

This is all being done using ct_lib, and works a described when using sybase
ct_lib.

Nothing I have been able to do allows this to happen, so it looks like
freetds is just not going to be an option for us (which is a shame, it would
of been nice to be able to use it and give freetds support as an option)

Thanks.