Re: Character conversion (how to stop it)

Plot Lost <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
On Sun, Dec 6, 2009 at 2:01 AM, James K. Lowden <[email protected]>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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.