Be very careful and definitely run
csscan.
I worked with a customer in Thailand that had an
applicaion where the front end was cobol. The database had USASCII7 as the
characterset and for whatever reason the cobol had allowed the use of Thai
Characters, which had become stored in the database. Oracle was storing in
effect garbage, that only the cobol application could extract, and it was
going to take some work to extract that data. It became apparent when the people
were testing and ran a couple of queries in sqlplus and got garbasge in product
descriptions or details lines. This data couldnt go into a
datawharehouse and in fact it was useless in that database to anything except the cobol
application.
The only solution I could see in this case would have
been to extract that data using the cobol and then creating a new database with
a suitable characterset and running the data back into it.
I only hope its since been fixed but I doubt
it.
Cheers
Peter
Hello Marks ...
I appreciate both your answers. UTF8 is
being forced upon us by several third party applications, and I doubt we would
have the option to change the character set unless we were willing to accept
'unsupported' status. So we will have at least three different systems on
UTF8 in the very near future, obsolete or not.
My thinking is very
similar to Mark B's thoughts - there are certain characters that are not going
to store in our data warehouse eventually if we don't convert the character set
to something more internationally friendly. I plan on running cscan but
... we have global manufacturing entering data in our systems, so even if there
are no issues now it seems logical that we would eventually hit something that
couldn't be stored in the warehouse. Which is why I don't understand
Oracle's answer to my question.
And that brings me back to Mark P's
input. Since the warehouse is the one place I can choose my character set,
it seems that the best approach would be to convert the warehouse to
AL32UTF8.
Then we'd be prepared for the current requirements and for the first vendor we
introduce that uses the newer standard.
thank you both ...
Robyn
On 7/17/07, Bobak,
Mark <Mark.Bobak@il.proquest.com>
wrote:
Hmm…well, as I said,
"I'm no expert on this subject…" so I'll be quiet now and see if more
knowledgeable people have anything to say…;-)
I thought UTF8 should be
considered obsolete as it is not guaranteed to match the emerging
standard and that AL32UTF8 was its replacement.
-- Mark D Powell --
Phone (313) 592-5148
