I'm trying to create a report that can switch between English and (Canadian) French number formatting (1,234.56 vs 1 234,56) but am having some troubles.
Before I get into what I have tried I'd like to say that in the past we have always converted the French number to a character, and than made the appropriate string modifications there, but this obviously isn't the best solution and I'm trying to find something better going forward.
The first thing I tried doing was adding the following line to the BEFORE REPORT trigger in the Oracle Report itself:
srw.do_sql ('alter session set nls_numeric_characters = '', ''');
I have my number fields set up with the format mask "(NNNGNNNGNN0D00)" so I would assume the G's and D would use the session's NLS_NUMERIC_CHARACTERS setting but they don't seem to.
To see if the setting was actually changing I created the following query in the report and displayed it's output:
select value from nls_session_parameters
where parameter = 'NLS_NUMERIC_CHARACTERS';
Sure enough the output changed from '.,' to ', ' using my alter session command.
After researching some more online I read that the change really needs to be made in the Oracle Report Server configuration as per this documentation - http://docs.oracle.com/cd/B14099_19/bi.1012/b14048/pbr_conf.htm#i1013352
I contacted the team responsible for our Oracle Application Server and had them try inserting the configurations we need to set up English and French number formatting and they added in the following:
<environment id="EN">
<envVariable name="NLS_LANG" value="AMERICAN_AMERICA.WE8ISO8859P1"/>
</environment>
<environment id="FR">
<envVariable name="NLS_LANG" value="FRENCH_CANADA.WE8ISO8859P1"/>
<envVabiable name="NLS_NUMERIC_CHARACTERS" value="', '"/>
</environment>
The report server was restarted and I entered in the URL to request the report, along with the ENVID=FR parameter, but still no luck. The report runs but the number formatting is still using the ,'s and .'s for grouping and decimal separation.
Does anyone know what we're missing or what else we could try?
I had the same issue and did to_char() where that NLS format needs to apply.
Related
I need help. is there a setting to allow the display of timestamps in tables?
the database is part of my job however a senior analyst of mine queried the same code and his managed to show the timestamps next to the date, mine doesnt. he told me there is a setting and asked me to search on my own.
I am using Version 4.1.2.20 of Oracle SQL Developer Build MAIN-20.64
Here is the table
Some GUI have their own settings for things like timestamp formats, and they ignore your NLS settings. (I find that quite annoying. Toad does that, among others.)
SQL Developer is good: it has such settings (you can hunt them down and use them), but you can also change them with standard SQL statements. What you need is something like
alter session set nls_timestamp_format = 'yyyy-mm-dd hh24:mi:ss.ff6';
(assuming you need six decimal places for the second, and the format model is the one you need). Use whatever format you require; but only fools (including, alas, Oracle itself!) use two-digit numbers for the year.
Something to pay attention to though: what is the data type of column created_dt? If it is date, for example, you will need to change nls_date_format (which doesn't take decimals for seconds); if it's timestamp with time zone then you will need to give a format including time zone elements, and you will need to change nls_timezone_tz_format.
You can also find these settings (and change them directly there - the valid formats are the same) in SQL Developer under
>> Tools >> Preferences >> Database >> NLS
I made a simple query to a remote database. The table where I make query has all fields with VARCHAR2. However, some fields returns "?" in characters like º, £. I checked enconding and get:
NLS_CHARACTERSET: AL32UTF8
NLS_NCHAR_CHARACTERSET:AL16UTF16
Checking my /etc/default/locale file. These are the results:
LANG="en_US.UTF-8"
LC_NUMERIC="pt_BR.UTF-8"
LC_TIME="pt_BR.UTF-8"
LC_MONETARY="pt_BR.UTF-8"
LC_PAPER="pt_BR.UTF-8"
LC_NAME="pt_BR.UTF-8"
LC_ADDRESS="pt_BR.UTF-8"
LC_TELEPHONE="pt_BR.UTF-8"
LC_MEASUREMENT="pt_BR.UTF-8"
LC_IDENTIFICATION="pt_BR.UTF-8"
The enconding from both edges are UTF-8. Is there another configuration that I missing?
When you say 'some fields return "?" in characters like ...' I assume that is shown on your screen, right? You don't know what is REALLY returned, you only know what's on your screen.
To see what is REALLY returned, you could do something like
select dump('£500') from dual;
DUMP('£500')
--------------------------
Typ=96 Len=4: 163,53,48,48
EDIT: As discussed in the comments below, if you type EXACTLY that command at your terminal and you do, in fact, have a display problem, you will see garbage on the way in. Rather, to see what is stored in the database, you must refer to an actual table, and a column that has those string values in it. For example if the column name is COL1 in the table TBL, and there is also an ID column and for ID = 1000 you have a COL1 value with the pound sign in it, run
select dump(COL1) from TBL where ID = 1000;
Obviously, there are no issues with the INPUT since the input no longer has a pound sign in it (like my first example did). But on the way out, the DUMP may show the proper character is there - however your display is not able to show it correctly.
END EDIT
If you see the code 163 in the DUMP, that means the pound sign is stored correctly in the database, and the issue is just how it is displayed on your screen. In that case, you may have an issue with your NLS_LANG setting. There is excellent information here:
http://www.oracle.com/technetwork/products/globalization/nls-lang-099431.html
If you find that you have to work with different character sets often, you may benefit from reading this article carefully. It will show you how to find out what your current character set is, how to change it, and why the "obvious" things one would look at are in fact not very helpful. The issue is not too complicated, but not trivial either.
When I change the encoding in my browser(s), the controls in the cart change accordingly when I have extended chars.
However, it is not consistent and looks very amateurish. See the attached comparison image.
How do I fix this in Magento 1.4.0.1? Or, is it a browser issue, and if so, how do I fix it?
How did you create your MySQL server? When you didn't set correct collation while creating a database, you can always face of troubles. Try following :
mysql > CREATE DATABASE sample DEFAULT CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI;
UT8_UNICODE_CI has many character sets.
I'm having trouble with the number formatting in Apex 3.2.1. NLS_TERRITORY is set to GERMANY, NLS_LANGUAGE to GERMAN. However, the default number formatting is wrong and I would like to fix/change it. I'm wondering why there is an application date format setting but no application number format setting. That would have been really helpful right now. So my question is: how can I set a new number format which will be applied everywhere in my application? Is it possible? If not, what would be the least painful way to to apply the new format mask. I'm mainly concerned with interactive reports. Additionally, if it were possible to change the default format mask for the territory in some configuration file, that would also be an option. Thanks for your input in advance.
Edit:
My problem with the default format is that numbers like 0.34 are being displayed as ",34", but the correct output would be "0,34".
Okay, purely the display then. I don't think there is an easy way to do this for all your fields, but specifying a format mask on those fields, by using for example FM999G999G990D000.
That would be annoying for a lot of fields across the application though, i agree. It is even more annoying when only by specifying a format mask, items are recognised as being number fields. Maybe making a plugin, which is identical to a number field, but with a default format mask may do the trick.
Or query the apex views to find items, then update them (though you will need access to the 'internal' tables of apex, the wwv_* things).
select application_name, page_id, page_name, item_name, display_as, display_as_code, format_mask from apex_application_page_items where page_id = 6
Which you could then transform into an update...
I've nothing else to offer, so far i've always specified the format mask during development...
Putting a parameter into the query gets the following error:
"ORA-01036: illegal variable name/number"
The query is:
select * from t_accounts where account_number = #ReportParamter1
Without the where clause, the query runs fine
Any ideas?
thanx!
Abraham
Oracle wants its bound parameters to be denoted with colons, not # signs.
So you want
...where account_number = :ReportParamter1
O. Jones highlighted the root but didn't go into as much detail as I needed to address this same issue/question. I had created the parameter in Visual Studio and as noted it has the '#' in the format of the parameter so when applied to the Dataset I got the error message. Unfortunately in the construct of the parameter in VS (I'm using 12) there isn't anything in the various options that allows designating a : in place of the #. What I discovered was after manually adding the parameter to my query in the Dataset, I then found it listed in the parameters area of the Dataset Properties - the parameter entered in query was set to the parameter made in VS. I removed the original and preview processed without issue.