Is there any way to determine the NLS_LANG of a client using SQL or PL/SQL.

sys_context('USERENV','LANGUAGE') gives the database characterset, not the clients.

Thanks,

Gerard

Gerard H. Pille schrieb:
For local connections ( also using bequeth protocol) you can get the
environment variables with dbms_system.get_env procedure.

Best regards

Maxim

--
Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?

Aksel Peter Jørgensen

Maxim Demenko schreef:

Alas, we want to check if all PC's have been correctly configured, even all clients.

Gerard H. Pille schrieb:
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.

Best regards

Maxim

--
Why make things difficult, when it is possible to make them cryptic
and totally illogical, with just a little bit more effort?

Aksel Peter Jørgensen

Maxim Demenko schreef:
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.

Laurenz Albe wrote:
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?!?

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.

[snip!]
Eh? data has nothing to do with nls_lang. Besides, define correct.
It does not fail - it simply ends up in another character code.
Other dimension of same world.

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

--

Regards,
Frank van Bortel

Frank van Bortel schreef:
I must say that it was BULLSHIT that sprang to my mind, rather than EBCDIC.

Ik geloof dat in Nederland het woord "lulkoek" zou gebruikt worden.

I feel like replying to this, but let's not get religious
about it - I know that these things are to some extent
a matter of taste.

Frank van Bortel wrote:
That largely depends on what your definition of rubbish is.
My personal answer is "data that are not correct are rubbish".
My definition of "correct" in this context will be given below.

To your question of "how can it be wrong":
My feeling is that if somebody happily sits on a time bomb
and currently has no problems, I should still call that "wrong".
Or to be more picturesque, I could call it shit suspended above
the fan.

New requirements come up quickly in the business, and as soon
as somebody decides that this database should be - for example -
accessed with a JDBC client, you have a very real problem.

I think I understand your point, and I agree that it is a valid one.

When musing about this problem class I figured that there are
basically two philosophies:

1) Character data stored in a database should always be "correct"
(see below for my definition), and it is the responsibility
of the database software and the people who maintain and
configure it to keep it that way.

2) A database is a byte repository and should not care about
semantics. Its job is to reliably reproduce whatever was
fed into it. It is the job of the application to interpret
and maybe convert the data.

You seem to adhere to the second line of thinking, while I prefer
the first. I admit that the second paradigm is certainly much
more convenient for the DBA.

The character set part of NLS_LANG influences the data stored
in the database.

Ok, and here is my definition of correct:
A character stored in a database is correct if and only if the
user (or client application) and the database software agree on
its meaning.

I admit that I have been sloppy in what I wrote: the database
software cannot verify correctness of data in that sense.

What I wanted to say is "verify that the bytes fed to the client
are correct in the client encoding".

For example:
Both Note 14786.1 and Note 341676.1 agree that code point
hex 0x80 is not assigned in the WE8ISO8859P1 character set.
Yet Oracle will happily accept this byte when you feed it
to the client.

This is what I complain about.

Perhaps I'm spoiled by other software, but I get a very bad feeling
when I store something in a database, get no error or warning,
and yet the database mutilates the strings I want to store
so that I cannot get my data back.

I agree. I used this overly strong word for emphasis.

Yours,
Laurenz Albe

Laurenz Albe wrote:

Point taken.
And I can only agree; I wish Oracle only had the options "Single Byte"
and "Multi Byte" when creating a database.

The client side network should warn about using unassigned code points.
However - it would generate a *lot* of warnings!
--

Regards,
Frank van Bortel