Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: NLS Part III - i really need help ... !!!

Re: NLS Part III - i really need help ... !!!

From: Martin Haltmayer <Martin.Haltmayer_at_d2mail.de>
Date: Fri, 29 Jun 2001 10:28:59 +0200
Message-ID: <3B3C3C4B.34DF5244@d2mail.de>

Hi Ingmar,

did you also specify the national character set when creating the database? Can you please post the result of "alter database backup controlfile to trace;"?

My guess on the US7ASCII working: many 7-bit systems map the umlaut codes (which are clearly 8-bit) to [\]{|}~ (for Γ„Γ–ΓœΓ€ΓΆΓΌΓŸ) but display them as 7-bit. What does a "select dump (COL) from TABX" give? Then you will see as what value Oracle stores the beast.

This would explain the "working" US7ASCII and the wrong sorting (because [\]{|}~ are true 7-bit characters that are sorted as such). You may try to sort umlaut upper A, umlaut upper O, umlaut upper U, [, \ and ]. What gives?

You should create your database with any 8-bit character set (like WE8ISO8859P1 or UTF8). Then each client should set its environment characterset to whatever codes *it* provides. Oracle will notice that the character sets are different and it will try to convert between them provided the codes match the declared character set.

Martin

Ingmar wrote:
>
> OK, I hope there is somebody out there that is familiar with NLS. I already
> posted a message today.
> I have Solaris 7 running Oracle 8.1.7
>
> I created three databases with three different character sets:
>
> 1.) US7ASCII
> 2.) WE8ISO8859P9
> 3.) UTF8
>
> The goal: Realize what settings influence the ability to create European
> chars and have a correct sort order
>
> OK, so what's the problem. This is what I tested
>
> Chars entered at Characters seen (visible)
> Database
> ============================================================================
> ==========
> âÀü server (local) âÀü
> US7ASCII (1.)
> Àâü remote win32 sqlplus client oau
> US7ASCII (1.)
> âÀü server (local) vd|
> WE8ISO8859P9 (2.)
> Àâü remote win32 sqlplus client Àâü
> WE8ISO8859P9 (2.)
> âÀü server (local) vd|
> UTF8 (3.)
> Àâü remote win32 sqlplus client Àâü
> UTF8 (3.)
>
> If I enter umlauts directly at the server with sqlplus with an insert, then
> the chars will look
> correctly only in the first db. For whatever reason, theoretically I would
> think that a 7bit
> database character set shouldn't even be able to save it as an "Γ€" - but it
> does.
> If I connect to the same DB from a remote win32 machine, the chars get
> converted to the same
> char without the dots. This is what I would expect the DB to do.
> The other databases, that should support the umlauts, only support them when
> I enter them from
> the remote client.
> Exception: If I enter "âÀü" on db 1. or 2. and view them locally at the
> server, I see "oau". If
> I enter them at the server, I see "vd|". That shows me that the server is
> converting when working
> over the listener - right?
>
> Sort order:
> The sort order will only be correct (after setting NLS_LANGUAGE or NLS_SORT)
> if I use one of the
> latter databases, not the first one.
>
> The problem:
> We have a server based daemon that writes on behalf of the clients, so the
> umlauts work only
> in the US7ASCII db where, in turn, the sort order won't work. Another thing
> is, besides that
> problem, that I don't even remotely understand why this works for the
> US7ASCII db. Is it because
> my Solaris box is configured for US ASCII? I tried different 'locale'
> settings with 'export LANG=...'
> with no effect.
>
> Now as you can see I already set up a funky little test environment here and
> I am getting more
> desperate EVERY DAY. So please help if your familiar with NLS or maybe just
> explain to me silly boy
> why things are the way they are.
>
> Thanks a lot in advance,
>
> Ingmar.
>
> --
>
> Regards,
>
> Ingmar.
>
> ==========================================================
> Get Eventwatch NT 2.0 FOR FREE at http://www.netikus.net !
> ==========================================================
Received on Fri Jun 29 2001 - 03:28:59 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US