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.
Related
I am unable to see the diacritic characters (with accents) in my oracle SQL Developer. I have tried with all the Font option. Is any way I can add the "Arial Unicode MS" font in my oracle SQLDeveloper and see the character instead of the square box.
Since SQL Developer is based on pure Java and JDBC there is the a possibility that the data itself were stored wrong - this could happen when you used not proper client NLS_LANG value and/or wrong codepage (Windows) or LANG (Linux / Unix). Since Data allready in DB and fetch with SQL Developer returns crap, this is by 95% a NLS issue.
Please let us know Database Charachterset and NLS_LANG and Codepage (chcp) settings of client. You can perform
Select <Colname>, dump(<colname>) "Dump" from <table>;
To return a column and dump in Sqlplus.
Provide
NLS_LANG of client
Client codepage (Windows) or LANG (Linux)
Database Charachterset
the value from select,
the expected value and
value from SQL Developer performing the same select as shown above
and we will see 😉
I have already set up the oracle client NLS_LANG=THAI_THAILAND.TH8TISASCII in regedit>Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ORACLE\KEY_OraClient10g_home1.
And the database server CHARACTERSET also is TH8TISASCII(NLS_CHARACTERSET=TH8TISASCII)
But SQL PLUS still can't show the thailand language
try to set
NLS_LANG to the value AMERICAN_AMERICA.TH8TISASCII
we have a similar issue with our local settings that TURKISH_TURKEY.WE8ISO8859P9 produces problems even if WE8ISO8859P9 is characterset for Turkish, whereas AMERICAN_AMERICA.WE8ISO8859P9 runs fine for our character set.
sqlplus inherits the character set from your cmd.exe. You can interrogate and modify the character set (aka "codepage") with command chcp, e.g.
C:\>chcp
Active code page: 1252
If you have a Thai Windows then most likely this command returns Active code page: 874 in your case.
If you get a different code page then change it with chcp 874 before your launch sqlplus.
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.
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.
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