Skip to Content.
Sympa Menu

freetds - Re: [freetds] Cant's select columns with umlaute

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Frediano Ziglio" <freddy77 AT gmail.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Cant's select columns with umlaute
  • Date: Tue, 9 Dec 2008 17:08:53 +0100

2008/12/9 James K. Lowden <jklowden AT freetds.org>:
> Michael Schodra wrote:
>>
>> I try to established a DB-Link from Oracle 11g to a MSSQL 2000 database
>> but it doesn't work.
>>
>> We install on Centos 5.1 (Linux 64bit).
>> Our database is Oracle 11.1.0.6.0 plus bugfix 7389110 and we installed
>> the "linux.x64_11gR1_gateways". I configured freetds and uinixodbc (see
>> below)
>>
>> I already told the unixodb folk about the problem, but they told me: ask
>> the freetds folk. So I do now and I hope you can help me?
>>
>> Here is my configuration and the problem.
>>
>>
>> 1. unixODBC (unixODBC-2.2.11)
>> 1.1 /etc/freetds.conf
>> combandb <http://forums.oracle.com/forums/>
>> host = 212.xxx.xxx.5
>> port = 1433
>> tds version = 8.0
>>
>> Client Charset = UTF-8
> ...
>> UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'
>
> 1. When the umlauted character is passed to SQLPrepare, is it in fact
> encoded as UTF-8, or is it possibly ISO 8859-1? What is your intention?
>
> 2. What is the output of "tsql -C"? When you connect with tsql, what
> encoding does it report?
>
>> SQL = select ID, Ort, Straße from x_lt; length = 62 (SQL_NTS)
>
> 62? There are 32 characters. Evidently, 31 were converted to UCS-2,
> giving a length of 62 = 2 * 31.
>

Probably Oracle call SQLPrepareW (wide version)

>
> I suspect the 'ß' cannot be converted to UCS-2 because iconv(3) is
> presented with input (your SQL text) that is not encoded in the character
> set it was told to expect. The 'ß' for example is 0xE1 in 8859-1, which
> is not a valid value in UTF-8. The UTF-8 sequence is c3 a1 (both of
> which are valid 8859-1 characters).
>

by default (I don't know how to change this behavior) unixODBC convert
UCS-2 using ISO8859-1 but FreeTDS assume UTF-8 so you get error
preparing.

> Because the 'ß' encoded as ISO 8859-1 cannot be interpreted as UTF-8 --
> but could be interpreted, albeit incorrectly, as ISO-8859 if encoded as
> UTF-8 -- I suspect that FreeTDS is responding to your freetds.conf entry
> above. It expects UTF-8, but its input is actually ISO 8859-1.
>
> The solution is match what FreeTDS expects to what it's given. Either
> change your locale(1) settings to use UTF-8 (so that what you type at the
> terminal arrives as UTF-8) or tell FreeTDS to expect ISO 8859-1. The
> latter could be done by simply removing the "client charset" line from
> freetds.conf.
>

I think this can work with this particular configuration.

> You can verify the above with a TDSDUMP log. It will show your SQL text
> as a hex dump, and at the top of the file it reports what encodings it's
> using. You should also see errors from tds_iconv about inabilty to
> convert characters to be sent to the server.
>
>> Isql> select * from x_lt
>>
>> Works well, but umlaute are missing.
>
> When sending to the server, data encoding conversion errors result in an
> error and the function fails. When fetching data from the server, data
> encoding conversion errors result in a warning, which your client tool
> seems not to report.
>
> HTH.
>
> --jkl

freddy77

PS: I have still to finish coding wide characters support for
SQLBindParameter/SQLBindCol/SQLGetData/SQLPutData (well.. only
SQLPutData is partially working, others works quite well)... for wide
functions (like SQLPrepareW) there is no plan at all...



Archive powered by MHonArc 2.6.24.

Top of Page