From: Frank van Bortel <>
Date: Sun, 07 Jun 2009 17:24:05 +0200
Message-ID: <2c38a$4a2bdb96$524b9d64$>

Laurenz Albe wrote:
> Gerard H. Pille wrote:

>>>> Alas, we want to check if all PC's have been correctly configured, even all clients.
>>> As far as i know, it can't be done from within the Oracle server.
>>> I guess, it should be done by os means, another difficulty may be in the term environment *variable*, i.e., it can be changed 
>>> every time by the client.
[Quoted] >> Indeed, and we would like to prevent that.  A client pretending to use the same character set as the database, can store quite 
>> some rubbish.


[Quoted] No they cannot. And as long as path to equals path from, no one is going to see any changes.
If you want to store the character 'A', and you do it by translating into something you do not recognize, and get it back, and it is still represented as 'A', how can that be wrong?!?

[Quoted] Somethimes, the thing you stored (and did not recognize) is encrypted. Sometimes, a client with another nls setting than what you *expected* entered the character.

Think EBCDIC, for a change.

> - They do not verify correctness of the data when client
> encoding is equal to serve encoding.

[Quoted] Eh? data has nothing to do with nls_lang. Besides, define correct.
> - They do not report an error when a character conversion
> between different encodings fails, but silently store
> bad data ("replacement characters").

[Quoted] It does not fail - it simply ends up in another character code. Other dimension of same world.

> This all comes together with a third bug, namely that
> (at least up to Oracle 8) Windows clients were installed
> with the wrong NLS_LANG setting (WE8ISO8859P1) by default.
> All this resulted in lots of corrupt databases.

[Quoted] Perhaps in some code points being off - not corrupt databases. Corrupt is too large a word here.


Frank van Bortel
Received on Sun Jun 07 2009 - 17:24:05 CEST

Original text of this message