Praveen wrote:
The oracle clients don't care what charset the database server has
as long as the client charset is a full subset of the server's.
Server we8iso8859p1, client us-ascii =works fine, but not reversed.
Then a session is created, a bunch of statements like alter session set
nls_charset=... ., number delimiters and ore. That means that the
connecting process on the server adapts the settings from the client,
if possible.
Server UTF8, client could have any set of we8iso8859p1-17, traditional
Chinese, north-korean, russian, greek ....
The edge is, that your english or us client possibly isn't able to
display the north-korean text, and will be shown as reversed ????
Worse is, that many believe that an 'international' windows client might
be able to select Chinese charset - but if it is not a Chinese version
windows - it wont work.
Remember that with utf8 charset on the server, some characters like ñ,
ü and others (i cant type due to charset settings) can expand up to 3
bytes. All of a sudden a varchar2(300) holds only 100 characters, if
they are all 3 byte types. Some charset are fixed 3 byte and some are
variable 1 to 3 bytes. Check the doc, nls_lang support.
/svend
Hi All,
I have Oracle 8.1.6 on win2000 env. I have already one database with
AMERICAN_AMERIC A.WE8ISO8859P1 charset. And i created one more database
with UTF8 charset. If i see in my registry, the variables have
following values..
HKLM\Software\O racle\NLS_LANG= NA
HKLM\Software\O racle\ALL_HOMES \ID0\NLS_LANG=N A
HKLM\Software\O racle\HOME0\NLS _LANG=AMERICAN_ AMERICA.WE8ISO8 859P1.
If client app(which is going to be developed in java) try to access
this database will it work? or if there is anything is missing in my
registry.
Please help me,
Praveen
I have Oracle 8.1.6 on win2000 env. I have already one database with
AMERICAN_AMERIC A.WE8ISO8859P1 charset. And i created one more database
with UTF8 charset. If i see in my registry, the variables have
following values..
HKLM\Software\O racle\NLS_LANG= NA
HKLM\Software\O racle\ALL_HOMES \ID0\NLS_LANG=N A
HKLM\Software\O racle\HOME0\NLS _LANG=AMERICAN_ AMERICA.WE8ISO8 859P1.
If client app(which is going to be developed in java) try to access
this database will it work? or if there is anything is missing in my
registry.
Please help me,
Praveen
as long as the client charset is a full subset of the server's.
Server we8iso8859p1, client us-ascii =works fine, but not reversed.
Then a session is created, a bunch of statements like alter session set
nls_charset=... ., number delimiters and ore. That means that the
connecting process on the server adapts the settings from the client,
if possible.
Server UTF8, client could have any set of we8iso8859p1-17, traditional
Chinese, north-korean, russian, greek ....
The edge is, that your english or us client possibly isn't able to
display the north-korean text, and will be shown as reversed ????
Worse is, that many believe that an 'international' windows client might
be able to select Chinese charset - but if it is not a Chinese version
windows - it wont work.
Remember that with utf8 charset on the server, some characters like ñ,
ü and others (i cant type due to charset settings) can expand up to 3
bytes. All of a sudden a varchar2(300) holds only 100 characters, if
they are all 3 byte types. Some charset are fixed 3 byte and some are
variable 1 to 3 bytes. Check the doc, nls_lang support.
/svend