Re: NLS settings

> I'm using 9i, UTF16 characterset for the database.
>

UTF16 can only be used with national characterset (This is NVARCHARS ad so...)

If you want to see chinese characters in your sqlplus you must set the sqlfont properly (old 'courier new' won't help you here)

Also, you can use sql scratchpad or isql to see the chinese data.

> I'm trying to see if our application will store double-byte characters. I'm
> having trouble getting this to work with an English version of Windows. Do
> I need a Chinese version of Windows? (the language I'm trying to test?)

No you don't. If you are storing chinese in UTF16 (as NVARCHARS) you can use DUMP() function in sqlplus to see how your DB is actually storing your data. (Maybe you will not see the chinese characters, but you will be able to know if they are stored in the DB OK).

> registry, but then Windows wouldn't boot! My understanding is that the NLS
> setting on the client MUST match the code page the o/s is actually using.

Nope. NLS settings only concern the client connection with the DB. Nothing to do with the client 'national' OS.

In all above situations you must have a font installed which is capable to represent the chinese characters.

Regards.

Carlos.

"dsb" <dana_at_iqms.com> wrote in message news:<107tkicm19vf4a2_at_news.supernews.com>...
> Hi,
>
> I'm wading my way through all the NLS doumentation for 9i, and although it
> has improved vastly, it has also become quite huge!
>
> I'm trying to see if our application will store double-byte characters. I'm
> having trouble getting this to work with an English version of Windows. Do
> I need a Chinese version of Windows? (the language I'm trying to test?)
>
> I've tried changing the locale in regional settings, but I still get English
> input using SQL*Plus Worksheet. I tried setting the ACP to 952 in the
> registry, but then Windows wouldn't boot! My understanding is that the NLS
> setting on the client MUST match the code page the o/s is actually using.
>
> I'm using 9i, UTF16 characterset for the database.
>
> Thanks in advance,
> db
Received on Mon Apr 19 2004 - 04:33:39 CDT