Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Storing multilingual characters in Oracle
We had tons of problems with al32utf8 character set. Some applications
won't work with this character set. When we imported the data from our
production database to our 9i database created with al32utf8 lots or
records were not imported.
We ended up recreating our 9i database with WE8ISO8859P1 and UTF8 and we haven't had any problems anymore.
PARAMETER VALUE
------------------------------ --------------
NLS_NCHAR_CHARACTERSET UTF8 NLS_CHARACTERSET WE8ISO8859P1
We have another 9i database with the default character set. But, as I said before some of our application won't run here.
PARAMETER VALUE
--------------------------------------------------------------------------------
NLS_NCHAR_CHARACTERSET AL16UTF16 NLS_CHARACTERSET AL32UTF8
Thanks
Ana E. Choto
American University
e-Operations - Information Technology
Phone (202) 885-2275
Fax (202) 885-2224
Sandeep Dubey <dubey.sandeep_at_gm ail.com> To Sent by: oracle-l_at_freelists.org oracle-l-bounce_at_f cc reelists.org Subject Storing multilingual characters in 04/29/2005 09:31 Oracle AM Please respond to dubey.sandeep_at_gma il.com
Our database currently storing english characters now needs to store lanaguages like chinese, korean and Japanese. NLS_CHARACTERSET is currently WE8ISO8859P1. I need to store multilingual characters in approximately 20% of the tables. There are three options:
Are there any known issues of using Nchar on Oracle 9.2.0.4? I found on a metalink note recommending NOT to use nchar and rather change character set. Anyone has any bad experience with Nchar/Nvarchar2?
Is WE8ISO8859P1 a strict subset of AL32UTF8?=20
Or Option 3 is the best way to go. I am trying to avoid this option because of outage time I have to take for export and import.
Please share your experience.
Regards,
Sandeep Dubey
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Apr 29 2005 - 10:37:35 CDT