2

I'm running a DB2 v10.5 FP 7 on a Windows Server 2013 and there is a problem with the encoding setup:

The windows is set to use German(Switzerland) as region setting and input language.

chcp: Active code page: 850

My database is set to UTF-8, see this output from db2 get cfg

 Datenbankgebiet = CH
 Codepage für Datenbank = 1208
 Codierter Zeichensatz der Datenbank = UTF-8
 Landescode der Datenbank = 41
 Sortierfolge der Datenbank = SYSTEM_1252
 Alternative Sortierfolge (ALT_COLLATE)  = 

UTF-8 Strings with umlauts are stored correctly in the database (checked by looking at the effective hex-values). However on retrieval, they are mixed up: db2 CLI output

The correct value would be '87100 - Überbauung Hinterroos'. Notice how also the default db2 output is shown as 'Sõtze' instead of 'Sätze'.

The incorrect output can also be reproduced by selecting the same rows via JDBC/Java.

IBM Documentation says this behaviour is linked to the DB2CODEPAGE registry variable, which is not set explicitly on the server.

Any ideas how to fix this?

EDIT: (More info as requested by @mao):

The windows default code page is 850 too. In the registry, codepages are as follows:

  • ACP 1252
  • OEMCP 850
  • MACCP 10000

To make sure I'm not following any wrong leads, I verified the stored string in the table by SELECT HEX(DISPLAY_NAME)... which outputs

3837313030202D20C39C626572626175756E672048696E746572726F6F73

The letter with umlaut is 0xC39C which is CAPITAL LETTER U WITH DIARESIS

Setting the DB2CODEPAGE variable to 1208 changes the output to a different wrong output: CLI output 2

  • @mustaccio that's the first thing I tried, i used the commands like mao suggested, in that order. This didn't change anything perceivable for me – tannerli May 15 '18 at 7:15
2

After opening a support case with IBM, they gave me the clue that lead to a solution:

-> Could you first right click in the title bar of the Command Window and take "Properties".

Is it using a TrueType font for displaying characters?

As it turns out, changing the font (wtf?) changes the display of said characters.

This is some specific behaviour for the DB2 CLI window: Opening a regular cmd with a non TrueType font works as expected.

0

codepage 850 is a fixed-width and legacy 8-bit character set. For many, codepage 1252 replaced codepage 850.

Does it make a difference in the Db2-CLP if you try codepage 1252 instead of 850 like this:

db2 connect reset
db2 terminate
chcp 1252
db2 connect to ....
db2 "select ..."

Is your "system default" codepage on Windows the same as codepage 850 ? Double check this in Windows regional settings and/or registry. Java/jdbc is also sensitive to the system default setting.

Explicitly setting Windows environment variable DB2CODEPAGE to 1208 can sometimes help, but it can also have unexpected consequences, so careful testing is required.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.