I have the following problem on WINDOWS (Italian):
my NLS_LANG parameter is: ITALIAN_ITALY.UTF8
i want to execute the following query:
INSERT INTO SCHEMA.MY_TABLE("NAME") VALUES('ò');
Doing it by using command line (pure sqlplus) stores invalid data inside DB.
Doing it by using SQLDEVELOPER stores correct data.
I cannot find any way to set this stuff correctly, what should I do? Using SQLPLUS from command line is required.
Any help is appreciated.
When you use sqlplus then it inherits the character set from command line window. You can interrogate and modify character set (aka encoding) with chcp, I assume it is CP850 - which is not UTF8.
Run chcp 65001 before you start sqlplus, then it should work. See also Converting German special characters to English equivalent one in Oracle SQL / PL-SQL or to read more details OdbcConnection returning Chinese Characters as "?"
Related
In our database german umlauts are displayed as ASCII.
Here some examples
Ü is displayed as "š"
ä is displayed as "„"
Ä is displayed as "Ž"
ö is displayed as "”"
Ö is displayed as "™"
Here some Oracle enviroment variables:
SELECT distinct client_charset FROM v$session_connect_info
WHERE sid = sys_context('USERENV','SID');
retuns Unknown
select * from v$NLS_PARAMETERS;
NLS_LANGUAGE GERMAN
NLS_CHARACTERSET WE8MSWIN1252
I have also noticed, that there is no NLS_LANG setted up.
Can someone give me any clue how to check if this is a problem of env variable or character-encoding itself? Or how to fix it so that the umlauts would be displayed correctly?
Thanks in advance!
The first sentence is already wrong, it must be "my client application displays german umlauts as ..." Characters like Ž are not ASCII either. The Oracle environment variables have nothing to do how your client displays any characters.
There could be two reasons:
Characters like š „ Ž ” ™ are really stored in your database because they are inserted wrong, and you just think it should be Ü ä Ä ö Ö
Your client uses the wrong character set.
NLS_LANG is used to tell the database "my client uses character set XYZ" - no more, no less! Well, some clients inherit the NLS_LANG value for own character set setting but that is not always the case.
Actual answer:
You have wrong data in your database! When you inserted the data then your client was using CP437 (Oracle Character Set US8PC437) but you did not tell this the database.
Most likely data was inserted by sqlplus which inherits the codepage from cmd.exe which is by default 437 on English Windows machines. NLS_LANG character set was set to WE8MSWIN1252. When character set of client and database is the same then data is transferred byte-by-byte without any conversion - there is the mismatch!
Solutions:
Before you run your sqlplus script Set NLS_LANG accordingly, e.g.
SET NLS_LANG=.US8PC437
sqlplus ...
Language and Territory are optional and thus can be skipped.
Your database uses character set WE8MSWIN1252, then it would be beneficial to use it also by your client. By this you can insert and display any character which is supported by the database (no less but also no more)
chcp 1252
SET NLS_LANG=.WE8MSWIN1252
sqlplus ...
Correction of wrong data:
In order to correct the wrong data try this:
UPDATE table_name SET column_name = CONVERT(column_name, 'WE8MSWIN1252', 'US8PC437');
Note, this should be a one-time correction only. Do not put such update as part of your application code!
Update
For correction of PL/SQL code, try this one (not tested):
Create a SQL script like this:
SET HEADING OFF
SET FEEDBACK OFF
SET NEWPAGE NONE
SET VERIFY OFF
SET TRIMSPOOL ON
SET DEFINE OFF
SET ECHO OFF
SET TERMOUT OFF
SET PAGESIZE 0
SET LINESIZE 32767
SET LONG 2000000000
SET LONGCHUNKSIZE 32767
spool PACKAGE_NAME.sql;
SELECT DBMS_METADATA.GET_DDL('PACKAGE', 'PACKAGE_NAME', USER) FROM DUAL t;
spool OFF;
EXIT
And the run it like this
c:\> chcp 437
c:\> SET NLS_LANG=.WE8MSWIN1252
c:\> sqlplus -s ... #<above script>
c:\> SET NLS_LANG=.US8PC437
c:\> sqlplus ... #PACKAGE_NAME.sql
I have created simple table which has only one field TCHAR
SQL> desc test;
Name Null? Type
----------------------------------------- -------- --------------
TCHAR CHAR(20)
I have created one .sql file and run the sql script from sqlplus using
#filepath..\germantest.sql then output was getting replaced with some junk words
Output:
SQL> select * from test;
TCHAR
--------------------
Ä
Wir bestß
Nauch à â Ý
But when I try to insert same data run directly on sqlplus instead of file then
Input
insert into test values('Ärger Ökonom');
insert into test values('Ä');
insert into test values('Wir bestß');
insert into test values('Nauch à â Ý');
Output
SQL> select * from test;
TCHAR
--------------------
Ärger Ökonom
Ä
Wir bestß
Nauch à â Y
The output shows here is correct.
What I tried till now.
I checked file format and it must be utf-8
I checked NLS_charset and it is AL32UTF8.
What did I expect?
When I run same file from sqldeveloper, then I am getting correct output.
I want to run same script from .sql file and want to retain german characters in database as it is in original file.
Your codepage in the Windows console must match the NLS_LANG setting for SQL*Plus.
In a nutshell you need:
c:\> chcp 65001
c:\> SET NLS_LANG=GERMAN_GERMANY.AL32UTF8
You can easily verify if your code page is correct if you run type germantest.sql in the console. If that doesn't display the file contents correctly you have the wrong codepage:
Now the codepage has to match the NLS_LANG setting:
The correct value for NLS_LANG is also important when running a SQL script because it determines the encoding in which the file is read by SQL*Plus.
Of course cmd.exe needs to be configured to use a font that can actually display those characters.
I exported a table in Oracle (which has Vietnamese text) from Dataserver A:
export NLS_LANG=AMERICAN_AMERICA.VN8VN3
exp system/123 BUFFER=64000 FILE=/tmp/export.dmp TABLES=(USERS.AREA) GRANTS=N INDEXES=NO ROWS=Y
And then, I try to import export.dmp to Dataserver B:
export NLS_LANG=AMERICAN_AMERICA.VN8VN3
imp system/123 BUFFER=64000 FILE=/tmp/export.dmp indexes=n grants=n constraints=n statistics=none ignore=y full=y
But, the field ID_ISSUE_PLACE was garbled.
And this is the screenshot which I operated in B.
I used the same command to export two tables on A, but after I executed imp command on B,the result is like this! The field COMMENTS in table1 is correct, but the filed NAME in table2 is incorrect.
How to solve this problem?
Assuming you are on Windows, and you are using SQL*Plus - it may be as simple as using the proper character set in the COMMAND window. In my case, I have the command $chcp 1252 in my glogin.sql, but from within the session you can do the same with host chcp 1252. This changes the "codepage" (character mapping) to 1252, Microsoft's name for the character set it uses for graphical programs.
For Vietnamese, perhaps the right codepage is not 1252. Take a look at http://www.oracle.com/technetwork/products/globalization/nls-lang-099431.html (and bookmark it for future reference); if I am reading it right, the correct codepage for Vietnamese is 1258.
So: Type host chcp 1258 at the SQL*Plus console and see if it helps. If it does, add $chcp 1258 to your glogin.sql.
I need to insert value into an Oracle table
'RR® 5'?
I created a table column varchar2 data type.
But when I am displaying the data it is showing:
'RR?? 5'
Any idea, please.
First of all you have to check if your database runs on character encoding which supports your special characters.
Execute this query to check.
SELECT *
FROM V$NLS_PARAMETERS
WHERE PARAMETER IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');
Character sets like AL32UTF8, UTF8, WE8ISO8859P1 are able to store special characters ®.
In order to check whether your characters are supported you can run this command
SELECT
ASCIISTR(CAST(UNISTR('\00C2') AS VARCHAR2(4))) AS VARCHAR_SUPPORT,
ASCIISTR(CAST(UNISTR('\00C2') AS NVARCHAR2(4))) AS NVARCHAR_SUPPORT
FROM dual;
VARCHAR_SUPPORT NVARCHAR_SUPPORT
---------------- ------------------------
\00C2 \00C2
1 row selected.
If your result value (00C2) is equal to your input value then your characters are supported.
Suppose your database supports the characters (otherwise the game ends here)
Solution 1
Run this command from any SQL editor or from SQL*plus
INSERT INTO THE_TABLE VALUES (UNISTR('RR\00C2\00AE 5'));
Depending on your actual requirements this can be a very tedious work.
Solution 2
Use SQL*plus command. For this you have to set NLS_LANG environment variable according to code page of cmd
C:\>chcp
Active code page: 850
C:\>set NLS_LANG=.WE8PC850
C:\>sqlplus user/pwd#DB
SQL> INSERT INTO THE_TABLE VALUES ('®');
When you work on Linux/Unix the chcp equivalent is locale charmap or echo $LANG. You can also change current code page, e.g. chcp 65001 for UTF-8
Solution 3a
Create a SQL script containing the same INSERT command as above, and save it with local encoding (typically Windows CP1252, many times misnamed as ANSI)
c:\>set NLS_LANG=.WE8MSWIN1252
c:\>sqlplus user/pwd#DB #Special_Char_CP1252.sql
Solution 3b
Create a SQL script and save it with UTF-8 which is supported by most modern editors. Note: SQL scripts must not contain a BOM (Byte Order Mark), otherwise SQL*plus will raise an error. I found this tiny command line tool to add and remove BOM from arbitary text files: UTF BOM Utils
c:\>set NLS_LANG=.AL32UTF8
c:\>sqlplus user/pwd#DB #Special_Char_UTF8.sql
Note for solutions above: you can skip the set NLS_LANG command in case your registry is set accordingly. Check with this command
C:\>REM for x64 Oracle Client
c:\>reg query HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\ /s /v NLS_LANG
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient11g_home1
NLS_LANG REG_SZ AMERICAN_SWITZERLAND.AL32UTF8
End of search: 1 match(es) found.
C:\>REM for x86 Oracle Client
c:\>reg query HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE\ /s /v NLS_LANG
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE\KEY_OraClient11g_home1
NLS_LANG REG_SZ AMERICAN_SWITZERLAND.AL32UTF8
End of search: 1 match(es) found.
C:\>
Solution 4
Run your INSERT statements from a more sophisticated editor like TOAD or SQL Developer. Ensure that NLS_LANG value in Registry, resp. your system environment variable matches the file save options of the editor.
Some external resources which may help you:
Oracle documentation NLS_LANG Settings in MS-DOS Mode and Batch Mode
List of Code pages: Code page
Find a Unicode Codepoint: Codepoints
I got this SQL statement that I wish to run on SQLite:
INSERT INTO tEntity (name) VALUES ('Roger Café');
Note the é character. Using the SQLite browser, I can insert this statement with the proper encoding.
However, if I save the above statement as a file (my.sql) and then run it on the Windows command line, I am having an encoding problem. The é in Café is garbled up.
C:\somewhere> sqlite3.exe my.db
sqlite> .read my.sql
I'm using Notepad++ to create the file in ANSI encoding. I have tried to use UTF-8 encoding but sqlite3.exe gives me a syntax error while reading the SQL file.
Is there any solution to fix this?
The encoding UTF-8 in notepad++ has BOM, which sqlite3.exe does not know about. Try using UTF-8 without BOM.