I can't figure out Oracle's encryptic syntax for the life of me. This is Oracle 10g
My session's NLS_LANGUAGE is currently defaulting to AMERICAN.
I need to be able to display UTF8 characters.
Below are some of my attempts, all incorrect:
ALTER SESSION SET NLS_LANGUAGE='UTF8'
ALTER SESSION SET NLS_LANGUAGE='AMERICAN_AMERICA.UTF8'
What's the secret command?
The character set is part of the locale, which is determined by the value of NLS_LANG. As the documentation makes clear this is an operating system variable:
NLS_LANG is set as an environment
variable on UNIX platforms. NLS_LANG
is set in the registry on Windows
platforms.
Now we can use ALTER SESSION to change the values for a couple of locale elements, NLS_LANGUAGE and NLS_TERRITORY. But not, alas, the character set. The reason for this discrepancy is - I think - that the language and territory simply effect how Oracle interprets the stored data, e.g. whether to display a comma or a period when displaying a large number. Wheareas the character set is concerned with how the client application renders the displayed data. This information is picked up by the client application at startup time, and cannot be changed from within.
Okay, per http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm:
NLS_LANG cannot be changed by ALTER
SESSION, NLS_LANGUAGE and
NLS_TERRITORY can. However
NLS_LANGUAGE and /or NLS_TERRITORY
cannot be set as "standalone"
parameters in the environment or
registry on the client.
Evidently the "right" solution is, before logging into Oracle at all, setting the following environment variable:
export NLS_LANG=AMERICAN_AMERICA.UTF8
Oracle gets a big fat F for usability.
Therefore, before starting '$ sqlplus' on OS, run the followings:
On Windows
set NLS_LANG=AMERICAN_AMERICA.UTF8
On Unix (Solaris and Linux, centos etc)
export NLS_LANG=AMERICAN_AMERICA.UTF8
It would also be advisable to set env variable in your '.bash_profile' [on start up script]
This is the place where other ORACLE env variables (ORACLE_SID, ORACLE_HOME) are usually set.
just fyi - SQL Developer is good at displaying/handling non-English UTF8 characters.
Related
I am using 19c client and my database's NLS parameters like these:
Also my clients specs are:
While (Windows 10 x64) I am using sqplus, I get this(you can see my NLS_LANG environment variable on the top of command line):
My 19c client home regedit NLS_LANG variable also is set to AMERICAN_AMERICA.W8ISO8859P9.
Yet, when I using TOAD for Oracle:
and using SQL Developer:
I got confused. On the internet they say NLS_LANG environment variable should be enough for setting client character set, but clearly it isn' t.
Due to this configuration difference, I am seeing "fıtıkçışahap"(on sqlplus) as "fıtıkçışahap"(on SQL Developer and TOAD for Oracle)
How can I overcome this situation?
Thanks in advance!
Edit:
V$NLS_PARAMETERS
Forget about SELECT CLIENT_CHARSET FROM V$SESSION_CONNECT_INFO, it does not mean anything.
SQL Developer is Java/JDBC based. 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.
Your NLS_LANG variable is set to AMERICAN_AMERICA.W8ISO8859P9 - what does it mean in terms of character set?
You tell the Oracle database: "my client uses character set W8ISO8859P9" (i.e. ISO-8859-9) - no more, no less!
When you run SQL*Plus then it inherits the character set from the command line codepage. You can interrogate and modify the codepage with command chcp. I assume it is either CP857 (if you run a Turkish Windows) or CP850 or CP437 (see National Language Support (NLS) API Reference). Non of these three codepages matches ISO-8859-9, so your output is gibberish.
Before you run SQL*Plus set the codepage accordingly, i.e. chcp 28599 (see Code Page Identifiers)
Alternatively set the NLS_LANG according to your codepage, e.g. AMERICAN_AMERICA.TR8PC857 (check with SELECT VALUE AS ORACLE_CHARSET, UTL_I18N.MAP_CHARSET(VALUE) AS IANA_NAME FROM V$NLS_VALID_VALUES WHERE PARAMETER = 'CHARACTERSET')
Usually TOAD handles the character set very smart, so I fear the gibberish you see in TOAD is the real data in your database, i.e. it is junk because you had the wrong NLS_LANG value when the data was inserted.
See also OdbcConnection returning Chinese Characters as "?"
My PostgreSQL database' s encoding was tr_TR.UTF8, so still UTF8. It should have been LATIN that support Turkish character set. Changing it to tr_TR.iso8859 solved my problem.
we have recently upgraded our test environment database to 12.2.0.1 from 11.2.0.3.
I see that NLS_TERRITORY value and NLS_LANG value in NLS_SESSION_PARAMETERS is not showing correct value after ORACLE 12C Upgrade.
It should be GERMANY and GERMAN and instead it is AMERICAN and AMERICA and hence some of the query do not show the correct result is terms of currency.
as the parameter "NLS_NUMERIC_CHARACTERS" is dependent of NLS_TERRITORY value.
I see that the NLS_DATABASE_PARAMETERS & NLS_INSTANCE_PARAMETERS, but the NLS_SESSION_PARAMETERS is wrong and hence it is affecting with some of our scripts where we are displaying the numbers.
I do not want to change it via ALTER SESSION and execute the SQL or hardcode in the SQL syntax with the parameter which handles the numbers.
Please let me know if there is any solution for the same so that NLS_SESSION_PARAMETER can be changed.
as the ORACLE DB is reading the PFILE, I have the below values set for NLS parameters are:-
NLS_LANGUAGE = GERMAN
NLS_TERRITORY = GERMANY
nls_length_semantics = char
I found the solution myself, it was a silly environment configuration and somehow reading wrong entry from another profile which is pointed by the actual profile file for the envrionment NLS_LANG.
it was export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
and hence whenever the DB was booting, the NLS session was loaded with the wrong NLS_LANG and NLS_TERRITORY value from this NLS_LANG envrionment variable.
I removed that wrong profile entry and used the NLS_LANG as below:-
export NLS_LANG=GERMAN_GERMANY.WE8ISO8859P15 in the actual profile file such that the DB gets the correct information.
then when I rebooted the DB, the NLS Session values gets fixed by itself and hence I do not have to change something in my scripts and will now work as same as they werr working with previous Oracle version.
I am using PLSQL developer to work with oracle db. When I compile a view which stores code like this:
select 'xidmət' as service from dual
the 'ə' character in the string becomes '?' character.
I think it's some oracle or plsql developer configuration problem, but I don't know what.What do you think the problem is?
First, check what your character set is using this:
select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
Then set your NLS_LANG environment variable to AMERICAN_AMERICA.CHARSET where CHARSET is the value found with that select. If you are in Windows, you will have to go to Control Panel, System, Advanced, Environment Variables, and set NLS_LANG under System variables.
Oracle does at least a 'one-pass' conversion between client and database, but the problem is that there are so many layers between client and database, including your client software, that it is usually better to match your client NLS_LANG with the database setting.
It also depends how that character was inserted. It might have been inserted using a different client tool using a different NLS_LANG, so you might have to update your extended ASCII characters (or foreign characters) before you get a consistent view from your select.
Need to configure your systems NLS_LANG parameter, according to your language preferences. Here's a link:
http://www.nazmulhuda.info/setting-nls_lang-environment-variable-for-windows-and-unix-for-oracle-database
For example, we have letters like "ąčęėįšųū". So in order to see them in pl/sql, we set NLS_LANG with value "LITHUANIAN_LITHUANIA.BLT8MSWIN1257".
Hope it helps. Good luck.
I'm trying to retrieve data from an Oracle database into MS Access or Excel on to a Windows 7 PC. The data includes characters such as degree and diameter symbols. These are not displayed correctly on the PC. I can see that the data is stored correctly using the dump function in my query, and that it is the translation to the client character set that not bringing them in.
By looking at this query, and also querying the database parameters with SELECT * FROM NLS_database_PARAMETERS, I can see that the NLS_CHARACTERSET = US7ASCII. I think this is cause of the problem as the diameter symbol etc is not included in this character set.
But, I've checked the registry to see what NLS_LANG is set to, and it is ENGLISH_UNITED KINGDOM.WE8MSWIN1252. I know that I'm looking in the correct registry key because when I change the language/territory (to GERMAN_GERMANY for example) it does change for my queries.
I've also checked for an environment variable that is overriding this setting and couldn't find one. I trying creating an NLS_LANG environment variable with the same settings as above but that didn't make any difference.
My Windows code page is set to 1252. The database NLS_NCHAR_CHARACTERSET setting is AL16UTF16.
Any ideas of what to do next?
If NLS_CHARACTERSET is set to US7ASCII then you will never get any special characters from it. With NLS_NCHAR_CHARACTERSET=AL16UTF16 you should get any character, provided the data type of your column is NVARCHAR2 or NCHAR (not VARCHAR2)
Set your local NLS_LANG to ENGLISH_UNITED KINGDOM.AL32UTF8 then it should work.
Some time ago my PL/SQL stopped showing characters åäö.
I've tried reinstalling oracle_home_11g, PL/SQL cleaned the registry but the problem remains.
Anyone know why?
Most probably it is due to the mismatch between the locale-specific NLS characterset and the database characterset. Or else, the NLS_LANG value is not correctly set in the OS environmental variable.
Have a look at Why are junk values/special characters/question marks displayed on my client?
Your client charaterset doesn't match with database characterset.
You can compare between :
-- locale-specific characterset
select value
from v$nls_parameters
where parameter = 'NLS_CHARACTERSET';
-- database characterset
select value
from nls_database_parameters
where parameter = 'NLS_CHARACTERSET';
If you see a mismatch between the two, then set the locale-specific NLS characterset to that of database characterset.
If the above charactersets match, then you need to set the NLS_LANG value in the OS environmental variable.
For Windows OS, the format is:
[NLS_LANGUAGE]_[NLS_TERRITORY].[NLS_CHARACTERSET]
Follow the instruction in the documentation regarding setting up the NLS_LANG : Setting the NLS_LANG Environment Variable for Oracle Databases