One of my field has Data Type as Numeric and the size is (16,8). If I give the value as 0.000000012 will it take and load it in the table? As there are 9 places after the decimal.
It will accept and round the values (at least in 11g):
SQL> CREATE TABLE tst (c1 NUMBER(10,2));
Table created
SQL> INSERT INTO tst VALUES (9.123);
1 row inserted
SQL> INSERT INTO tst VALUES (9.129);
1 row inserted
SQL> SELECT * FROM tst;
C1
------------
9.12
9.13
Related
What is the evaluation of a of value 123.89 in decemial storage in Oracle Databa for NUMBER(3) when there is no scale is defined step by step?
I don't know what Oracle does step-by-step, but - in the end, it rounds the value:
SQL> create table test (col number(3));
Table created.
SQL> insert into test values (123.89);
1 row created.
SQL> insert into test values (200.13);
1 row created.
SQL> select * from test;
COL
----------
124
200
SQL>
Why? Because numbers can have precision and scale. number(3) means that there's no scale (i.e. is equal to number(3, 0)) so - if there's no scale and value you enter exceeds it, then Oracle rounds it.
Read more about NUMBER datatype in documentation.
select standard_hash(‘text’,’MD5’) from dual.
The above script provides md5 hashing in oracle sql developer
But i want to do hashing on my table column and store the result in corresponding field.
I have also tried:
INSERT INTO TABLENAME(MD5)
SELECT standard_hash(TEXT,’MD5’) from TABLENAME
but it is giving error: ORA-01400 cannot insert into null
Normally, the standard_hash will give you an output which you perhaps can't store in the same column you had, because the length won't be the same. To avoid this, I recommend you use raw as data type for the column where you want to store the hash value.
MD5 processes an arbitrary-length message into a fixed-length output of 128 bits, typically represented as a sequence of 32 hexadecimal digits.
SQL> create table test_normal ( c1 varchar2(20) ) ;
Table created.
SQL> insert into test_normal values ( 'AbdiRSDAloPdi8978' ) ;
1 row created.
SQL> select standard_hash(c1) from test_normal ;
STANDARD_HASH(C1)
----------------------------------------
BD6062214847DB31BB40A0185E3F89B0FB6980BF
SQL> alter table test_normal add ( c2 raw(256) );
Table altered.
SQL> update test_normal set c2=standard_hash(c1) ;
1 row updated.
SQL> select * from test_normal ;
C1
--------------------
C2
--------------------------------------------------------------------------------
AbdiRSDAloPdi8978
BD6062214847DB31BB40A0185E3F89B0FB6980BF
SQL> select standard_hash(c1,'MD5') from test_normal ;
STANDARD_HASH(C1,'MD5')
--------------------------------
E404D2867EB21AD65827E2858A07CA65
I have a query on field type varchar2 that works also without apex.
E.g.
SELECT * FROM table WHERE field = 123456
where field is varchar2, and it returns the result and not the
ORA-01722: invalid number.
There is some setting on DB that make it possible? Thankx.
If that column's datatype is varchar2, then enclose its value with single quotes:
SELECT * FROM table WHERE field = '123456'
There's no setting that would "remove" invalid number error, as far as I can tell.
Query you posted works when there are only "numbers" in a table; though, when "something else" (it is a varchar2 after all) is stored in the column, it won't work any more:
Sample table:
SQL> create table test (id number, field varchar2(10));
Table created.
Numbers only:
SQL> insert into test (id, field) values (1, 123456);
1 row created.
SQL> select * from test where field = 123456;
ID FIELD
---------- ----------
1 123456
Enter value that contains e.g. letters in field:
SQL> insert into test (id, field) values (2, 'ABC');
1 row created.
SQL> select * from test where field = 123456;
ERROR:
ORA-01722: invalid number
no rows selected
SQL>
So, it is not "Apex" to blame, but you who tried to misuse what you have.
i have a transaction form in oracle apex within that form has a page item called transactioncode.
what i will like, is to generate a alphanumeric code on page load for eg. AA110 which will increment everytime they create a new transaction.
table: transactioncode, transactiondate, productcode, productname.
I have not tried any sql or pl/sql or trigger
You can use a SEQUENCE and assign the sequence.nextval to the field transactioncode or define the field as IDENTITY if you are using 12.1 onwards. If your version is prior to 12.1, then you need a trigger to associate the sequence.
Example below will show you column c1 as identity, column c2 using sequence
SQL> create sequence my_example start with 1000 increment by 1 maxvalue 9999999999999999 ;
Sequence created.
SQL> create table my_test ( c1 NUMBER GENERATED BY DEFAULT AS IDENTITY , c2 number default my_example.nextval , c3 varchar2(1) ) ;
Table created.
SQL> insert into my_test ( c3 ) values ( 1 ) ;
1 row created.
SQL> commit;
Commit complete.
SQL> select * from my_test ;
C1 C2 C
---------- ---------- -
1 1000 1
The following restrictions applied to IDENTITY fields
One identity column per table.
Identity columns must be numeric types, and can't be user-defined
data types.
Identity columns can't have a default clause.
Identity columns are implicitly have NOT NULL and NOT DEFERRABLE constraints.
They can't be explicitly alter to anything else. From the doc, "If an
identity column is encrypted, then the encryption algorithm may be
inferred. Oracle recommends that you use a strong encryption
algorithm on identity columns."
The CREATE TABLE ... AS SELECT will not inherit the identity property on a column. This is true for several structural definitions. If you care about structure, you
should always CREATE TABLE, then use INSERT INTO ... SELECT to
populate it.
We have Oracle as source and HANA 1.0 sps12 as target. We are mirroring Oracle to HANA with Informatica CDC through real-time replication. In Oracle, for many columns we have datatype as CHAR i.e. fixed length datatype. As HANA officially doesn't support CHAR datatype so we are using NVARCHAR data type instead of same. Problem we are facing is -as in Oracle CHAR datatype is of fixed length and append spaces whenever actual string is of lesser length than datatype, we have lot of extra spaces in target HANA db for such columns.
For eg. If column col1 has data type
CHAR(5)
and value as 'A', it is replicated in HANA as 'A ' i.e. 'A' appended by four extra spaces, causing lot of problems in queries and data interpretation
Is it possible to implement CHAR like datatype in HANA?
You can use RPAD function in Informatica while transferring data to Hana. Just make sure if Hana doesn't trim automatically.
So, for the CHAR(5) source column you should use:
out_Column = RPAD(input_Column, 5)
Pretty much exactly, as the documentation says:
I don't know HANA and this is more a comment than an answer, but I chose to put it here as there's some code I'd like you to see.
Here's a table whose column is of a CHAR datatype:
SQL> create table test (col char(10));
Table created.
SQL> insert into test values ('abc');
1 row created.
Column's length is 10 (which you already know):
SQL> select length(col) from test;
LENGTH(COL)
-----------
10
But, if you TRIM it, you get a better result, the one you're looking for:
SQL> select length( TRIM (col)) from test;
LENGTH(TRIM(COL))
-----------------
3
SQL>
So: if you can persuade the mirroring process to apply TRIM function to those columns, you might get what you want.
[EDIT, after seeing Lars' comment and re-reading the question]
Right; the problem seems to be just the opposite of what I initially understood. If that's the point, maybe RPAD would help. Here's an example:
SQL> create table test (col varchar2(10));
Table created.
SQL> insert into test values ('abc');
1 row created.
SQL> select length(col) from test;
LENGTH(COL)
-----------
3
SQL> insert into test values (rpad('def', 10, ' '));
1 row created.
SQL> select col, length(col) len from test;
COL LEN
---------- ----------
abc 3
def 10
SQL>