I am running a sql script through pl/sql Developer Command Windows.It is a simple script with two insert commands that inserts two labels in two different languages (French and English).
Some characters in the French label are inserted with "bad format". Running the query select * from V$NLS_PARAMETERS returns the values
NLS_LANGUAGE = AMERICAN
NLS_TERRITORY = AMERICA
NLS_CHARACTERSET = UTF8
My script file is saved in UTF encoding.
I am running in a Windows 10 machine.
Should i change the NLS_LANG value ? if yes what value should i insert ? The labels could be in English and French.
Is there anyway to run the command window in some encoding ? Or none of the those are solutions and i must do something else ?
Thanks in advance.
The safest option might be to use UNISTR to escape any non-ASCII characters:
SQL> select unistr('Fran\00E7ais') label from dual;
LABEL
-----------------
Français
I'm sure there is a way to configure your script, operating system, and PL/SQL Developer to natively work with different character sets. But what happens if someone runs the script in SQL*Plus instead? If there are only a few non-ASCII characters, escaping them is probably the easiest solution.
Related
I have a subject table which has a theme field contains the following rows :
theme
-----
pays
économie
associée
And I have this basic query :
SELECT * FROM SUBJECT WHERE THEME='associée';
The query runs fine in Sql developer and returns the expected row to me.
On the other hand under Sqlplus it returns 0 lines to me (which is not normal).
I have the impression that the query does not recognize accented characters under sqlplus. I am thinking of an NLS_LANG problem but I do not know about it. Please help.
Thank you in advance.
Set your OS session's NLS_LANG variable to the value of, e.g., ENGLISH_AMERICA.AL32UTF8 and restart your SQL Developer. Retry afterwards.
If that didn't help, try also running your query as follows:
SELECT * FROM SUBJECT WHERE THEME = n'associée';
Notice the n before the string literal. That's a nvarchar2 string literal modifier. Depending on your DB charset/national charset settings you may need to explicitly state that the value you are querying for, is "national charset", not just a "regular charset".
If that didn't help, there's actually a multitude of additional variables that come into play when working with accented characters against an Oracle DB.
Explanation:
Your SQL Developer does recognize accents... provided that you have your Oracle DB session using character set compatible with your database character set. And your Oracle DB session's character set can be set either on OS level (via OS environment variable) or, possibly(!), in SQL Developer's options directly. Alas, the said multitude of other factors may include (though not exclusively):
your OS regional settings,
your OS Unicode support,
your Oracle client software's (SQL Developer) Unicode support,
your Java JDK/JRE's Unicode support,
your JDBC driver's Unicode support,
your other *DBC drivers' Unicode support, if there are any more in chain.
Sad thing is that the more interfaces you have between your keyboard and your Oracle database, the more likely is one of them to fiddle with your charset conversions badly.
So, let's just hope that the first two hints work for you, otherwise I can't help you (that easily).
I have a db2 database where I store names containing special characters. When I try to retrieve them with an internal software, I get proper results. However when I tried to do the same with queries or look into the db, the characters are stored strangely.
The documentation says that the encoding is utf-8 latin1.
My query looks something like this:
SELECT firstn, lastn
FROM unams
WHERE unamid = 12345
The user with the given ID has some special characters in his/her name: é and ó, but the query returns it as Ă© and Ăł.
Is there a way to convert the characters back to their original form with using some simple SQL function? I am new to databases and encoding, trying to understand the latter by reading this but I'm quite lost.
EDIT: Currently sending queries via SPSS Modeler with a proper ODBC driver, the database lies on a Windows Server 2016
Per the comments, the solution was to create a Windows environment variable DB2CODEPAGE=1208 , then restart, then drop and re-populate the tables.
If the applications runs locally on the Db2-server (i.e. only one hostname is involved) then the same variable can be set. This will impact all local applications that use the UTF-8 encoded database.
If the application runs remotely from the Db2-server (i.e. two hostnames are involved) then set the variable on the workstation and on the Windows Db2-server.
Current versions of IBM supplied Db2-clients on Windows will derive their codepage from the regional settings which might not always render Unicode characters correctly, so using the DB2CODEPAGE=1208 forces the Db2-client CLI drivers to use a Unicode application code page to override this.
with t (firstn) as (
values ('éó')
--SELECT firstn
--FROM unams
--WHERE unamid = 12345
)
select x.c, hex(x.c) c_hes
from
t
, xmltable('for $id in (1 to string-length($s)) return <i>{substring($s, $id, 1)}</i>'
passing t.firstn as "s" columns tok varchar(6) path '.') x(c);
C C_HEX
- -----
é C3A9
ó C3B3
The query above converts the string of characters to a table with each character (C) and its hex representation (C_HEX) in each row.
You can run it as is to check if you get the same output. It must be as described for a UTF-8 database.
Now try to comment out the line with values ('éó') and uncomment the select statement returning some row with these special characters.
If you see the same hex representation of these characters stored in the firstn column, then this means, that the string is stored appropriately, but your client tool (SPSS Modeller) can't show these characters correctly due to some reason (wrong font, for example).
I have a problem when inserting values into my Oracle database. I have to insert French characters like à or è and when I try to insert them through an INSERT statement it will convert the character to ¿ or ?.
Is there any possibility to set the encoding of that specific script, or what can I do in this situation ?
Thank you
Usually you would set the character set when you install your database. You can, however, change it post-setup if required (Look up CSALTER). If your database needs to support multiple languages, then you should take a look at this: Supporting Multilingual Databases with Unicode
I have fixed this problem by adding an Environment Variable called NLS_LANG with the value .AL32UTF8 . This worked even though the database has as language American and territory America. The problem that I have faced here was that once I changed the NLS_LANG variable, it started to encode my characters also in the application.
Also you can try to change the encoding of the script that you are running. For example I have used ANSI encoding (you can do it by opening a script in notepad++ and from the Encoding menu, select Convert to ANSI) and it worked properly.
Thank you guys for your help :)
When I query for data that have arabic text in PL/SQL Developer, It is showed as question marks (????).
I am sure the data is correctly stored in DB because it shows on website properly, also on the server.
So I think it is a problem related to my PL/SQL Developer (v8.0.4.1514).
Is there any way to change how PL/SQL Developer shows/encodes arabic text?
How to check in what format/encoding the arabic text is stored?
My question might be missing some details, So Just ask me and also keep in mind that I am very beginner in PL/SQL and in SQL.
Thank you.
I found a solution (which might also work with other languages that shows as '????')
I changed the NLS_LANG in registry to AMERICAN_AMERICA.AL32UTF8
(I found 3 NLS_LANG's in registry, check with each one or just change them all like I did.)
then restarted PL/SQL developer, test a query and arabic text is showing normally.
Thank you all.
can you SET NLS_LANGUAGE to Arabic by ALTER SESSION SET NLS_LANGUAGE = 'ARABIC'
it could be the solution, if not can you provide more information about O/S and it's version, ... etc
There might be multiple instance of oracle installed so you must set default enconding for all of them. Just follow this instructions:
Open reg edit and go to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Oracle. There is one or more keys related to each instance:
For each of this keys right click and create a string value named NLS_LANG if not already there:
Then set it's value to AMERICAN_AMERICA.AL32UTF8 and done just refresh your query in PL/SQL.
in registery find NLS_LANG and change its value from AMERICAN_AMERICA.WE8MSWIN1252 to AMERICAN_AMERICA.UTF8
it works fine for me for persian characters.
I am trying to get unicode strings into an SQL*Plus: Release 10.2.0.2.0 database but am having difficulties. If I use SQLPlus and copy and paste the insert statement into the database, any special characters are inserted as ? or something like that. I then try to call a sql file that has been encoded to UTF-8 and the outcome is the same.
Does anyone know how to get unicode data into database?
Can anyone help . How can i set NLS_LANG option within sqlplus
SQL *Plus is not a database it's a command-line based front-end to a SQL or PL/SQL database. The command-line usually only supports ANSI or ASCI encoded characters. So when you try and paste in the command the program (SQL *Plus) just replaces the text it can't figure out how to encode with "?" marks. You probably need to switch to a different client application to use UTF-8
In my case the problem wasn't in sqlplus but in the environment in that the database was run. After I set
NLS_LANG=RUSSIAN_RUSSIA.UTF8
I could insert unicode characters without any distortion.
Some restarts may be needed for this to take effect (db or OS or both). I run an Oracle XE db in docker so
I had to add -e NLS_LANG=RUSSIAN_RUSSIA.UTF8 to the docker run... command as shown below:
docker run -d --rm -p 49161:1521 --name db -e NLS_LANG=RUSSIAN_RUSSIA.UTF8 -e ORACLE_ALLOW_REMOTE=true wnameless/oracle-xe-11g
Set the NLS_LANG environmental variable to make SQL*Plus understand the character representation you're using.
http://www.sqlsnippets.com/en/topic-13434.html
try to using something around this statement
update pp.pp_employee t
set t.first_name=UNISTR('АБДАЛЛА')
where t.emp_id = 5451 ;