The other day I got this annoying oracle error: ORA-12705: Cannot access NLS data files or invalid environment specified. Funny thing I wasn't trying to access NLS data files
There are two possible causes:
An attempt was made to issue an ALTER SESSION statement with an invalid NLS parameter or value.
The NLS_LANG environment variable contains an invalid language, territory, or character set.
Fix:
Unset the NLS_LANG environment variable
Windows - The NLS_LANG must be unset in the Windows registry (re-named is best). Look for the NLS_LANG subkey in the registry at \HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE, and rename it.
Linux/UNIX - Here you simply issue the Linux command "unset NLS_LANG"
I have Oracle 10g XE and Windows 7. I resolved this as follows:
Go to Control panel > Regional and language options > Format and set your language.
Follow this procedure to set the NLS_LANG environment variable for Oracle databases.
To set the NLS_LANG environment variable for Oracle databases
Determine the NLS_LANG value.
In the data warehouse database, run the command
SELECT * FROM V$NLS_PARAMETERS
Make a note of the NLS_LANG value, which is in the format [NLS_LANGUAGE]_[NLS_TERRITORY].[NLS_CHARACTERSET].
For example: American_America.UTF8
For Windows:
Navigate to Control Panel > System and click the Advanced tab. Click Environment Variables.
In System variables section, click New.
In the Variable Name field, enter NLS_LANG.
In the Variable Value field, enter the NLS_LANG value that was returned in Step 1.
The format for the NLS_LANG value should be [NLS_LANGUAGE]_[NLS_TERRITORY].[NLS_CHARACTERSET].
For example: American_America.UTF8.
For UNIX, set the variable as shown below:
setenv NLS_LANG
For example: setenv NLS_LANG American_America.UTF8.
If your data is 7-bit or 8-bit ASCII and the Informatica Server is running on UNIX, then set
NLS_LANG _.WE8ISO8859P1
CAUTION: Make sure you set the NLS_LANG variable correctly, as stated in this procedure, or your data will not display correctly.
Reboot the machine after creating the variable.
In my case, I was creating a database adapter in the oracle weblogic console, solve the problem by doing the following configuration.
Windows -> control panel -> region: 1. Change the format to English (United States) date format M / d / yy and 2. Change my address to the United States. Perform this configuration because my machine was configured with the Spanish language, then restart the computer and I worked without problems.
After addition of path in Environment variable of Oracle Instant client the Oracle SQLPLUSW goes to Oracle Instant client and for that client it required to set NLS LANG AS American_America.UTF8
You can also just set the NLS config in your oracle settings
In case if above solutions not helped, can try my solution. I just replaced my latest version of Ojdbc14.jar to an older version Ojdbc5.jar. It helped me to solve my issue.
I was trying to configure my Data Source on WebLogic 12c that was pointing to an 11g Database and I kept getting this error. I found out that WL 12c is not compatible with oracle 11g databases.
I know it is not related but I am sure someone else will find this useful.
Related
Need your advise on the below:
Recently we migrated to Oracle client 19c from Oracle 11g through script on the windows server.
The script has wiped the previous Environment variable path for oracle 11g and replaced with 19c which is good.
The set up is such that, When I tried to connect to the DB, it first checks the environmental variable and then establishes the DB connection.
Sample Script:
set ora
set tns
pause
tnsping GENPF_dev_connect
sqlplus
The respective output are
"set ora"
ORACLE_Home=F:\GENPF\Oracle\product\19.0.0\client_32
Note: This path is correctly set
"set tns"
TNS_ADMIN=C:\Oracle\product\11.2.0\Client_1\Network\Admin\
TNS_NAMES=F:\GENPF\Oracle\product\19.0.0\client_32\network\admin
Note: Not sure from where Oracle took the TNS_ADMIN path.
TNS_NAMES path is correctly set
tnsping GENPF_dev_connect
Used parameter files:
C:\Oracle\product\11.2.0\Client_1\Network\Admin\sqlnet.ora
The strange part on tnsping is, even after defining and retrieving the right TNS_NAMES, it only checks the path for TNS_ADMIN.
As a work around, I set the TNS_ADMIN with the right path under Environmental variable such as
TNS_ADMIN=F:\GENPF\Oracle\product\19.0.0\client_32\network\admin
Even after adding the above entry, Oracle seems to ignore the environment variable path added and always provides the old entry.
Please suggest where things are going wrong on this?
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.
According to the site,
http://www.dba-oracle.com/t_nls_lang.htm
Problem might occur even if both the database and the client use the same characterset(AL32UTF8). I couldn't understand how this can be possible.
Quoting from the site:
For example, suppose that the database character set is AL32UTF8, the
client is an English Windows operating system, and the NLS_LANG
setting on the client is AL32UTF8. Data coming into the database is
encoded in WE8MSWIN1252 and is not converted to AL32UTF8 data
because the NLS_LANG setting on the client matches the database
character set. Thus Oracle assumes that no conversion is necessary,
and invalid data is entered into the database.
How can the data be coming as WE8MSIN1252 into the database when the encoding in the client is AL32UTF8?.
Because OS itself using other character set (WE8MSIN1252 in this case). But since NLS_LANG (on client) is set to AL32UTF8, Oracle does not know about this. Oracle always uses value in NLS_LANG and ignores system settings, while (almost) all other software uses OS settings.
So, to fix this problem, local (client) NLS_LANG must be the same as OS character set. Or (other option) software running on client must reencode characters by itself.
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 want to import data from a DB2 database into MS Access via ODBC. The connection is set up and working but decimal values get converted due to some locale issue (German Windows).
234.75 ends up as 23475 in the Access table.
I had the same issue with Oracle but was able to fix it by setting the ODBC drive to US locale. How can I do that with the DB2 ODBC driver?
DB2 v9.5
Do you have the possibility to read some of your field's properties through your ODBC connection? In this case I guess you could find that some of these properties will help you identify field's type, default value, length, etc. It should be then possible for you to incorporate in your import code some conversion instructions for numbers.
Have you tried to change your windows locale settings to US (start/Settings/Control Panel/Regional and language Settings/Regional Settings/customize)?
Even if your windows is german, you can set things such as decimal separator, date, etc to other standards (meaning for example that you can specificaly declare '.' as decimal separator instead of ',' for all windows applications.
When you set an ODBC connection with the linked table manager and you click through all the screens about database name, what credentials to use, there is a checkbox there for "Use regional settings when outputting dates, times, etc... something like that..." Is that checked?
Though this is an old posting some people might benefit from the solution to this issue (which I also encountered). The solution is:
Start the ODBC Administrator
Open the DSN
Open tab page Advanced
Setting Add a line with the following specs:
CLI Parameter: Patch2
Value: 15
This tells the DB2 client to use '.' as a decimal separator in stead of the locale.
Tested on: DB2 V9.7, Access 2010
Source: http://www-01.ibm.com/support/knowledgecenter/#!/SSEPGG_9.7.0/com.ibm.db2.luw.apdv.cli.doc/doc/r0008805.html