Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: what characterset to use?

Re: what characterset to use?

From: Ben <>
Date: Thu, 23 Aug 2007 05:22:35 -0700
Message-ID: <>

On Aug 22, 2:57 pm, wrote:
> On Wed, 22 Aug 2007 08:39:02 -0700, Ben <> wrote:
> >One other thought. How could it be possible to guarantee that you
> >would never corrupt your data in a WE8MSWIN1252 database character set
> >or any other multibyte character set?
> WE8MSWIN1252 is a *single* byte characterset. Please read your
> manuals.

I wasn't trying to imply that WE*8*MSWIN1252 was a multibyte characterset. I can see how it read that way though. I have read the Globalization Guide, thanks for the pointer though.

> >You don't really have control over what character set all the clients
> >connect with, do you? If you have a client that uses US7ASCII and they
> >select then update based on results, you could potentially corrupt all
> >your data. no?
> Incorrect again. If your database has been set up correctly (which is
> database characterset matches the OS characterset or is supported by
> the OS AND NLS_LANG has been set correctly) the US7ASCII data will get
> converted upon arrival.

The way I'm understanding Tom Kyte's book, Expert Oracle Database Architeture, it is contradicting what you're saying here. He has an example on page 493-494 where a database using characterset we8iso8859p1 is loaded with three 8 bit values chr(224) chr(225) & chr(226). The he sets a client's character set to us7ascii and reads the data. It displays three 7 bit converted characters. So yes it does convert 8 bit data to a 7 bit replacement character. But if that same client stores that data in a variable and then updates that data, it will then be stored as the 7 bit value that was read by the client. That is what I meant by data corruption.

> If your client NLS_LANG is US7ASCII AND your database NLS_LANG is
> US7ASCII, no conversion will take place. THIS will 'corrupt' your
> data.

If you database is setup as us7ascii then no 8 bit data can be stored in the first place. correct? If the client was setup as us7ascii also, then I don't see the problem. Client can't read or write 8 bit data and database can't store 8 bit data, there wouldn't be any need for a conversion. What am I missing here? Received on Thu Aug 23 2007 - 07:22:35 CDT

Original text of this message