what I found odd after reading the migration manual is that the 9i
upgrade database is still showing:
NLS_CHARACTERSET WE8ISO8859P1
NLS_NCHAR_CHARACTERSET WE8ISO8859P1
I haven't found any issues with functionality, keeping in mind this
two tier instance doesn't contain any buisness data either. Most of
this questioning is derived from my lack of understanding the
charsets, not knowing what warrants choosing one over the other,
and well maybe the part about the conversion possibly creating
truncated or expanded data.
again TIA to anyone who has any input.
-----Original Message-----
From: Markham, Richard [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 9:28 PM
To: Multiple recipients of list ORACLE-L
Subject: migrating 8.x->9i and charsets
Ron I was reading your response about converting to UTF8 and it has risen some curiosity with my situation and recent upgrade of a DB from 8.1.7.2 to 9.1.0.3. A snippet from the migration manual states:<<If the old National Character Set is UTF8, then the new National Character Set will be UTF8. Otherwise, the National Character Set is changed to AL16UTF16.>>
the character set at the time was AMERICAN_AMERICA.WE8ISO8859P1 which my understanding is that the character set would become AL16UTF16. I never could get the character set scanner to accept the tochar=AL16UTF16 or tochar=al16utf16 parameter(s). It would result in CSS-00115: invalid character set name AL16UTF16 or CSS-00115: invalid character set name al16utf16. I went forward with the upgrade. I would like to know if there is anything I can do to check the data after this change or did the ccscan need only need to be ran against converting to UTF8. This test database houses the 11i applications objects. TIA for any information
