Web-browser displays specific Norwegian symbols incorrectly.
configuration of DB:
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_CHARACTERSET WE8ISO8859P1
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
Is the problem in NLS_CHARACTERSET?
If the database hasn't been set up to use a multi-byte characterset, or a single character byteset compatible with those Norwegian characters, then nothing the client can do can fix that.
But you can try setting the environment variables and see whether it works
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
export NLS_LANG
Looks like the database is set up for a US based character set. It is single byte "WE8ISO8859P1" and not aimed at Norwegian.
Modern apps (and Web browsers) generally use UTF-8 so there is going to be a loss of information when converting UTF-8 data to a single byte character set.
I think, for the long run, you'd be best off trying to get the database converted.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/toc.htm
Related
I'm having a problem after published a ASMX webservice that querys a OracleDB using Oracle.ManagedDataAccess.
When I debug the webservice, calling the respective WebMethod, I can run the oracle sql query with no problems! But when I publish it to my IIS 7 server and call the refered WebMethod I get ORA-01861 error.
The obvious answer would be the PL/SQL syntax has a "TO_DATE" function not well-formed... but how come I can run it in debug in my laptop?!?
Both debug laptop and IIS Server are 64bit. And Oracle.ManagedDataAccess dll is 64bit. Already enabled "Enable 32bit Applications" in IIS, already checked that the assembly is correctly registered in GAC_64 of my IIS server.
Runing out of ideas…
Any help would be much apretiated.
I presume NLS settings in databases on your laptop and on the server are different. The one on the laptop matches date format you provide (as a string), but the one on the server doesn't match, Oracle is unable to implicitly convert it to a correct format and thus returns an error.
So - compare those settings. Query NLS_SESSION_PARAMETERS, NLS_INSTANCE_PARAMETERS and NLS_DATABASE_PARAMETERS, such as
SQL> select * From nls_session_parameters;
PARAMETER VALUE
------------------------------ -----------------------------------
NLS_LANGUAGE CROATIAN
NLS_TERRITORY CROATIA
NLS_CURRENCY kn
NLS_ISO_CURRENCY CROATIA
NLS_NUMERIC_CHARACTERS ,.
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD.MM.RR
NLS_DATE_LANGUAGE CROATIAN
NLS_SORT CROATIAN
NLS_TIME_FORMAT HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT DD.MM.RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT DD.MM.RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY kn
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
17 rows selected.
SQL>
I am trying to connect power Bi with Oracle DB 12c via ODBC, but the arabic characters displays as (??? question marks). I have checked the database in sql developer and it was displayed fine.
I have changed the CHARACTER SET to AR8ISO8859P6 just in case
SQL> SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET' ;
VALUE$
--------------------------------------------------------------------------------
AR8ISO8859P6
and the sdl_lang on registry to AMERICAN_AMERICA.AR8MSWIN1256
SQL> SELECT * FROM NLS_DATABASE_PARAMETERS;
PARAMETER
--------------------------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_RDBMS_VERSION
12.2.0.1.0
NLS_NCHAR_CONV_EXCP
FALSE
NLS_LENGTH_SEMANTICS
BYTE
PARAMETER
--------------------------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_COMP
BINARY
NLS_DUAL_CURRENCY
$
NLS_TIMESTAMP_TZ_FORMAT
DD-MON-RR HH.MI.SSXFF AM TZR
PARAMETER
--------------------------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_TIME_TZ_FORMAT
HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_FORMAT
DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_FORMAT
HH.MI.SSXFF AM
PARAMETER
--------------------------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_SORT
BINARY
NLS_DATE_LANGUAGE
AMERICAN
NLS_DATE_FORMAT
DD-MON-RR
PARAMETER
--------------------------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_CALENDAR
GREGORIAN
NLS_NUMERIC_CHARACTERS
.,
NLS_NCHAR_CHARACTERSET
AL16UTF16
PARAMETER
--------------------------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_CHARACTERSET
AR8ISO8859P6
NLS_ISO_CURRENCY
AMERICA
NLS_CURRENCY
$
PARAMETER
--------------------------------------------------------------------------------
VALUE
----------------------------------------------------------------
NLS_TERRITORY
AMERICA
NLS_LANGUAGE
AMERICAN
20 rows selected.
and the sql developer is fine the arabic is display correct
but when I connect power bi with oracle db it displays the arabic as ????
how can I fix this issue?
UPDATE: Change Windows Region To Arabic:
I have changed windows to Arabic Even on power Bi region setting still not Arabic not displayed correct
I got the same problem and I saw two alternatives:
Replace ODBC to a Oracle Driver connection (best solution, because it resolves automatic updates issues in a report server)
Set enviroment variable NLS_LANG in your SO to the same DB parameter value.
Good day. I try to retrieve russian characters with Oracle db. I try to set env. variables, change NLS_LANG in preferences of the SQL Developer... And what i have now:
PARAMETER VALUE
------------------------------ ----------------------------------------------------------------
NLS_LANGUAGE RUSSIAN
NLS_TERRITORY RUSSIA
NLS_CURRENCY ¿.
NLS_ISO_CURRENCY RUSSIA
NLS_NUMERIC_CHARACTERS .,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD.MM.RR
NLS_DATE_LANGUAGE RUSSIAN
NLS_SORT RUSSIAN
NLS_TIME_FORMAT HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT DD.MM.RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT DD.MM.RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY ¿.
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
17 rows selected
COL1 COL2
---------- --------------------------------------------------
¿¿¿¿ ¿¿¿¿¿¿¿¿¿¿¿ ¿¿¿¿ ¿ ¿¿¿¿¿¿¿¿¿¿
Your database character set cannot encode cyrillic characters, so you won't be able to store them in the database.
You have two options:
Create a new database with character set AL32UTF8. This is the better option.
Create the fields that are to contain cyrillic characters as NVARCHAR.
I must start that I am not Oracle user expert so I have some problems undestanding the basics :D. Our application is an MVC one with Nhibernate db connection. Problem lies when we try to save a characters like 'ѼóÂ' into a NVARCHAR2 field, they are saved as a question mark '?'. To fix this we changed to a different charset in database.
Here are our nls_database_parameters at installation:
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET EE8ISO8859P2
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
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 10.2.0.4.0
Originaly NLS_CHARSET was EE8ISO8859P2 and we changed it to: AL32UTF8 (works perfectly). Question is isn't NLS_NCHAR_CHARACTERSET suposed to handle those special characters for fields like nvarchar2 ? If no then can someone please explain to me the its purspose?
Edit: NLS_LANG is set to: POLISH_POLAND.AL32UTF8
National characterset was used in earlier times, i.e. before Unicode was available. The main idea was to have the common characterset where you store language independent items (include any source codes, etc.) for VARCHAR2/CHAR and have a customer-specific, i.e. language specific national characterset for NVARCHAR2/NCHAR.
In my opinion there is no reason to use it nowadays, since AL32UTF8 (or any other Unicode coding) is able to store any character anyway.
Maybe when you work in non-western languages a national characterset like AL16UTF16 or AL32UTF32 are slightly beneficial in terms of storage and efficiency.
Regarding you question: National Characterset AL16UTF16 is able to store any Unicode character, so your polish characters should be no problem. However, maybe your client applications (or the selected font) is not able to display such characters
I use node-oracle to connect to an Oracle db.
When I select values from tables with cyrillic data, everything is fine, but if I call a procudure like this:
CREATE OR REPLACE PROCEDURE TEST_ENCODING (CUR OUT SYS_REFCURSOR) AS
BEGIN
open cur for
select 'тест' as hello from dual; -- cyrillic hardcoded text
END TEST_ENCODING;
and then call it from node:
connection.execute("call TEST_ENCODING(:1)", [new oracle.OutParam(oracle.OCCICURSOR)],
function (err, result) {
console.log(result)
}
);
Result is:[ { HELLO: 'те' } ] (the string is cut in half).
The database is configured as follows:
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET CL8MSWIN1251
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
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 11.2.0.3.0
In my local env: NLS_LANG=AMERICAN_AMERICA.UTF8
(also tried NLS_LANG=RUSSIAN_RUSSIA.UTF8 and RUSSIAN_RUSSIA.AL32UTF8 with same results)
My configuration:
Mac OS X 10.9
Oracle Client 11.2
node 0.10.22
node-oracle 0.3.4
Seems that for now there are no support for encodings other then UTF8 in node-oracle because node.js dosn't support native encodings (proof).
To handle strings properly you need to set NLS_LANG parameter on the client to same value as in database (CL8MSWIN1251)
So, you can choice from 2 variants:
A) Migrate database to UTF8 encoding.
B) Patch node-oracle source to convert strings and CLOBs to UTF8 before returning it content to node.js and applying conversion from UTF8 to CL8MSWIN1251 before passing it to Oracle. OCI interface have a functions for such conversions. E.g. for your local purpose it's enough to patch OBJ_GET_STRING macro in utils.h
P.S. node-oracle looks very simplistic at the moment, so be prepared for many surprises (e.g. no support for BLOBs and collections, lack of connections settings and so on).
It could be because your database primary charset is CL8MSWIN1251, when local setting specifies UTF8.
NLS_CHARACTERSET CL8MSWIN1251
The variable NLS_LANG specifies how to interpret your local environment
NLS_LANG = language_territory.charset
The last part of NLS_LANG provides information about local charset and it is used to let Oracle know what character set you are USING on the client side, so Oracle can do the proper conversion. Probably, values from tables are converted properly, when charset of value from dual table is not identified correctly.
Please try to set NLS_LANG variable to AMERICAN_AMERICA.CL8MSWIN1251 (or RUSSIAN_RUSSIA.CL8MSWIN1251, it doesn't really matter)
are you sure that your source code has UTF-8 character set?
if problem only with hardcoded symbols maybe your GUI for Oracle development do not support UTF-8
I have similar problem with special characters like ¥ in my package and sql*plus that convert special characters into some unreadable