Reputation: 11
An application I'm using with Oracle seems to be having issues with characters, and I ran the queries below to check on the CHARACTERSET.
SELECT * FROM nls_session_parameters WHERE PARAMETER='NLS_CHARACTERSET';
SELECT * FROM nls_database_parameters WHERE PARAMETER='NLS_CHARACTERSET';
The second query from nls_database_parameters returns AL32UTF8.
But the first query seems to return None.
I've read that the nls_session_parameters takes precedence over the nls_database_parameters, but in this case, where there does not seem to be any value set for it, would it fall back to the nls_database_parameters, or is there something that needs to be configured to set the nls_session_parameters.
Thank you for any input on this.
Upvotes: 0
Views: 4600
Reputation: 185
From Oracle Docs
NLS_SESSION_PARAMETERS shows the NLS parameters and their values for the session that is querying the view. It does not show information about the character set.
Basically NLS_SESSION_PARAMETERS
will not have Parameter called NLS_CHARACTERSET
.
The character set is part of the locale, which is determined by the value of NLS_LANG
.
NLS_LANG is set as an environment variable on UNIX platforms. NLS_LANG is set in the registry on Windows platforms.
Hence check the NLS_LANG
. Also this information is picked up by the client application at startup time, and cannot be changed from within.
Upvotes: 1
Reputation: 59436
The NLS_CHARACTERSET
is the character set which is used by the database. Your session (i.e. the client) does not store anything, thus NLS_CHARACTERSET
does not exist.
I assume you are looking for NLS_LANG
which tells the database which character set is used by the client. You cannot query NLS_LANG
from any database view/table, you have to check settings in your client. You can set NLS_LANG
only at your client side, not at database side.
Note, some clients (e.g. Java JDBC based clients) do not use NLS_LANG
setting, they use a different globalization mechanism.
Upvotes: 0