November 24, 2007
db2move import utf-8
Well it starts off as a simple export/import of an UTF-8 database from AIX to Windows. I have an UTF-8 database on an AIX box and I created a UTF-8 database on the windows to replicate the setup on AIX with
and did the following to export the schema and the data from the AIX box
db2move AMUTF export
and on the windows box did this to import it on my newly created UTF-8 DB.
db2move MYUTFDB IMPORT
Now comes the time for a 2 day long struggle to find out why the utf-8 data inside the tables are all messed up, and all I could see are characters looking like "–>–>". When i opened up the ixf file for the imported tables using Notepad++ Instead of seeing actual characters (ex: in Japanese) i could only find "SUB" (Hex: 1A1A). To keep the long story short this is what i used to solve the problem
db2 terminate
db2 force applications all
db2stop
db2start
I did this both on the AIX and Windows box.
The reason being, for some reason the db2move export on the AIX box, always exported the IXF files in the codepage 819 instead of 1208, eventhough my database was set to codepage 1208. Hence problem solved!
World Peace!
Comments(2)
I know this is old (and hope this gets to you) but what happened to the data on the AIX box once you did this? Was the UTF-8 data still readable or did it become garbled? I have the same issue with migrating from AIX to Linux. During db2move import on Linux, it “coverts” from 819 to 1208 making all my data look garbled.
I am worried about asking the admin of the AIX box to set it to 1208 just so I can have an successful import (we run the dev servers, someone runs the production servers). I am worried that the application running on the AIX will start corrupting data or display garbled text.
The UTF-8 data on the AIX box had no change (It didn’t corrupt the data), everything on it works fine. Even now I am still using the same DB on AIX after making the changes.