Skip to Content.
Sympa Menu

freetds - Re: [freetds] Character conversion (how to stop it)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Plot Lost <plot.lost AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Character conversion (how to stop it)
  • Date: Mon, 7 Dec 2009 10:55:08 +0400

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.




Archive powered by MHonArc 2.6.24.

Top of Page