Re: Extended Characters

From: Tim Johnston <tjohnston_at_quallaby.com>
Date: Tue, 13 Apr 2004 20:14:05 -0400
Message-ID: <407C824D.4080306@quallaby.com>

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_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Tue Apr 13 2004 - 19:10:40 CDT