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
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 would like to know the difference between
NLS_NCHAR_CHARACTERSET and NLS_CHARACTERSET settings in Oracle?
From my understanding, NLS_NCHAR_CHARACTERSET is for NVARCHAR data types
and for NLS_CHARACTERSET would be for VARCHAR2 data types.
I tried to test this on my development server which my current settings for CHARACTERSET are as the following :
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET US7ASCII
Then I inserted some Chinese character values into the database. I inserted the characters into a table called data_<seqno> and updated the column for ADDRESS and ADDRESS_2 which are VARCHAR2 columns. Right from my understanding with the current setting for NLS_CHARACTERSET US7ASCII, Chinese characters should not be supported but it is still showing in the database. Does NLS_NCHAR_CHARACTERSET take precedence over this?
Thank You.
In general all your points are correct. NLS_NCHAR_CHARACTERSET defines the character set for NVARCHAR2, et. al. columns whereas NLS_CHARACTERSET is used for VARCHAR2.
Why is it possible that you see Chinese characters with US7ASCII?
The reason is, your database character set and your client character set (i.e. see NLS_LANG value) are both US7ASCII. Your database uses US7ASCII and it "thinks" also the client sends data using US7ASCII. Thus it does not make any conversion of the strings, the data are transferred bit-by-bit from client to server and vice versa.
Due to that fact you can use characters which are actually not supported by US7ASCII. Be aware, in case your client uses a different character set (e.g. when you use ODP.NET Managed Driver in an Windows application) the data will be rubbish! Also if you would consider a database character set migration you have the same issue.
Another note: I don't think you would get the same behavior with other character sets, e.g. if your database and your client both would use WE8ISO8859P1 for example. Also be aware that you actually have wrong configuration. Your database uses character set US7ASCII, your NLS_LANG value is also US7ASCII (most likely it is not set at all and Oracle defaults it to US7ASCII) but the real character set of SQL*Plus, resp. your cmd.exe terminal is most likely CP950 or CP936.
If you like to set everything properly you can either set your environment variable NLS_LANG=.ZHT16MSWIN950 (CP936 seems to be not supported by Oracle) or change your codepage before running sqlplus.exe with command chcp 437. With this proper settings you will not see any Chinese characters as you probably would have expected.
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.
I'm facing a character discrepancy issue while extracting data from db tables.
I've written a PL/SQL code to spool some data to .txt file from my db tables and running this sql using unix shell but when I'm getting the spooled file, the result set is a changed one from the one at back end.
For example:
At back end: SADETTÝN
In Spooled txt file : SADETTŸN
If you look at the Y character, it is a changed one. I want to preserve all the characters the way they are at back end.
My db's character set:
SELECT * FROM v$nls_parameters WHERE parameter LIKE 'NLS%CHARACTERSET'
PARAMETER VALUE
NLS_CHARACTERSET WE8ISO8859P1
NLS_NCHAR_CHARACTERSET WE8ISO8859P1
And Unix NLS_LANG parameter :
$ echo $NLS_LANG
AMERICAN_AMERICA.WE8ISO8859P1
I tried changing NLS_LANG parameter to WE8ISO8859P9(Trukish characterset) but no help!
Could anyone let me know the solution to this problem?
I presume that you are trying to visualize your file with "vi" or something similar.NLS_LANG parameter is used only by your database to export to your file.For your editor(vi), you need to set the LANG parameter to the corresponding value to your NLS_LANG.
Exemple : For ISO8859P1 american english you have to do
export LANG=en_US.ISO8859-1
In other words your file is just fine it's your editor who doesn't know what to do with your Turkish characters.
You should use NCHAR data types. More information is available at Oracle Documentation - SQL and PL/SQL Programming with Unicode
For spooling from SQL*Plus, you need to set the NLS_LANG environment variable correctly. Here is a similar question in stackoverflow.