On Apr 15, 8:26*am, "André Hartmann" <andrehartm...@hotmail.com>
wrote:
> "Carlos" <miotromailcar...@netscape.net> schrieb im Newsbeitragnews:c03f11e2-8cd4-41ff-bba6-b0a0f6c3c7e7@m3g2000hsc.googlegroups.com...
> On Apr 15, 3:04 pm, "André Hartmann" <andrehartm...@hotmail.com>
> wrote:>I cannot see the point of storing UNICODE (UTF8? UTF16?) in a
> >WE8MSWIN1252 database... (you don't specify the NLSupport codepage for
> >NVARCHARS/NCHARS)
>
> >The DB codepage should be unicode *(AL32UTF8).
>
> * Hi, if that is so (unicode cannot be stored into databases that do not
> have a unicode character set) then why can I create tables with unicode
> columns (NCHAR, NVARCHAR2, NCLOB) in such databases? Wouldnt it be more
> appropriate then for Oracle to cast errors when trying so? To say it the
> other way round, the sheer fact that it is possible to declare unicode
> columns in the database implied to me that it is possible to store such
> values. Am I wrong here?

You are missing the point about Oracle being helpful and friendly and
way, way helpful and way, way, way friendly about converting from one
character set to another. Most tools honor that, but some don't. But
the general way to not get the conversion is to have the proper NLS
environment, as well as the proper character set. In general, using a
character set that does not support what you are putting into it will
cause you grief one way or another. Unicode is designed to handle any
sets (subject to which Unicode you are using - there are many version-
dependent issues about that).

It is not an error because it is a feature for Oracle to be able to
handle different character sets. That puts it upon you to understand
the implications. Please read the docs about globalization, as well
as the metalink docs that help you understand NLS. It can get quite
involved, though usually the answer for a particular situation winds
up being simple.

jg
--
@home.com is bogus.
http://paulschreiber.com/blog/2008/0...n-translation/