We are using a stored procedure in Oracle 12c to calculate and return some amounts. As we have clients in various countries, we received a requirement to display the amounts as per French Locale format based a a particular environment variable.
Here is the exact issue:
The regular amount format would be like 5,000.00
For this, we use select (TRIM(TO_CHAR('5000','999,999,999,999,999.99') )) from dual;
-->5,000.00
But for French locale, it should be returned like 5 000,00
Please suggest if Oracle provides any functions to support amounts based on Locales than using Replace over the above statement when the locale is French:
select replace(replace((TRIM(TO_CHAR('5000','999,999,999,999,999.99') )),',',' '),'.',',') from dual;
--> 5 000,00
you can set NLS_TERRITORY parameter at a session level:
alter session set nls_territory='FRANCE';
select to_char('5000', 'fm99G999D00') as french
from dual;
Result:
FRENCH
----------
5 000,00
Related
We have an Oracle Database which has many records in it. Recently we noticed that we can not save Persian/Arabic digits within a column with a datatype nvarchar2 and instead of the numbers it shows question marks "?".
I went through this to check the charset using these commands :
SELECT *
from NLS_DATABASE_PARAMETERS
WHERE PARAMETER IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');
and this command
SELECT USERENV('language') FROM DUAL;
The results are these two respectively:
I also issue this command :
SELECT DUMP(myColumn, 1016) FROM myTable;
And the result is like this :
Typ=1 Len=22 CharacterSet=AL16UTF16: 6,33,6,44,6,27,6,45,0,20,0,3f,0,3f,0,2f,0,3f,0,2f,0,3f
The results seem to be okay but unfortunately we still cannot save any Persian/Arabic digit within that column. however the Persian/Arabic alphabets are okay. Do you know what is the cause of this problem ?
Thank You
USERENV('language') does not return your client characters set.
So, SELECT USERENV('language') FROM DUAL; is equal to
SELECT l.value||'_'||t.value||'.'||c.value
FROM (SELECT * FROM NLS_SESSION_PARAMETERS WHERE PARAMETER = 'NLS_LANGUAGE') l
CROSS JOIN (SELECT * FROM NLS_SESSION_PARAMETERS WHERE PARAMETER = 'NLS_TERRITORY') t
CROSS JOIN (SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET') c;
It is not possible to get the client NLS_LANG by any SQL statement (although there seems to be a quirky workaround: How do I check the NLS_LANG of the client?)
Check your client NLS_LANG setting. It is defined either by Registry (HKLM\SOFTWARE\ORACLE\KEY_%ORACLE_HOME_NAME%\NLS_LANG, resp. HKLM\SOFTWARE\Wow6432Node\ORACLE\KEY_%ORACLE_HOME_NAME%\NLS_LANG) or as Environment variable. The Environment variable takes precedence.
Then you must ensure that your client application (you did not tell us which one you are using) uses the same character set as specified in NLS_LANG.
In case your application runs on Java have a look at this: Database JDBC Developer's Guide - Globalization Support
See also OdbcConnection returning Chinese Characters as "?"
Do yourself a favor and convert the main character set of your database from AR8MSWIN1256 to AL32UTF8. Most of these problems will simply go away. You can forget about NCHAR and NVARCHAR2. They are not needed anymore.
It's a one-time effort that will pay back a thounsand times.
See Character Set Migration for instructions.
I got a bug report where Oracle 10g was truncating return values from to_char(datetime):
SQL> select to_char(systimestamp, '"day:"DD"hello"') from dual;
TO_CHAR(SYSTIMESTAMP,'"DAY:"DD"HE
---------------------------------
day:27hel
Notably, this does not appear to happen in Oracle 11g. My question is, why does it happen at all? Is there some configuration variable to set to tell to_char(datetime) to allocate a bigger buffer for its return value?
I'm not sure but it might be just displaying in SQL*Plus. Have you tried to run it in Toad? Or if you assign result to varchar2 in PL/SQL block and output result?
Here what I've found in SQL*Plus Reference for 10g:
The default width and format of unformatted DATE columns in SQL*Plus
is determined by the database NLS_DATE_FORMAT parameter. Otherwise,
the default format width is A9. See the FORMAT clause of the COLUMN
command for more information on formatting DATE columns.
Your values is trimmed to 9 characters which corresponds to default A9 format. I don't have same version and this behaviour is not reproducing in 11g so can you please check my theory?
I've got the same problem and I know the solution.
I use Release 11.2.0.4.0 but I beleave it is possible to repeat the situation in other versions. It somehow depends on client. (E.g. I cannot repeat it using SQL*Plus, only with PL/SQL Devepoper)
Try this:
select to_char(systimestamp, '"day:"DD"йцукенг OR any other UTF-encoded-something"') from dual
union all
select to_char(systimestamp, '"day:"DD"hello"') from dual;
You'll get the following result:
day:08йцукенг OR any other UTF-encoded-so
day:08hello
You can see the "mething" is lost. This is exactly 7 bytes exceeded because of 7 two-byte simbols "йцукенг". Oracle allocates buffer for the number of characters, not a number of required bytes.
The command
alter session set nls_length_semantics=byte/char
unfortunately does not affect this behavior.
So my solution is to cast a result as varchar2(enough_capacity)
select cast(to_char(systimestamp, '"day:"DD"йцукенг OR any other UTF-encoded-something"') as varchar(1000)) from dual
union all
select to_char(systimestamp, '"day:"DD"hello"') from dual
Explicit typecasting makes expression independent from client or configuration.
BTW, the same thing happens in all implicit to_char-conversions. E.g.
case [numeric_expression]
when 1 then '[unicode_containing_string]'
end
Result might be cutted.
We use Oracle 10.2.0.4.0 database, oracle form builder and report builder for creating forms and reports.
Now the problem is in our production database nls_date_format is dd-mon-rr format. When developer create form in developer suit they give dd-mm-rr format at form level and when data stored in table that date format is dd-mm-rr.
Now when developer run form or report within form builder it gives dd-mm-rr format.but when same form or report run from application server side it gives junk characters in month.date and year print same as date format only month display in junk characters.
Hope you all guide well.
There are two issues.
when data stored in table that date format is dd-mm-rr.
This is completely wrong. Oracle doesn't store the date in the format you see, what you see is for display. Oracle stores DATE in an internal proprietary format in 7 bytes with each byte representing different elements of the DATE.
Byte Description
---- -------------------------------------------------
1 Century value but before storing it add 100 to it
2 Year and 100 is added to it before storing
3 Month
4 Day of the month
5 Hours but add 1 before storing it
6 Minutes but add 1 before storing it
7 Seconds but add 1 before storing it
Do not depend on the locale_specific NLS_DATE_FORMAT. Always use:
TO_CHAR to display the date in your desired format
TO_DATE to explicitly convert the string into date.
Remember, TO_DATE is NLS dependent.
If you only have a date element, and if you do not care about the time element, then better use ANSI Date literal which follows a fixed format 'YYYY-MM-DD'.
only month display in junk characters
This is again because you are depending on the NLS_DATE_LANGUAGE. As I said, you should avoid depending on the locale-specific client settings. Explicitly mention the NLS_DATE_LANGUAGE or use ANSI Date literal if you are not concerned about the time element.
For example,
SQL> SELECT TO_CHAR(SYSDATE, 'DD-MON-RR') dt FROM DUAL;
DT
---------
26-OCT-15
SQL> alter session set nls_date_language='french';
Session altered.
SQL> SELECT TO_CHAR(SYSDATE, 'DD-MON-RR') dt FROM DUAL;
DT
-----------
26-OCT. -15
So, what happened above? for a person using FRENCH nls_date_language, the MONTH is showing junk value. Let's make it NLS independent by explicitly mentioning the nls_date_language.
SQL> SELECT TO_CHAR(SYSDATE, 'DD-MON-RR', 'nls_date_language=english') dt FROM DUAL;
DT
---------
26-OCT-15
Also, the NLS_LANG value might not be correctly set in the OS environmental variable. See Why are junk values/special characters/question marks displayed on my client?
I'm calling Oracle procedures that have argument date. How can I specify the format of the date so it is recognized by oracle no matter what kind of globalization it uses ?
E.g.
create or replace procedure MyProc(p_valid_date in date) ...
The client calls the proc, how should I specify p_valid_date as a string ... ?
If I use, e.g., '01212014', i.e. DDMMYYYY then it won't work with US settings. If I use US settings, it won't work in UK. Etc.
In SQL Server, I'd use YYYYMMDD format which is culture invariant but I can't find anything about culture invariant format in Oracle documentation and all kind of formats that I have tried seem to be always bound to the culture.
UPDATE
I don't want to use functions because my client does pure procedure call. That's a limitation of my client. I know that I could change the argument into string and then convert the string using to_date inside the procedure but that seems like a pretty poor design.
Thank you
ISO date format is "invariant" you are looking for:
SQL> alter session set nls_date_format='dd/mon.yyyy';
Session altered.
SQL> select sysdate from dual;
SYSDATE
-----------
07/nov.2014
SQL> select to_char(DATE '2014-12-31') from dual;
TO_CHAR(DAT
-----------
31/dec.2014
You can use this notation: DATE '2014-12-31'
I have a requirement to globalize the application based on culture specified in config file.
I have Amounts and date values .I decided to convert them in query itself.Like below
For Spanish Chile Es-CL:
for Date format is "dd-mm-yyyy" I will use Select TO_CHAR(busdate,'dd-mm-yyyy') from itemTable.
Similarly i want to use same for the amounts Select to_char(Amount,'99.999.99,00') from table1.
But its in vain.
Please suggest me the right way to achive my requirement.
These amounts and date formats can be available.but need to know how to convert them.
I thought to use in On_Data_bound event for datagrids ,but still this will be a performance issue.
You would use the NLS_NUMERIC_CHARACTERS session variable, along with globalized format model:
SQL> alter session set NLS_NUMERIC_CHARACTERS='.,';
Session altered
SQL> select to_char(123456789.01, 'fm999G999G990D00') from dual;
TO_CHAR(123456789.01,
---------------------
123,456,789.01
SQL> alter session set NLS_NUMERIC_CHARACTERS=', ';
Session altered
SQL> select to_char(123456789.01, 'fm999G999G990D00') from dual;
TO_CHAR(123456789.01,
---------------------
123 456 789,01