My system using NLS_LANG = AR8MSWIN1256
This character set most read arabic character.
But, only arabic digit can't read.
ex) ٠ ١ ٢ ٣ ٤ ٥ ٦ ٧ ٨ ٩
These auto-convet into question marks to DB.
oracle column dump text
[ Typ=1 Len=1: 63 ]
I tried below things.
Change NLS_LANG = AL32UTF8
Change Regedit Oralce NLS_LANG = AL32UTF8
But, didn't works.
Please give me any solutions.
Related
I've got an issue inserting ñ chatacter to an Oracle database.
The INSERT operation completes successfully.
However, when I SELECT, I get n instead of ñ.
Also, I noticed executing:
select 'ñ' from dual;
gives me 'n'.
select * from nls_database_parameters where parameter='NLS_CHARACTERSET';
gives me 'EE8MSWIN1250'.
How do I insert ñ?
I'd like to avoid modifying db settings.
The only way I got this working was:
read the input .csv file with its windows-1250 encoding
change encoding to unicode
change strings to unicode codes representation (in which ñ is \00d1)
execute INSERT/UPDATE passing the value from #3 to a UNISTR function
For sure there is an easier way to achieve this.
Simplest way would be, find out the ASCII of the character using ASCII() and insert use CHR() to convert back to string.
SQL:
select ascii('ñ'),chr(50097) from dual;
Output:
ASCII('Ñ') CHR(50097)
---------- ----------
50097 ñ
The client you are using to connect to database matters. Some clients, donot support these characters.
Before you start your SQL*Plus you have to set the codepage (using chcp command) and NLS_LANG environment parameter accordingly:
chcp 1250
set NLS_LANG=.EE8MSWIN1250
sqlplus ...
However as already given in comments, Windows 1250 does not support character ñ. So, these values will not work.
It is not compulsory to set these values equal to your database character set, however codepage and NLS_LANG must match, i.e. following ones should work as well (as they all support ñ)
chcp 1252
set NLS_LANG=.WE8MSWIN1252
sqlplus ...
or
chcp 850
set NLS_LANG=.WE8PC850
sqlplus ...
Again, EE8MSWIN1250 does not support character ñ, unless data type of your column is NVARCHAR2 (resp. NCLOB) it is not possible to store ñ in the database.
Is that character supported by the database character set?
I could not find that character here: https://en.wikipedia.org/wiki/Windows-1250
I had no problems inserting that character in my database which has character set WE8MSWIN1252.
https://en.wikipedia.org/wiki/Windows-1252
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 have data which contains special characters like à ç è etc..
I am trying to insert the data into tables having these characters. Data gets inserted without any issues but these characters are replaced with with ?/?? when stored in tables
How should I resolve this issue?I want to store these characters in my tables.
Is it related to NLS parameters?
Currently the NLS characterset is having AL32UTF8 as seen from V$Nls_parameters table.
Is there any specific table/column to be checked ? Or is it something at the database settings ?
Kindly advise.
Thank in advance
From the comments: It is not required that column must be NVARCHAR (resp. NVARCHAR2), because your database character set is AL32UTF8 which supports any Unicode character.
Set your NLS_LANG variable to AMERICAN_AMERICA.AL32UTF8 before you launch your SQL*Plus. You may change the language and/or territory to your own preferences.
Ensure you select a font which is able to display the special characters.
Note, client character set AL32UTF8 is determined by your local LANG variable (i.e. en_US.UTF-8), not by the database character set.
Check also this answer for more information: OdbcConnection returning Chinese Characters as "?"
I'm loading a csv file using sqlldr.
the file contains the symbol "€" which is inserted into a VARCHAR2 column.
After the load, the database displays '¿' instead of the euro symbol.
I have specified the characterset in the control file during the load:
LOAD DATA
CHARACTERSET WE8MSWIN1252
I'm runing all of this on a Solaris machine, which by the way can't display the '€' symbol, I gives me a '.' instead when I hit the key to get the €.
We are using the data for BI purposes, so we have to keep the varchar2 column, even though changing its type to nvarchar2 inserts the € symbol correctly.
Can you suggest any other solution for the issue?
When I run locale command on the machin, I get :
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
and my NLS DATABASE PARAMETERS Are:
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET WE8DEC
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
I have tried setting the NLS_LANG variable, but nothing seems to work.
Regards.
Your database is not configured to support the Euro character in a VARCHAR2 column. Your database's NLS_CHARACTERSET of WE8DEC means that it uses the old DEC MCS character set. That character set long predates the Euro character (it's even older than the ISO 8859-1 character set that also predates the Euro). So you can't validly store a Euro character in a VARCHAR2 column in your database.
You could change the database character set to something that supports the Euro character. There are many such character sets but I would guess that ISO-8859-15, Windows-1252, or UTF-8 would be the easiest migrations. Personally, I'd always prefer Unicode (UTF-8 which is the AL32UTF8 character set in Oracle) but you may have a reason to prefer a single-byte character set. Alternatively, you could declare this column (and any others that need to use the Euro character) to be NVARCHAR2 columns since your national character set supports Unicode. Supporting NVARCHAR2 columns may require changes to your front-end applications. If you can change the database character set, that would be my strong preference over adding NVARCHAR2 columns.
I have an Oracle Database with character set AL32UTF8, but I am not able to read some information (ex. Chinese characters). How can I configure my PLSQL Developer to read these characters?
By the way, when I read this information it appears such as ???
I'm using Windows XP.
I found the answer by myself.
It's necessary to change the NLS_LANG registry in the following route HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_ODACHome2
And set it with the properly language. In my case it was : AMERICAN_AMERICA.AL32UTF8
Anyway...Thanks.
Set NLS_LANG Environment Variable also works for me.
Variable: NLS_LANG
Value: AMERICAN_AMERICA.AL32UTF8
Your NLS_CHARACTERSET should be set to AL32UTF8 and also make sure that parameter NLS_NCHAR_CHARACTERSET is set to UTF8.
SQL> ALTER SESSION SET NLS_NCHAR_CHARACTERSET = 'UTF8';