Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Extended Characters
In this specific case, the original poster was talking about Microsoft
extended characters, which will almost certainly cause a problem.
Anything outside the 7-bit ASCII set that almost every character set is
a superset of will cause a problem.
Are you talking about the character set scanner? That will tell you whether any of your existing data is incorrect (i.e. Chinese data in a US7SASCII database), but I'm not aware of any option to tell you whether the data would be valid in some other character set.
You can force the conversion by adding the INTERNAL_USE clause to the ALTER DATABASE statement, but I would tend to view that as a last ditch solution when every other option is exhausted and only if you really, really, really understand what it is doing under the covers (and then only after exhaustive testing and a well-tested backup & recovery plan).
Justin Cave
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of
Jared.Still_at_radisys.com
Sent: Tuesday, April 13, 2004 5:45 PM
To: oracle-l_at_freelists.org
Subject: RE: Extended Characters
Since AL32UTF8 is not a strict
binary superset of WE8DEC, I believe a full export & import would be
necessary.
Not necessarily. There is a utility to run (forgot the name) to scan your database for characters that will be incompatible with the new character set. If none are found, you can force the character set conversion.
Testing on a throwaway clone DB would be a good idea.
Making a backup would probably also be a good idea.
A search of MetaLink will turn up the relevant docs.
Jared
![]() |
![]() |