Well, the trick is that a database can only specify which "locale" it is used for at creation time. When you create a database you either specify what you want by specifying the codeset, territory and collation (example
CREATE DATABASE MYDB AUTOMATIC STORAGE YES ON '/data' DBPATH ON '/dbdir' USING CODESET UTF-8 TERRITORY US COLLATE USING SYSTEM), or you let DB2 guess based on some system settings.
You can check what yours is set to by running
db2 get db cfg for <db name>. In the case of what was used above you would see the following:
Database territory = US
Database code page = 1208
Database code set = UTF-8
Database country/region code = 1
Database collating sequence = IDENTITY
Alternate collating sequence (ALT_COLLATE) =
Note, that you cannot change these settings after a database is created. One option would be to export the data from your database (using
db2export), drop and rebuild the database the with language settings you want, and then re-import the data (using
Another option would be to see if there is a way to represent your character strings as pure "bit" data and store the bit sequence rather than the "string" or declare a field as
VARCHAR FOR BIT DATA and store your strings as bit sequences (though I'm not 100% positive on that one...).
Also check out the links below as they have more information on the language thing and how to deal with multi-code-page results. Note that some of this information requires DB2 to be at least at version 9.5 or higher.
as well as check out the whole Multicultural support parent/sibling links related to that list link (the Character conversion between different code pages).