Re: Extended Characters

  • From: Tim Johnston <tjohnston@xxxxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Tue, 13 Apr 2004 20:14:05 -0400

Justin Cave (DDBC) wrote:

>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).
>  
>
Well...  One of the quick and dirty things you can do this... Run the csscan 
utility with a destination characterset of US7ASCII...  Just because they are 
using the WE8DEC characterset does not mean they are putting anything other 
then US7ASCII characters into it...  

Here is the scenario that could work:

Run csscan with a destination characterset of US7ASCII
Examine the reports produced and see where you would have problems

Now... 

If there are only US7ASCII characters in you database
                      AND 
The current characterset you are on is a strict superset of US7ASCII

Then you might be able to utilize the INTERNAL_USE functionality to convert the 
database characterset...  However you need to make sure you understand the 
limitations around CLOB data...


Another thing to consider is the combination method...  Basically, you export 
the problem tables...  Convert the database...  Import the previous export...  
This works extremely well on a system that has lots of tables that simply 
stores numeric data and a handful of tables with character data...


Like you said, not for the faint of heart...  Make sure you REALLY understand 
this stuff before you start issuing any of these commands...  There is no 
ability to rollback these changes...

Tim

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: