WE8MSWIN1252 Does it supports Arabic?

Question

Hi All,
One of the strange facts which we saw recently was a 8i database running with WE8MSWIN1252 supporting Arabic characters successfully. Users were happy with the data representation in Forms 6i too. Though we have 100's of threads which says AR8ISO.. or AR8MSWIN... are the character sets which supports Arabic apart from UTF8. We were surprised to see how WE8MSWIN1252 was supporting Arabic characters. We came across a thread which said that it might be possible to have Arabic data stored with WE8MSWIN1252. Please refer to the following Link.
DB Migration from WE8MSWIN1252  TO AR8MSWIN1256  is it possible ???
Real Problem occured when we were asked to upgrade the DB to 10g. The problem started when we exported the dump from 8i and imported the same dump in a 10g i.e 10.2.0.1.0. database with same character set i.e WE8MSWIN1252. In 10g all arabic characters were showing as junk or inverted question mark when queried from db or while querying from forms application.
So we are planning to do the steps.
@ LIVE DB
1) Take a export of the existing dump from production 8i - 8.1.7.0
@ Test DB
1) Change the character set of DB to AR8MSWIN1256.
2) Import the Dump in Test DB
3) Check the data in back end and front end for its correctness.
4) If that works fine import that dump into 10g database with AR8MSWIN1256 character set
Will this work or if not please advice us for a right solution.
Thanks in advance.

Answer 1

As suggested by S. Wolicki in the mentioned thread I think you should first fix data in your current database in the current Oracle version and work with Oracle Support if needed to solve this case before doing any upgrade or export/import:
>
Now, to the solution. First, the database must be verified to contain data only in one charater set. That is, either all applications understand all data as WE8MSWIN1252 or all applications understand all data as AR8MSWIN12526. If some columns (or rows) contain data visible in applications as one character set and some other columns (or rows) contain data visible as another character set, such database cannot be easily migrated. Data must first be spooled to text files, separated as required and loaded back to a new database, usually in AL32UTF8 to cover all required languages/scripts. Both the verification and such special migrations are manual tasks.
Assuming the data in the database is consistent in respect to how it is visible to applications, the solution is to update the database character set declaration to the real one corresponding to the data. This should happen without actually touching any character codes. You need to contact Oracle Support to provide you with the correct procedure that uses an undocumented statement. (I guess you will find this statement in Google, but then you use it at your own risk!) Oracle Support should verify that the procedure will not corrupt your data.
>
Edited by: P. Forstmann on 14 déc. 2010 09:11