Skip to Content.
Sympa Menu

freetds - Re: [freetds] Character conversion errorwithspecialcharacters(umlauts)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Stefan Axelsson" <Stefan.Axelsson AT ltkalmar.se>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Character conversion errorwithspecialcharacters(umlauts)
  • Date: Tue, 22 Jul 2008 10:51:16 +0200



>-----Ursprungligt meddelande-----
>Från: freetds-bounces AT lists.ibiblio.org
>[mailto:freetds-bounces AT lists.ibiblio.org] För James K. Lowden
>Skickat: den 21 juli 2008 16:45
>Till: FreeTDS Development Group
>Ämne: Re: [freetds] Character conversion errorwithspecialcharacters(umlauts)
>
>Stefan Axelsson wrote:
>>
>> Just tested something else, as I realized I hadn't. isql lets me
>> update the records with åäö in them just fine. Checking on the server
>> and the updated data is as it should be. Getting the records back
>> through isql (SELECT * FROM tablename) works fine. Using my Perl-script
>> returns ?
>> Where the åäö should be.
>>
>> Unfortunately I'm still rather confused about what talks to what, and
>> how. And I'm even more in the dark when it comes to how to track what
>> happens step-by-step. All I've gotten to work so far is the logging I
>> can enable in odbcinst.ini-file. So if you, or anyone else, have any
>> ideas, hints, tricks...do tell. I'd so prefere to solve this and not
>> just install some other distro/port to Windows.
>
>Ledsen att säga, det är inte enkelt. :-(
>
>The server announces its encoding during the login sequence. For non-UCS2
>columns, the encoding is set by server or database defaults, or (in SQL
>Server >200[05]) by column. sp_helpsort should show you yours (although I
>think you know yours already).
>
>The client's encoding is determined first by the locale. It can be
>overridden in freetds.conf. To use the override feature for an ODBC
>connection, you >must cause the ODBC driver to read freetds.conf. To do
>that, use the "Servername" (not "server") property in the DSN entry, naming
>the section in
>freetds.conf where the encoding ("client charset") is specified. (I think
>you could set the client charset in the "[global]"
>section, instead, if you prefer.)
>
>As long as both encodings can represent all the characters you need, you're
>OK. It is not necessary to use USC-2 on the server. It is necessary only
>that the intersection of the two encodings satisfies your requirements.
>
>Now, who's the "client" here? You're running a webserver producing HTML,
>normally encoded as UTF-8. And you seem to want UTF-8. So I think you want
>either to set your locale to UTF-8 or use and ODBC-Combined configuration to
>take advantage of the freetds.conf override feature.
>
>HTH. I can provide more if you need it. Ta det lungt.
>
>--jkl

Det var enkelt, tackar. :)

And for the non-swedes (or atleast, swedish speaking). It worked like a
charm. I just changed "server" to "servername", restarted Apache (was quite
sure that wasn't realy an issue, but better safe than sorry) and it worked
flawlessly right away. Sure, had to add a HTTP tag to use UTF-8 for the page
in the browser, but that was just one line in one includefile.

So thanks for the help, my boss seems much happier now too. :) Guess I owe
you a beer, a coffee or whatever if we would ever run into eachother in RL.

Many thanks!
Stefan




Archive powered by MHonArc 2.6.24.

Top of Page