We have created a "after logon" trigger to alter the session in order to set the two NLS settings - NLS_SORT and NLS_COMP. NLS_SORT needs to be set to BINARY_CI and NLS_COMP needs to be set to LINGUISTIC. By querying the V$NLS_PARAMETERS view after establishing the connection to verify the values I see that NLS_COMP parameter gets updated but NLS_SORT doesn't.
After researching more I realized that the OCI JDBC driver executes the below query after the connection is established
ALTER SESSION SET NLS_LANGUAGE='AMERICAN' NLS_TERRITORY='AMERICA'
Since NLS_SORT derives its values from NLS_LANGUAGE, NLS_SORT parameter value resets to BINARY instead of BINARY_CI. The NLS_LANGUAGE setting is taken from windows registry.
Does the oci jdbc driver execute these queries to synchronize the NLS settings on the client to that with the database server?
Can the jdbc oci driver be configured to avoid executing the alter session set NLS_LANGUAGE query?
The reason I ask the second question is that it doesn't make sense for application server (e.g glassfish, tomcat, jboss) machine (on which the OCI client is installed) settings to override the database server settings.
I have been wrestling with the exact same problem after introducing a trigger on logon for setting these values.
"The purpose of the NLS_LANGUAGE and NLS_TERRITORY settings are to let the database know locale information. These are derived from the NLS_LANG setting on the client (but can also be changed). These settings allow the database to send data back to the client in the expected format and language." - taken from here
No, it can't be configured to avoid that execution, though it might be a future feature. As it is, it seems the only solution is to have your application always change these parameters after logging in.
It might be of help to know that if you're using the thin connector rather than the OCI-driver and you set an on logon trigger, these values will be set properly after logon. The problem here is with the OCI-driver that will set up these values according to NLS_LANG only after the logon trigger has been executed.
According to chapter 19 Globalization Support from Home / Database / Oracle Database Online Documentation 12c Release 1 (12.1) / Application Development / Database JDBC Developer's Guide:
Starting from Oracle Database 10g, the NLS_LANG variable is no longer
part of the JDBC globalization mechanism. The JDBC driver does not
check NLS environment. So, setting it has no effect.
ALTER SESSION statement which you observed probably comes from the following statement from Globalization Support for JDBC Drivers section of chapter 9 Java Programming in a Global Environment from Oracle9i Database Globalization Support Guide (Release 2 (9.2)):
At database connection time, the JDBC Class Library sets the server
NLS_LANGUAGE and NLS_TERRITORY parameters to correspond to the locale
of the Java VM that runs the JDBC driver. This operation is performed
on the JDBC OCI and JDBC thin drivers only, and ensures that the
server and the Java client communicate in the same language.
Related
I have an issue regarding configuring Thai language in oracle (PL/SQL Developer). I have configured Thai language 'AMERICAN_AMERICA.TH8TISASCII' in regedit. Also I configured Environment variables in my computer. But still when I connect PL/SQL developer and retrieve data, columns that should show Thai descriptions are showing garbage data. Please help me.
Example of garbage data is '¿¿¿¿¿¿¿¿'
Oracle Configurations is as below :
regedit->computer->HKEY_LOCAL_MACHINE->SOFTWARE->ORACLE->KEY_OraDB11g_home1
Windown Configuration is as below:
Mycomputer->Advanced system setting->Advanced System
Settings->Environment Variables -> (here i added variable)
the same configuration is done by my peers and they got the configuration but i am not able to do this
I have configured Thai language 'AMERICAN_AMERICA.TH8TISASCII' in regedit.
It means you have configured your NLS_LANGUAGE as AMERICAN and NLS_TERRITORY as AMERICA. Which is wrong.
You should select the following:
NLS_LANGAUGE=THAI
NLS_TERRITORY=THAILAND
You need to do this at:
Database level - init.ora file
Environment level - NLS LANG settings
I think your characterset is fine.
UPDATE OP got the issue with PL/SQL Developer tool.
You can enter "alter session" commands in the AfterConnect.sql file in the PL/SQL Developer installation directory. For example:
alter session set nls_date_format='dd-mm-yyyy';
alter session set nls_territory='THAILAND';
alter session set nls_language='THAI';
source
I assume your selected font in PL/SQL Developer does not support Thai characters. Try this command to check:
SELECT UNISTR('Kho Khuat: \0E03') FROM DUAL;
Do you get proper output like this?
Kho Khuat: ฃ
If not, you should select a font which support Thai characters.
You can use this page FileFormat.info to check which font supports your character.
Value for NLS_LANG should match your local environment settings, not the setting from Database. By this all characters are properly translated in SQL communication.
Check you local environment with this command:
c:\>reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage /v ACP
In my case it is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage
ACP REG_SZ 1252
So, my NLS_LANG should be set to .WE8MSWIN1252 or something similar.
However, this is only valid if your application (SQL Developer in your case) uses the default encoding settings from Windows. In some applications you can change that - typically you can switch between local codepage and Unicode (UTF-8). In this case you must modify NLS_LANG accordingly.
Are the settings of oracle server like , the nls_date_format,.... attributes (I don't know really how many of these kind settings are there) , will be downloaded to the oracle client running on different machine by connecting to the SQL*plus using server host name?
Or the client will maitain its different set , assuming the client is SQL*Plus.
If the client is having its own settings ,is there any way If I can set the same settings as server. like export all settings from server and import those settings to client.
If the client is SQL Developer , is there any way to maintain the sync. between server settings and client's.
You can query the settings (about 20 variables) from the NLS-Views (NLS_DATABASE_PARAMETERS, NLS_INSTANCE_PARAMETERS, NLS_SESSION_PARAMETERS). By show parameter nls you can view the actual settings in SQL*Plus.
These can be altered by sysdba in several ways:
The database parameters are read from (s)pfile while startup. They can be altered via ALTER SYSTEM SCOPE=SPFILE if you use spfile. If you use pfile you have to edit it manually
The instance parameters are set by ALTER SYSTEM SCOPE=MEMORY and will be lost upon shutdown
Both at once can be altered using SCOPE=BOTH. This will be applied immediately and survive the shutdown
The client can override this for his own session in (at least?) two ways:
Set it for your session by ALTER SESSION in SQL*Plus
Set environment variables before client startup via export NLS_...=... in the shell
The latter overrides the earlier ones, so SESSION beats INSTANCE which eats DATABASE.
For your question: you can use a SELECT * FROM NLS_INSTANCE_SETTINGS and apply these to your current session by ALTER SESSION SET ... for each of these variables (maybe via some PL/SQL procedure). Another way would be just to unset all session parameters so that the instance parameters will be used.
If you do not set any NLS variables (especially NLS_LANG) in your environment, your session should be the same as the instance or the database ones. In practice this will never work as expected as you always have some locale settings that produce weired results in SQLP*Plus. ;-)
I found out my servers, running Oracle 10g, were not initializing with the same NLS_SORT value when using the sqlplus binary.
Is there a way to set the default NLS_SESSION_PARAMETERS for every instance of sqlplus?
PS: The idea is not to do an ALTER SESSION at the beginning of every sql script.
the NLS parameters are specified by the client application. SQL*Plus on windows will have its parameters defined in the registry (same as the ORACLE_HOME where it is installed). On *nix systems the paremeters are defined as environment variable.
You can find additionnal information in the documentation.
Use an ON LOGON trigger to do the ALTER SESSION?
Then you can do it in one place and won't have have to change every client.
i'm developing a 32bit Client-Application with Delphi. From this application I need to connect to databases on two different servers. First databse character set ist WE8MSWIN1252, the other server decodes with WE8PC850. Setting the client NLS_LANG parameter to the correct value solves correct sql-query results.
Unfortunately this (the client character-set) seems only to be recognized on applications startup (first connect to oracle). I need to change the client-characterset at runtime. Oracle client seems to store the character set an application used to connect!
beside: I#m using udl-files to setup the connections (Microsoft OLE DB - driver)
what can I do?
You could use ALTER SESSION calls to change the settings at the session level after connecting to the database.
I need to change the
client-characterset at runtime.
Why ? I would have thought what you want at the client end is a character set that is acceptable to the operating environment and end-user.
Pick out a character set such as UTF-8 and let Oracle handle the conversion between the client character set and the two database character sets.
I am using the thin Oracle JDBC driver ver 10.2.0 (ojdbc14.jar). I would like to configure its NLS_LANG setting manually. Is there a way?
Currently it fetches this setting from the VM variable user.language (which is set automatically by setting the current locale, or on startup from the system environment).
This is a problem when the users switch the application locale to a one that is unsupported by the Oracle JDBC driver (e.g. mk_MK). In this case, the next time I fetch a connection I get the following exception:
ORA-00604: error occurred at recursive SQL level 1
ORA-12705: Cannot access NLS data files or invalid environment specified
I can change the locale on the fly just before I fetch the connection and switch back to the user's selected one back and forth, but this seems unelegant and unefficient.
See also: https://serverfault.com/questions/63216/ora-12705-cannot-access-nls-data-files-or-invalid-environment-specified/64536
For me the best response was by FoxyBOA to invoke java app with:
-Duser.country=en -Duser.language=en
The NLS_LANG settings are derived from the java.util.Locale . Therefore, you will need to make a call similar to this before connecting:
Locale.setDefault(Locale.<your locale here>);
I was fighting the same problem and found out that thin jdbc Oracle drivers do not require NLS_LANG or system locale to be specified. But when you connect to non-english databases you are to have orai18n.jar in the classpath.
from Oracle® Database JDBC Developer’s Guide and Reference
Providing Globalization Support
The basic Java Archive (JAR) files,
ojdbc5.jar and ojdbc6.jar, contain all
the necessary classes to provide
complete globalization support for:
Oracle character sets for CHAR,
VARCHAR, LONGVARCHAR, or CLOB data
that is not being retrieved or
inserted as a data member of an Oracle
object or collection type.
CHAR or
VARCHAR data members of object and
collection for the character sets
US7ASCII, WE8DEC, WE8ISO8859P1,
WE8MSWIN1252, and UTF8.
To use any other character sets in
CHAR or VARCHAR data members of
objects or collections, you must
include orai18n.jar in the CLASSPATH
environment variable of your
application.
Invoking java with the following works for me :
-Duser.country=us -Duser.language=en
if "en" for country also causes ORA-12705.
You should use the old Oracle 9.2 JDBC driver that is fully compatible and certified with Oracle 10g. The old driver does not use ALTER SESSION SET NLS_LANGUAGE commands.