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>
Related
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.
I need to format a string ot date including abbreviated strings.
I tried with:
to_date('Fri Jul 24', 'DY MON DD')
It doesn't work, I figured it was because my oracle NLS parameters are set to French I have no idea why:
SELECT * FROM V$NLS_PARAMETERS
----------------------
NLS_LANGUAGE FRENCH
NLS_TERRITORY FRANCE
NLS_CURRENCY €
NLS_ISO_CURRENCY FRANCE
NLS_NUMERIC_CHARACTERS ,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD/MM/RR
NLS_DATE_LANGUAGE FRENCH
NLS_CHARACTERSET AL32UTF8
NLS_SORT FRENCH
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_NCHAR_CHARACTERSET AL16UTF16
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
So of course I tested the french conversion:
to_date('Vendredi Juillet 24', 'DAY MONTH DD')
This works. Then I tried the abbreviated version:
to_date('Ven Jui 24', 'DY MON DD')
which does NOT work.
Anyway, I ma interested in the English conversion, so I should start by switching my NLS from French to English. How do I do that?
I followed those steps from this link: http://docs.oracle.com/cd/E12102_01/books/AnyInstAdm784/AnyInstAdmPreInstall18.html, but without any success.
Any idea?
Refer rather to this link if you want to change - and first understand how they work - NLS parameters:
http://docs.oracle.com/cd/E11882_01/server.112/e10729/ch3globenv.htm#i1005949
NLS parameters can be specified in the following ways:
As initialization parameters on the server
You can include parameters in the initialization parameter file to specify a default session NLS environment. These settings have no effect on the client side; they control only the server's behavior. For example:
NLS_TERRITORY = "CZECH REPUBLIC"
2. As environment variables on the client
You can use NLS environment variables, which may be platform-dependent, to specify locale-dependent behavior for the client and also to override the default values set for the session in the initialization parameter file. For example, on a UNIX system:
% setenv NLS_SORT FRENCH
3. With the ALTER SESSION statement
You can use NLS parameters that are set in an ALTER SESSION statement to override the default values that are set for the session in the initialization parameter file or set by the client with environment variables.
ALTER SESSION SET NLS_SORT = FRENCH;
4. In SQL functions
You can use NLS parameters explicitly to hardcode NLS behavior within a SQL function. This practice overrides the default values that are set for the session in the initialization parameter file, set for the client with environment variables, or set for the session by the ALTER SESSION statement. For example:
TO_CHAR(hiredate, 'DD/MON/YYYY', 'nls_date_language = FRENCH')
Notice that the session NLS parameters on the client (not servers' parameters) decide how conversions work in your SQL statements. The client can derive it's own NLS parameters from the server, but it doesn't have to do it. For example in SQL Developer you can set NLS parameters of your session in the menu under Tools/Preferences/Database/NLS option, but default settings are usually derived from your PC (for example from MS-Windows language settings or NLS_LANG environment variable, if exists).
Each client has it's own specific method to set these parameters, you must refer to documentaton of your client.
It makes sense, because for example imagine that the server is located in France and has NLS settings = 'France', but the first client is connecting from America, and the second one from Norway - the first client want to see American dates, so it sets NLS parameters on it's client to NLS = 'America. The second client sets it's language settings to NLS = 'Norway" an it sees dates in local approtirate format.
You can always change NLS settings in your session, regardless of the client, using ALTER SESSION command.
The abbreviated French form is Ven. Juil. 24 the periods appear to be integral.
You can change the date language of the TO_DATE and TO_CHAR functions by supplying the optional 3rd argument e.g.:
to_char(sysdate,'Dy Mon dd','NLS_DATE_LANGUAGE = FRENCH')
to_char(sysdate,'Dy Mon dd','NLS_DATE_LANGUAGE = AMERICAN')
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
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