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.