I need to cast a varchar to a float. (The varchar is guaranteed to be a number)
I'm trying to create a materialized view on top of a pre-built table. Because of this, all the data types must match exactly...including the precision and size of the data types. The original column (before the NVL was added) was pulling from a FLOAT data type with a precision of 126. When I try casting a varchar to a float of a precision of 126 it doesn't seem to include the 126 data precision.
(I tested the fact that it wasn't including the 126 data size by creating a standard view with the below query that casts to float(126). Through my Toad IDE I could see that the precision of the "ThisorThat" float column was 38).
I have simply updated my materialized view with a NVL statement like so...
Select Cast(NVL(thisFloat, thatFloat) as Float(126)) as ThisorThat
....
From tables;
I get the error "Ora-12060: shape of prebuilt table does not match definition query" because the sizes are different than the original table that I am "pre-building" upon. I need to somehow cast the varchar to a float with an explicit size of 126. Any ideas?
Version: Oracle 10g
Edit:
Here's a link which is basically the same thing I'm encountering.
Use
TO_BINARY_FLOAT(mynumberstring)
or
TO_BINARY_DOUBLE(mynumberstring)
What you're trying to do actually isn't a cast, it's a conversion.
Related
Creating a mySomeTable table with 2 fields
create table mySomeTable (
IDRQ VARCHAR2(32 CHAR),
PROCID VARCHAR2(64 CHAR)
);
Creating an index on the table by the PROCID field
create index idx_PROCID on mySomeTable(trunc(PROCID));
Inserting records:
insert into mySomeTable values ('a', '1'); -- OK
insert into mySomeTable values ('b', 'c'); -- FAIL
As you can see, an error has been made in the index construction script and the script will try to build an index on the field using the trunc() function.
trunct() is a function for working with dates or numbers, and the field has the string type
This index building script successfully works out and creates an index without displaying any warnings and errors.
An index is created on the table using the TRUNC(TO_NUMBER(PROCID)) function
When trying to insert or change an entry in the table, if PROCID cannot be converted to a number, I get the error ORA-01722: invalid number, which is actually logical.
However, the understanding that I am working in a table with rows and adding string values to the table, and the error is about converting to a number, was misleading and not understanding what is happening...
Question: Why does Oracle change the index construction function, instead of giving an error? And how can this be avoided in the future?
Oracle version 19.14
Naturally, there was only one solution - to create the right index with the right script
create index idx_PROCID on mySomeTable(PROCID);
however, this does not explain, to me, this Oracle behavior.
Oracle doesn't know if the index declaration is wrong or the column data type is wrong. Arguably (though some may well disagree!) Oracle shouldn't try to second-guess your intentions or enforce restrictions beyond those documented in the manual - that's what user-defined constraints are for. And, arguably, this index acts as a form of pseudo-constraint. That's a decision for the developer, not Oracle.
It's legal, if usually ill-advised, to store a number in a string column. If you actually intentionally chose to store numbers as strings - against best practice and possibly just to irritate future maintainers of your code - then the index behaviour is reasonable.
A counter-question is to ask where it should draw the line - if you expect it to error on your index expression, what about something like
create index idx_PROCID on mySomeTable(
case when regexp_like(PROCID, '^\d.?\d*$') then trunc(PROCID) end
);
or
create index idx_PROCID on mySomeTable(
trunc(to_number(PROCID default null on conversion error))
);
You might actually have chosen to store both numeric and non-numeric data in the same string column (again, I'm not advocating that) and an index like that might then useful - and you wouldn't want Oracle to prevent you from creating it.
Something that obviously doesn't make sense and shouldn't be allowed to you is much harder for software to evaluate.
Interestingly the documentation says:
Oracle recommends that you specify explicit conversions, rather than rely on implicit or automatic conversions, for these reasons:
...
If implicit data type conversion occurs in an index expression, then Oracle Database might not use the index because it is defined for the pre-conversion data type. This can have a negative impact on performance.
which is presumably why it actually chooses here to apply explicit conversion when it creates the index expression (which you can see in user_ind_expressions - fiddle)
But you'd get the same error if the index expression wasn't modified - there would still be an implicit conversion of 'c' to a number, and that would still throw ORA-01722. As would some strings that look like numbers if your NLS settings are incompatible.
In an old application (no source code available) long texts with over 40.000 characters are stored in an Oracle database in a table column of type LONG RAW. We now want to transfer the texts into another Oracle database and want to display their content. Somehow the old application was capable to do so. However, we always run into a 4000 byte limit...
How can we export/import and display the content in a human readable VARCHAR2 (or multiple ones).
All convert functions we tried seam not to work. For example TO_LOB or TO_CLOB.
ORA-00932: Inconsistent datentype: - expected, LONG BINARY found
ORA-00932: Inconsistent datentype: CHAR expected, LONG BINARY found
From the documentation:
TO_LOB converts LONG or LONG RAW values in the column long_column to LOB values. You can apply this function only to a LONG or LONG RAW column, and only in the select list of a subquery in an INSERT statement.
So you can't do:
select to_lob(old_column) from old_table;
ORA-00932: Inconsistent datentype: - expected, LONG BINARY found
But you can move the data into a BLOB column in another table:
insert into new_table(new_column)
select to_lob(old_column) from old_table;
db<>fiddle
Once you have the data as a BLOB you can manage it as a binary value, or if it represents text then you can convert it to a CLOB - using the appropriate character set - with the dbms_lob package.
I have a table with several number columns that are inserted through a Asp.Net application using bind variables.
Due to upgrade of Oracle client to 19c and server change, the code instead of giving an error on insert of invalid data, inserts trash and the application crashes aftewards.
Any help is appreciated in finding the root cause.
SELECT trial1,
DUMP (trial1, 17),
DUMP (trial1, 1016),
trial3,
DUMP (trial3,17),
DUMP (trial3, 1016)
Result in SQL Navigator
results of query
Oracle 12c
Oracle client 19
My DBA found this on Oracle Support and that lead to us find the error in the application side:
NaN is a specific IEEE754 value. However Oracle NUMBER is not IEEE754
compliant. Therefore if you force the data representing NaN into a
NUMBER column results are unpredicatable. SOLUTION If you can put a
value in a C float, double, int etc you can load this into the
database as no checks are undertaken - just as with the Oracle NUMBER
datatype it's up to the application to ensure the data is valid. If
you use the proper IEEE754 compliant type, eg BINARY_FLOAT, then NaN
is recognised and handled correctly.
You have bad data as you have tried to store an double precision NAN value in a NUMBER column rather than a BINARY_DOUBLE column.
We can duplicate the bad data with the function (never use this in a production environment):
CREATE FUNCTION createNumber(
hex VARCHAR2
) RETURN NUMBER DETERMINISTIC
IS
n NUMBER;
BEGIN
DBMS_STATS.CONVERT_RAW_VALUE( HEXTORAW( hex ), n );
RETURN n;
END;
/
Then, we can duplicate your bad values using the hexadecimal values from your DUMP output:
CREATE TABLE table_name (trial1 NUMBER, trial3 NUMBER);
INSERT INTO table_name (trial1, trial3) VALUES (
createNumber('FF65'),
createNumber('FFF8000000000000')
);
Then:
SELECT trial1,
DUMP(trial1, 16) AS t1_hexdump,
trial3,
DUMP(trial3, 16) AS t3_hexdump
FROM table_name;
Replicates your output:
TRIAL1
T1_HEXDUMP
TRIAL3
T3_HEXDUMP
~
Typ=2 Len=2: ff,65
null
Typ=2 Len=8: ff,f8,0,0,0,0,0,0
Any help is appreciated in finding the root cause.
You need to go back through your application and work out where the bad data came from and see if you can determine what the original data was and debug the steps it went through in the application to work out if it was:
Always bad data, and then you need to put in some validation into your application to make sure the bad data does not get propagated; or
Was good data but there is a bug in your code that changed it and then you need to fix the bug.
As for the existing bad data, you either need to correct it (if you know what it should be) or delete it.
We cannot help with any of that as we do not have visibility of your application nor do we know what the correct data should have been.
If you want to store that data as a floating point then you need to change from using a NUMBER to using a BINARY_DOUBLE data type:
CREATE TABLE table_name (value BINARY_DOUBLE);
INSERT INTO table_name(value) VALUES (BINARY_DOUBLE_INFINITY);
INSERT INTO table_name(value) VALUES (BINARY_DOUBLE_NAN);
Then:
SELECT value,
DUMP(value, 16)
FROM table_name;
Outputs:
VALUE
DUMP(VALUE,16)
Inf
Typ=101 Len=8: ff,f0,0,0,0,0,0,0
Nan
Typ=101 Len=8: ff,f8,0,0,0,0,0,0
Then BINARY_DOUBLE_NAN exactly matches the binary value in your column and you have tried to insert a Not-A-Number value into a NUMBER column (that does not support it) in the format expected for a BINARY_DOUBLE column (that would support it).
The issue was a division by zero on the application side that was inserted as infinity into the database, but Oracle has an unpredictable behavior with this values.
Please see original post above for all the details.
I am trying to create the following table in Oracle.
CREATE TABLE CUSTOMER(CUST_ID INT(10),
CUST_NAME VARCHAR2(50),
CUST_SEX CHAR(2),
CUST_STATE VARCHAR2(50),
CUST_COUNTRY VARCHAR2(50));
I get an error saying that the right parenthesis is missing. In reality, the issue is with the INT data type for the CUST_ID column. Once I remove the precision :(10) from the DDL query, I am able to execute it successfully.
Oracle docs don't specify anything with regarding to whether this data type can be accompanied by a precision parameter or not. However Oracle does mention that INTEGER/INT is per ANSI standards.
https://docs.oracle.com/cd/B19306_01/olap.102/b14346/dml_datatypes002.htm
Certain other non-official references describe INT/INTEGER to be a synonym for NUMBER(38).
Can someone please tell me if precision cannot indeed be specified for INT datatype?
The Oracle docs state that:
SQL statements that create tables and clusters can also use ANSI data types and data types from the IBM products SQL/DS and DB2. Oracle recognizes the ANSI or IBM data type name that differs from the Oracle Database data type name. It converts the data type to the equivalent Oracle data type
As the table below that sentence states, int, integer, and (surprisingly?) smallint are all synonyms for number(38), so you cannot specify a precision for them. For your usecase, if you want an integer number with ten digits, you should use number(10).
Let me try: precision cannot indeed be specified for INT datatype.
How did it sound?
Documentation says:
<snip>
| { NUMERIC | DECIMAL | DEC } [ (precision [, scale ]) ] --> precision + scale
| { INTEGER | INT | SMALLINT } --> no precision for integers
| FLOAT [ (size) ]
<snip>
The INT[EGER] data type (which should be , at least mostly, a 4-byte binary integer), in Oracle, exists, if at all, in PL/SQL stored procedures.
Your best bet is to design a NUMBER(5) for a SMALLINT, a NUMBER(9) for an INTEGER, and a NUMBER(18) for a LARGEINT/BIGINT
If you go:
CREATE TABLE dropme (i INT);
, in Oracle, you get a table with a column i NUMBER (with no length specification, which boils down to a pretty in-efficient NUMBER(38).
The Oracle numeric data types are NUMBER , with an optional overall precision and an optional decimal scale, and FLOAT.
And an Oracle NUMBER, at least as I understood it, is a variable-length construct, with a binary, two-byte, length indicator for the whole thing, followed by a binary decimal notation , in which every following half-byte can hold between 0000 and 1001, binary, or 0 to 9 - except the last one, which contains the sign: positive/negative.
As the documentation says, INTEGER is equivalent to NUMBER(38).
You can just use INTEGER where you want to store integers of any size, or you can use NUMBER(n) if you want to constrain the number of digits in the values to n.
Note: the only reason for specifying the precision in Oracle is for validation and documentation. There is no space advantage in using smaller values of n: the value 123456 occupies the same number of bytes in NUMBER(6) and NUMBER(38) and INTEGER columns - i.e. 4 bytes.
I can write the following query for Microsoft SQL Server and it working fine:
SELECT
STR(Facts.decimal_value,FormattingSettings.length,FormattingSettings.precision)
FROM
Facts,FormattingSettings
As result i get values formatted with custom precision (FormattingSettings there is one row table) and can changing the formatting dynamically.
It is possible to do same thing for DB2 (9.5)?
The answers for similar questions (like decimal formatting in sql query) had used only the integer constant as precision.