This content has been marked as final. Show 4 replies
Assuming you are using a non-express version of 10g, you'll want to look through the chapter on character set migration in the Globalization Support Guide. Assuming that the character set scanner gives you a clean bill of health, the CSALTER script should be able to change the database character set without too many headaches.
Of course, you'll need to ensure that your client NLS_LANG settings are correct (which they should be regardless of the setting, but is worth verifying as part of this general process).
Actually, I should add that if you're considering changing the database character set, my general recommendation is that you move to a Unicode character set (AL32UTF8) to give yourself maximum flexibility in the future. If you want to support some other languages in the future that aren't part of the Windows-1252 character set, changing from Windows-1252 to Unicode is going to be substantially harder than changing now from US7ASCII to UTF-8.
Message was edited by:
check note: 227330.1
I think for this particular requirement you should be able to use the SQL NCHAR (i.e. NCHAR, NVARCHAR2 etc. in Oracle) datatypes, which is exclusively Unicode, provides a flexible alternative for multilingual support
While Unicode may seem like the logical choice for any database, the decision to use it needs to be weighed carefully. There are performance and space usage penalties associated with using Unicode. If a smaller code set is available that encompasses all of the languages you are likely to ever need, then the overhead of Unicode makes it an illogical choice.
Some character sets support multiple languages because they have related writing systems or scripts. For example, the WE8ISO8859P1 Oracle character set supports the following Western European languages:
When a database is created, two session-independent NLS (National Language Support) parameters are specified: the Database character set and the national character set
The database character set defines the character set that will govern default text storage in the database. This includes all CHAR , VARCHAR2 , LONG , and fixed-width CLOB data as well as all SQL and PL/SQL text.
The national character set is an alternate Unicode character set that governs NCHAR , NVARCHAR2 , and NCLOB data.
Two things must be true in order to classify a character set as a strict superset of another:
• The superset must contain all of the characters defined in the subset.
• The encoded values of all characters defined in the subset must match their encoded values in the superset.
If your database is not too big, I recommend you to recreate an empty database with the above nls character set and than reimport the data, so the french accent will be stored, or verify if the WE8ISO8859P1 si superset of your curent database character set, is true, you can dynamically change your database character set without any migration.
Hope my info helps