Changing my oracle NLS_Lang environment - oracle

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')

Related

ORA-01861 Error thrown only when published to IIS

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>

NLS_TERRITORY in NLS_SESSION_PARAMETERS is not showing correct value after ORACLE 12C Upgrade

we have recently upgraded our test environment database to 12.2.0.1 from 11.2.0.3.
I see that NLS_TERRITORY value and NLS_LANG value in NLS_SESSION_PARAMETERS is not showing correct value after ORACLE 12C Upgrade.
It should be GERMANY and GERMAN and instead it is AMERICAN and AMERICA and hence some of the query do not show the correct result is terms of currency.
as the parameter "NLS_NUMERIC_CHARACTERS" is dependent of NLS_TERRITORY value.
I see that the NLS_DATABASE_PARAMETERS & NLS_INSTANCE_PARAMETERS, but the NLS_SESSION_PARAMETERS is wrong and hence it is affecting with some of our scripts where we are displaying the numbers.
I do not want to change it via ALTER SESSION and execute the SQL or hardcode in the SQL syntax with the parameter which handles the numbers.
Please let me know if there is any solution for the same so that NLS_SESSION_PARAMETER can be changed.
as the ORACLE DB is reading the PFILE, I have the below values set for NLS parameters are:-
NLS_LANGUAGE = GERMAN
NLS_TERRITORY = GERMANY
nls_length_semantics = char
I found the solution myself, it was a silly environment configuration and somehow reading wrong entry from another profile which is pointed by the actual profile file for the envrionment NLS_LANG.
it was export NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P15
and hence whenever the DB was booting, the NLS session was loaded with the wrong NLS_LANG and NLS_TERRITORY value from this NLS_LANG envrionment variable.
I removed that wrong profile entry and used the NLS_LANG as below:-
export NLS_LANG=GERMAN_GERMANY.WE8ISO8859P15 in the actual profile file such that the DB gets the correct information.
then when I rebooted the DB, the NLS Session values gets fixed by itself and hence I do not have to change something in my scripts and will now work as same as they werr working with previous Oracle version.

Euro '€' symbol not inserted correctly during Oracle SQL LOAD

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.

NLS_NCHAR_CHARACTERSET explanation

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

Hardcoded strings are cut in half with node-oracle

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

Resources