We are trying to store the values in a table which has a column of "Number" Datatype. The problem arises when we store a very small value , like "0.000001.
SQL> desc testing
Name Type Nullable Default Comments
---- ------ -------- ------- --------
A NUMBER Y
SQL> insert into testing values (0.00000001);
1 row inserted
SQL> select * from testing;
A
----------
0.001
1E-5
1E-8
0.0001
Is there a way, we can store and retrieve the absolute values, as in store, 0.00001 instead of 1E-5.
It is simply a DISPLAY issue. Set numformat properly.
For example,
SQL> create table t(a number);
Table created.
SQL> insert into t values(0.000000000000001);
1 row created.
SQL> select * from t;
A
----------
1.0000E-15
SQL> set numformat 9D9999999999999999
SQL> select * from t;
A
-------------------
.0000000000000010
SQL>
Update OP says the above didn't fix the issue when trying to send the number value to the application frontend. There must be something wrong with the locale-specific NLS settings that is being used by the application.
If the issue is with just the display, then you could convert it to char using to_char and proper format model.
SQL> create table t(a number);
Table created.
SQL> insert into t values(.000000000000000000001);
1 row created.
SQL> select * from t;
A
----------
1.0000E-21
SQL> select ltrim(to_char(a, '9999999D999999999999999999999', 'NLS_NUMERIC_CHARACTERS = ''.,''')) num from t
NUM
------------------------------
.000000000000000000001
SQL>
Note the use of ltrim.
Related
How to change date format '17.DEC.80' to '17.12.80' in Run SQL Command Line SCOTT Database?
It depends on what 17.DEC.80 actually is; if it is a string, then to_date it first (using appropriate format model), and then apply to_char with the final format:
SQL> select to_char(to_date('17.DEC.80', 'dd.mon-yy'), 'dd.mm.yy') like_this from dual;
LIKE_THI
--------
17.12.80
SQL>
If it is a date datatype value, then just to_char it, e.g.
SQL> create table test (col date);
Table created.
SQL> insert into test values (date '1980-12-17');
1 row created.
SQL> select col from test;
COL
---------
17-DEC-80
SQL> select to_char(col, 'dd.mm.yy') like_this from test;
LIKE_THI
--------
17.12.80
SQL>
Or, alter session to set format model:
SQL> alter session set nls_date_format = 'dd.mm.yy';
Session altered.
SQL> select * from test;
COL
--------
17.12.80
SQL>
Though: we've had Y2K issue 20 years ago and learnt that 2-digits years should be avoided. I suggest you do that as well and use 4 digits for years.
I have been trying to use different functions on clob datatype in oracle 19.3.0.0 and none of them return values.
eg : -
dbms_lob.getlength(clob_data)
However any kind of functions on clob/blob datatype doesn't return values
length(clob_data)
These functions have been working fine previously in Oracle 12c. I recently upgraded to Oracle 19.3.0.0. Please educate me if there is any work around for this.
If you don't want to insert anything in clob column you should use empty_clob function
Test case
SQL> create table test1 (id number,a clob);
Table created.
SQL> insert into test1 values (&id,&a);
Enter value for id: 1
Enter value for a: null
1 row created.
SQL> /
Enter value for id: 2
Enter value for a: empty_clob()
1 row created.
SQL> commit;
Commit complete.
SQL> select id,dbms_lob.getlength(a) length from test1;
ID LENGTH
---------- ----------
1
2 0
I need to increase a column length in oracle table. But there is type defined on same table inside a package specification. This package is being used in more than 1000 packages.
So when I alter column, all packages become invalid.
Is there a way, so I can increase column length without making dependent type invalid.
Thanks.
You don't need to do anything; Oracle will recompile (or, at least try to do so) those packages and make them VALID (unless something else prevents that).
Here's a simple demonstration.
Test case first:
SQL> create table test (name varchar2(5));
Table created.
SQL> insert into test
2 select 'Littl' from dual union all
3 select 'Foot' from dual;
2 rows created.
SQL> create or replace package pkg_test as
2 function f_test return test.name%type;
3 end;
4 /
Package created.
SQL> create or replace package body pkg_test as
2 function f_test return test.name%type is
3 retval test.name%type;
4 begin
5 select max(name) into retval from test;
6 return retval;
7 end;
8 end;
9 /
Package body created.
SQL>
Let's check package's status and see function's result:
SQL> select object_name, status From user_objects where object_name = 'PKG_TEST';
OBJECT_NAM STATUS
---------- -------
PKG_TEST VALID
PKG_TEST VALID
SQL> select pkg_test.f_test from dual;
F_TEST
--------------------------------------------------------------------------------
Littl
SQL>
Everything is OK.
Now, enlarge the column and see what happens:
SQL> alter table test modify name varchar2(10);
Table altered.
SQL> select object_name, status From user_objects where object_name = 'PKG_TEST';
OBJECT_NAM STATUS
---------- -------
PKG_TEST INVALID
PKG_TEST INVALID
SQL> select pkg_test.f_test from dual;
F_TEST
--------------------------------------------------------------------------------
Littl
SQL> select object_name, status From user_objects where object_name = 'PKG_TEST';
OBJECT_NAM STATUS
---------- -------
PKG_TEST VALID
PKG_TEST VALID
SQL>
See? It just works. Package was initially INVALID, was recompiled in the background and became VALID.
So, no worries. I'd just say congratulations you decided to declare everything so that it inherits column's datatype. If you hardcoded it, then you'd have a BIG problem in manually modifying all those variables, whatnot, to make everything work.
You can check online table redefinition in which case only affected column's dependent objects will become invalid. For example if the column you are altering is not dependant on the type in the same table declared in packages then those packages will remain valid.Even for normal alter command this condition applies but online redefinition allows using a interim table to support dml operations during the alterations
Anyway since it is a production system I suggest testing this feature in UAT and then work it out in production
create table T_XXX
(
DATE_POST VARCHAR2(8) NOT NULL,
DATE_GET DATE DEFAULT TO_DATE(SUBSTR("DATE_POST",1,8),'YYYYMMDD')
);
Error:
ORA-00904:"DATE_POST"
Why does this happen?
My Oracle version is 12c
Nope, that won't work.
But, as you're on 12c, create a virtual column. For example:
SQL> alter session set nls_Date_format = 'dd.mm.yyyy';
Session altered.
SQL> create table test
2 (date_post varchar2(8),
3 date_get date generated always as (to_date(date_post, 'yyyymmdd'))
4 );
Table created.
SQL> insert into test (date_post) values ('20200501');
1 row created.
SQL> select * From test;
DATE_POS DATE_GET
-------- ----------
20200501 01.05.2020
SQL>
When i'm using FML999G999G999G999G990D00 as my Number Format Mask in Oracle Apex, it shows Value as $800.00. I need to Replace $ with another Currency Sign.
How Could i do this ?
You need to modify the session parameter NLS_CURRENCY to change the currency:
SQL> ALTER SESSION SET NLS_CURRENCY='EUR';
Session altered.
SQL> SELECT to_char(800, 'FML999G999G999G999G990D00') FROM dual;
TO_CHAR(800,'FML999G999G999G999G9
---------------------------------
EUR800,00
Or with DBMS_SESSION:
SQL> BEGIN dbms_session.set_nls('NLS_CURRENCY', 'GBP'); END;
2 /
PL/SQL procedure successfully completed.
SQL> SELECT to_char(800, 'FML999G999G999G999G990D00') FROM dual;
TO_CHAR(800,'FML999G999G999G999G9
---------------------------------
GBP800,00
You can also specify the currency directly with TO_CHAR:
SQL> SELECT to_char(800, 'FML999G990D00', 'NLS_CURRENCY=''£''') FROM dual;
TO_CHAR(800,'FML999G9
---------------------
£800,00