I have an app build in Oracle APEX 18.2. Every number field in app have missing leading zero. For example when the number is 0.5, APEX displays it as .5. The problem occurs also in SQL Workshop. In SQL Developer numbers with leading zeros are formatted well, so I think this is problem with Oracle APEX, not with Oracle DB. Is there any global setting for number formatting in APEX?
As far as I can tell, there's no such a global setting, which means that you'd have to apply some format mask either
directly (in SELECT statement, within the TO_CHAR function call), or
in column's (item's) property
Format mask you might consider is FM999G990D00 as
FM will remove leading spaces and superfluous trailing zeros
instead of using explicit , and . grouping & decimal characters, use G and D instead
I had an issue adding zeros to numbers, but it was fixed using Function with Oracle Developer
select LPAD((max(ID))+1, 6, '0') from Yourtable
and call it as a function.
Probably you could use PL/SQL expressions to fix it
I had the same issue recently. i fixed it using to_char(xxx,'FM999G990D00')
SELECT mont.period_name AS PERIOD
, to_char(ivo.total_overtime,'FM999G990D00')
, to_char(emho.ACTUAL_TRANSFERRED_HOURS,'FM999G990D00')
, to_char(emho.actual_recup_days,'FM999G990D00')
FROM .....
worked like a charm
I'll assume you have a Classic or Interactive Report, in such case:
Go to page designer and select the column
Go to the format mask option
Select the numeric format you wish to have.
You'll probably get something like 999G999G999G999G990D00
if it has a 9D00 at the end, change the 9 to a 0
Related
I tried to query the Monetdb server. I am printing the columns in the table called Ada and the columns are truncated and only few columns are displayed. On the terminal, it says to avoid dropping or truncating the columns use \w-1 but not sure how to use it in commands.
I am new to use MonetDB so I need some help. Thanks
fram -> Database
The query i used to print columns:
>select * FROM fram.Ada LIMIT 3;
Just type \w-1 in the sql prompt at mclient:
sql>\w-1
Fair warning though the result probably will not look that good. You can see a brief description of all the meta-commands valid in mclient by typing \?. Specifically for \w the description is:
\w# - set maximal page width (-1=unlimited, 0=terminal width, >0=limit to num)
So in order to go back to the previous behavior use \w0, or to format the result to use 120 character columns use \w120.
I solved it by first running
>\w-1
>select * FROM fram.Ada LIMIT 3;
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.
When I try to excecute this:
INSERT INTO [DB_NAME].[dbo].[Table]
([Column])
VALUES('some_hebrew_characters')
I get only questions mark in the column. If I change it to N'some_hebrew_characters' - then it's OK. Why is this happening? How can I translate it to Linq?
How can I make this table to treat all data as Unicode by default? My colum collation is Hebrew_CS_AI, and server is SQL 2008 R2.
Thanks!
---EDIT----
something I just noticed:
even if I run this
SELECT 'some_hebrew_characters'
Im getting questions mark in my results grid
Didn't you forget to mark your column as NVARCHAR also?
Probably that's your editor's default enncoding is not unicode.
To be sure, save your query as a unicode file in SQL SERVER Management Studio and re-run it.
I think if you get results through Linq there would be right.
you need to prefix the '' with the letter N
when inserting a value that contains unicode characters, you need to do this:
insert into table_name(unicode_field) values (N'会意字')
without the N prefix, they'll be passed as ASCII characters.
Also, be sure that the column you're inserting to, supports unicode characters - i.e. nchar, nvarchar, ntext.
Can somebody suggest to me how a number can be displayed using comma separation without using the TO_CHAR function?
NUMBER 3455678.05 should be displayed as 3,455,678.05
NUMBER 3455678 should be displayed as 3,455,678
Without using TO_CHAR(), it's not possible, unless it can be handled in the client program.
For example, in SQL*Plus, you can do:
set numformat 999,999,999,999,999.00
but that's not a complete example, as 3455678.05 would print as 3,455,678.05, but, 3455678 would print as 3,455,678.00.
The correct solution is to use TO_CHAR() function, along with setting NLS_TERRITORY and/or NLS_NUMERIC_CHARACTERS to properly format output.
Hope that helps.
Display formating is something which should be done in your application or presentation layer, not via SQL.
If you insist on doing it, then as Mark J. Bobak says, to_char is your only option.
I have a query that has
... WHERE PRT_STATUS='ONT' ...
The prt_status field is defined as CHAR(5) though. So it's always padded with spaces. The query matches nothing as the result. To make this query work I have to do
... WHERE rtrim(PRT_STATUS)='ONT'
which does work.
That's annoying.
At the same time, a couple of pure-java DBMS clients (Oracle SQLDeveloper and AquaStudio) I have do NOT have a problem with the first query, they return the correct result. TOAD has no problem either.
I presume they simply put the connection into some compatibility mode (e.g. ANSI), so the Oracle knows that CHAR(5) expected to be compared with no respect to trailing characters.
How can I do it with Connection objects I get in my application?
UPDATE I cannot change the database schema.
SOLUTION It was indeed the way Oracle compares fields with passed in parameters.
When bind is done, the string is passed via PreparedStatement.setString(), which sets type to VARCHAR, and thus Oracle uses unpadded comparision -- and fails.
I tried to use setObject(n,str,Types.CHAR). Fails. Decompilation shows that Oracle ignores CHAR and passes it in as a VARCHAR again.
The variant that finally works is
setObject(n,str,OracleTypes.FIXED_CHAR);
It makes the code not portable though.
The UI clients succeed for a different reason -- they use character literals, not binding. When I type PRT_STATUS='ONT', 'ONT' is a literal, and as such compared using padded way.
Note that Oracle compares CHAR values using blank-padded comparison semantics.
From Datatype Comparison Rules,
Oracle uses blank-padded comparison
semantics only when both values in the
comparison are either expressions of
datatype CHAR, NCHAR, text literals,
or values returned by the USER
function.
In your example, is 'ONT' passed as a bind parameter, or is it built into the query textually, as you illustrated? If a bind parameter, then make sure that it is bound as type CHAR. Otherwise, verify the client library version used, as really old versions of Oracle (e.g. v6) will have different comparison semantics for CHAR.
If you cannot change your database table, you can modify your query.
Some alternatives for RTRIM:
.. WHERE PRT_STATUS like 'ONT%' ...
.. WHERE PRT_STATUS = 'ONT ' ... -- 2 white spaces behind T
.. WHERE PRT_STATUS = rpad('ONT',5,' ') ...
I would change CHAR(5) column into varchar2(5) in db.
You can use cast to char operation in your query:
... WHERE PRT_STATUS=cast('ONT' as char(5))
Or in more generic JDBC way:
... WHERE PRT_STATUS=cast(? as char(5))
And then in your JDBC code do use statement.setString(1, "ONT");