I created my database (Oracle 9.0.1.3 on SuSE SLES7) with
NLS_CHARACTERSET=US7ASCII and NLS_NCHAR_CHARACTERSET=AL16UTF16 because
my intention was to use NVARCHAR2 columns for storing multilanguage strings.

I thought these two parameters were independent from each other. But
then I came into "bug" 2858947 (actually, not a bug but an expected
behaviour):

"When a string literal is included in a query and the query is submitted
through a client-side tool such as SQL*Plus, all the queries are encoded
in the client's character set and then converted to the server's
database character set before processing. Therefore, data loss can occur
if the string literal cannot be converted to the server database
character set."

This make NVARCHAR2 columns absolutely usable for me. But, as I
understood correctly the above paragraph, even if my database were
created with WE8ISO8859P1 charset I would not have been able to store
anything but WE8IS8859P1 strings in NVARCHAR2 columns, because all
string literals would have been "converted to the server's database
character set before processing". So what is the aim of NVARCHAR2
datatype? I'm confused.

Kind regards,

--
Cris Carampa (spamto:cris119 (AT) operamail (DOT) com)

We are SCO. Unix is our property.
Linux is illegal. Prepare to be sued.

Cris Carampa <cris119 (AT) operamail (DOT) com> wrote

No. Basically it says: if your database character set and your client
characterset do not match, ie the database character set is a subset
of the client, you will get conversion.
Is your AL16UTF16 a subset of WE8ISO8859P1. Don't think so.
If however your client doesn't support this characterset, you won't be
able to store AL16UTF16 characters in the database.

Regards

Sybrand Bakker
Senior Oracle DBA