I am writing a condition to check 2 columns both data type number.
for example varchar2(100) is larger then varchar2(50) because it holds more character. Now for numbers, number(9,1) is larger then number(10,3) because it hold more number ?
In the below example F_IDis a number(10,3) , I want to compare with another column which is number(9,3)
DECLARE COL_COUNT NUMBER;
OLD_PREC NUMBER(5);
OLD_SCALE NUMBER(5);
BEGIN
SELECT DATA_PRECISION, DATA_SCALE INTO OLD_PREC,OLD_SCALE FROM USER_TAB_COLS
WHERE TABLE_NAME='EX_EMPLOYEE' AND COLUMN_NAME='F_ID';
IF ( OLD_PREC <= 9 AND OLD_SCALE < 3 ) THEN
-- do something
Can I compare it like this? Because (9,1) = 12345678,1 and (10,3) = 123456,1234, so basically 9,1 is larger then 10,3 right?
Oracle stores numbers in scientific notation: http://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT1833 so there is no direct relation between decimal precision and space it needs to store the number.
In case you want to check which one will take more space as a text why don't compare length(to_char(n1)) > length(to_char(n2)) ?
column_name NUMBER (precision, scale)
In the declaration above the precision is total number of digits and scale is number of digits to the right of the decimal point.
By subtracting the scale from precision you'll find the digits left of the decimal point.
Hence,
NUMBER (9,1) could contain maximum 8 length number left of the decimal point : 9999,9999.9
and
NUMBER (10,3) could contain maximum 7 length number left of the decimal point : 999,9999.999
Considering this you can say that first column is larger.
Just be aware that in case when the the digits right of the decimal point are equal you have to check the scale
NUMBER (8,1) could contain maximum 7 length number left of the decimal point: 999,9999.9
and
NUMBER (10,3) could contain maximum 7 length number left of the decimal point : 999,9999.999
But in this case the second column is larger because it has 3 length scale
You said:
"varchar2(100) is larger then varchar2(50) right ? it holds more
character . okay now for numbers, number(9,1) is larger then
number(10,3) "
As an infrence i can only get that you wanted to compare the data types. See below how you can do it. I uses a PLSQL anonymous block to explain.
declare
a number (9, 1);
b number (10, 3);
begin
if length (a) > length (b)
then
dbms_output.put_line ('a is bigger');
else
dbms_output.put_line ('a is smaller');
end if;
end;
Output:
SQL> /
a is smaller
PL/SQL procedure successfully completed.
Related
Is there an easy way to convert a number in scientific notation to float in BigQuery?
For example:
8.32E-4 to 0,08
I know this is an older question, but for anyone else looking for a solution, this query (although a little clunky) should work for all scientific notation fields.
The difficulty is that BigQuery will convert any numbers greater than E±3 to scientific notation. The workaround is to cast the number as a string. If you're using this output for reporting purposes, it shouldn't be a problem. If you need to work with the numbers, make sure you've completed all calculations before converting:
SELECT
number
,base_num
,exponent
,CASE WHEN REGEXP_EXTRACT(number, r'E([+-])') = '+'
THEN REGEXP_EXTRACT(STRING((base_num * (POW(10, exponent)))), r'(\d+\.0)')
ELSE STRING(base_num * (POW(10, (exponent * -1))))
END AS converted_number
FROM
(SELECT
number
,FLOAT(REGEXP_EXTRACT(number, r'(.*)E')) base_num
,INTEGER(REGEXP_EXTRACT(number, r'E[+-](\d+)')) exponent
FROM
(SELECT "8E+1" AS number)
,(SELECT "1.6E-3" AS number)
,(SELECT "8.32E-4" AS number)
,(SELECT "2.92E+9" AS number)
)
Explanation:
FLOAT(REGEXP_EXTRACT(number, r'(.*)E')) returns the number before the E (as a string) and then converts it to a float.
INTEGER(REGEXP_EXTRACT(number, r'E[+-](\d+)')) returns the number after the E (as a string) and then converts it to an integer.
Then, raise 10 to the exponent (or its inverse, if it's negative) and multiply this by the base number.
Finally, cast as a string to maintain non-scientific notation. For numbers greater than 1, "round" to a single 0 after the decimal using regex for easier reading.
Output:
Row number base_num exponent converted_number
1 8E+1 8.0 1 80.0
2 1.6E-3 1.6 3 0.001600
3 8.32E-4 8.32 4 0.000832
4 2.92E+9 2.92 9 2920000000.0
I supposed this is for reporting purposes maybe? Does this solve for you?
SELECT FORMAT("%.10f", 8.32E-8) number UNION ALL
SELECT FORMAT("%.6f", 8.32E-4) UNION ALL
SELECT FORMAT("%4.f", 8.32E+4) UNION ALL
SELECT FORMAT("%10.f", 8.32E+8)
create sequence student_studentid_seq
increment by 10
start with 100
nocycle;
create table student
(studentid number(10),
name varchar2(30) not null,
ss# number(9) unique,
gpa number(2,3) not null,
constraint student_studentid_pk PRIMARY KEY (studentid),
constraint student_gpa_ck CHECK (GPA >= 0) );
insert into student (studentid, name, ss#, gpa)
values(student_studentid_seq.NEXTVAL,'Draze Katan', 323456789,1);
receiving error message:
Error starting at line 29 in command:
insert into student (studentid, name, ss#, gpa)
values(student_studentid_seq.NEXTVAL,'Draze Katan', 323456789,1)
Error report:
SQL Error: ORA-01438: value larger than specified precision allowed for this column
01438. 00000 - "value larger than specified precision allowed for this column"
*Cause: When inserting or updating records, a numeric value was entered
that exceeded the precision defined for the column.
*Action: Enter a value that complies with the numeric column's precision,
or use the MODIFY option with the ALTER TABLE command to expand
the precision.
So it appears error message is for next constraint:constraint student_gpa_ck CHECK (GPA >= 0) );
In insert statement if I enter '0' for GPA raw will be inserted but anything more I will receive error message.
This is one of my exercise questions, I can't figure out. I just need hint where mistake is not full resolution. Please if you could help me out.
The issue is in the way you create the table, in particular in the column GPA.
You are using number(2, 3), which looks like "build a number with 2 total digits and 3 decimal digits".
In oracle documentation you find a better explanation about the NUMBER data type, its attributes and what things like number(2,3) mean:
Specify a fixed-point number using the following form:
NUMBER(p,s) where:
p is the precision, or the maximum number of significant decimal
digits, where the most significant digit is the left-most nonzero
digit, and the least significant digit is the right-most known digit.
Oracle guarantees the portability of numbers with precision of up to
20 base-100 digits, which is equivalent to 39 or 40 decimal digits
depending on the position of the decimal point.
s is the scale, or the number of digits from the decimal point to the
least significant digit. The scale can range from -84 to 127.
Positive scale is the number of significant digits to the right of the
decimal point to and including the least significant digit.
Negative scale is the number of significant digits to the left of the
decimal point, to but not including the least significant digit. For
negative scale the least significant digit is on the left side of the
decimal point, because the actual data is rounded to the specified
number of places to the left of the decimal point. For example, a
specification of (10,-2) means to round to hundreds.
Scale can be greater than precision, most commonly when e notation is
used. When scale is greater than precision, the precision specifies
the maximum number of significant digits to the right of the decimal
point. For example, a column defined as NUMBER(4,5) requires a zero
for the first digit after the decimal point and rounds all values past
the fifth digit after the decimal point.
For example:
SQL> create table tabError( a number (2, 3));
Table created.
SQL> insert into tabError values (1);
insert into tabError values (1)
*
ERROR at line 1:
ORA-01438: value larger than specified precision allowed for this column
SQL> insert into tabError values (0.1);
insert into tabError values (0.1)
*
ERROR at line 1:
ORA-01438: value larger than specified precision allowed for this column
SQL> insert into tabError values (0.01);
1 row created.
If you need 2 digits for the integer part and 3 for decimals, you need number(5, 3) or, according to Mathguy's comment, if you need numbers with one integer digit and 2 decimals, you need number(3,2).
In Oracle documentation it is mentioned that
NUMBER (precision, scale)
If a precision is not specified, the column stores values as given. If
no scale is specified, the scale is zero.
But NUMBER (without precision and scale) is also accepting floating point numbers (34.30) but according to documentation if scale is not specified it should be zero scale by default so it should allow only integers, am I wrong?.
And in another questions it is mentioned that
default precision is 38, default scale is zero
So NUMBER and NUMBER(*,0) should be equal but they are not.
Where am I wrong?
I think the sentence in the documentation
If a precision is not specified, the column stores values as given. If no scale is specified, the scale is zero.
is a bit confusing. The scale is zero if a precision is specified and a scale is not specified. So, for example, NUMBER(19) is equivalent to NUMBER(19,0). NUMBER, by itself, will have 38 digits of precision but no defined scale. So a column defined as a NUMBER can accept values of any scale, as long as their precision is 38 digits or less (basically, 38 numerical digits with a decimal point in any place).
You can also specify a scale without a precision: NUMBER(*, <scale>), but that just creates the column with 38 digits of precision so I'm not sure it's particularly useful.
The table How Scale Factors Affect Numeric Data Storage on this page might be helpful.
The default of scale is not zero, which has no value in it. Hence it can accept any value between -84 to 127. If you limit it to zero then it will not accept any presicion even the value contains the scale value
create table aaaaa
(
sno number(*,0),
sno1 number
);
The user_tab_columns will give you the value of your precision and scale
SQL> select column_name,data_precision,data_scale from user_tab_columns where ta
ble_name = 'AAAAA';
COLUMN_NAME DATA_PRECISION DATA_SCALE
------------------------------ -------------- ----------
SNO 0
SNO1
SQL>
Please find the below workings
SQL> select * from aaaaa;
no rows selected
SQL> insert into aaaaa values (123.123123,123123.21344);
1 row created.
SQL> commit;
Commit complete.
SQL> select * from aaaaa;
SNO SNO1
---------- ----------
123 123123.213
SQL>
This parts of Oracle documentation makes it absolutely clear:
Specify an integer using the following form:
NUMBER(p)
This represents a fixed-point number with precision p and scale 0 and is equivalent to NUMBER(p,0).
and
Specify a floating-point number using the following form:
NUMBER
The absence of precision and scale designators specifies the maximum range and precision for an Oracle number.
The meaning of the star precision is documented here and means the precision of 38
Another squirrelly case but one I faced... if the table you're inserting into contains a trigger, you should probably examine if any of its procedural flow includes attempting to convert something into a NUMBER...
I have a column X which is full of floats with decimals places ranging from 0 (no decimals) to 6 (maximum). I can count on the fact that there are no floats with greater than 6 decimal places. Given that, how do I make a new column such that it tells me how many digits come after the decimal?
I have seen some threads suggesting that I use CAST to convert the float to a string, then parse the string to count the length of the string that comes after the decimal. Is this the best way to go?
You can use something like this:
declare #v sql_variant
set #v=0.1242311
select SQL_VARIANT_PROPERTY(#v, 'Scale') as Scale
This will return 7.
I tried to make the above query work with a float column but couldn't get it working as expected. It only works with a sql_variant column as you can see here: http://sqlfiddle.com/#!6/5c62c/2
So, I proceeded to find another way and building upon this answer, I got this:
SELECT value,
LEN(
CAST(
CAST(
REVERSE(
CONVERT(VARCHAR(50), value, 128)
) AS float
) AS bigint
)
) as Decimals
FROM Numbers
Here's a SQL Fiddle to test this out: http://sqlfiddle.com/#!6/23d4f/29
To account for that little quirk, here's a modified version that will handle the case when the float value has no decimal part:
SELECT value,
Decimals = CASE Charindex('.', value)
WHEN 0 THEN 0
ELSE
Len (
Cast(
Cast(
Reverse(CONVERT(VARCHAR(50), value, 128)) AS FLOAT
) AS BIGINT
)
)
END
FROM numbers
Here's the accompanying SQL Fiddle: http://sqlfiddle.com/#!6/10d54/11
This thread is also using CAST, but I found the answer interesting:
http://www.sqlservercentral.com/Forums/Topic314390-8-1.aspx
DECLARE #Places INT
SELECT TOP 1000000 #Places = FLOOR(LOG10(REVERSE(ABS(SomeNumber)+1)))+1
FROM dbo.BigTest
and in ORACLE:
SELECT FLOOR(LOG(10,REVERSE(CAST(ABS(.56544)+1 as varchar(50))))) + 1 from DUAL
A float is just representing a real number. There is no meaning to the number of decimal places of a real number. In particular the real number 3 can have six decimal places, 3.000000, it's just that all the decimal places are zero.
You may have a display conversion which is not showing the right most zero values in the decimal.
Note also that the reason there is a maximum of 6 decimal places is that the seventh is imprecise, so the display conversion will not commit to a seventh decimal place value.
Also note that floats are stored in binary, and they actually have binary places to the right of a binary point. The decimal display is an approximation of the binary rational in the float storage which is in turn an approximation of a real number.
So the point is, there really is no sense of how many decimal places a float value has. If you do the conversion to a string (say using the CAST) you could count the decimal places. That really would be the best approach for what you are trying to do.
I answered this before, but I can tell from the comments that it's a little unclear. Over time I found a better way to express this.
Consider pi as
(a) 3.141592653590
This shows pi as 11 decimal places. However this was rounded to 12 decimal places, as pi, to 14 digits is
(b) 3.1415926535897932
A computer or database stores values in binary. For a single precision float, pi would be stored as
(c) 3.141592739105224609375
This is actually rounded up to the closest value that a single precision can store, just as we rounded in (a). The next lowest number a single precision can store is
(d) 3.141592502593994140625
So, when you are trying to count the number of decimal places, you are trying to find how many decimal places, after which all remaining decimals would be zero. However, since the number may need to be rounded to store it, it does not represent the correct value.
Numbers also introduce rounding error as mathematical operations are done, including converting from decimal to binary when inputting the number, and converting from binary to decimal when displaying the value.
You cannot reliably find the number of decimal places a number in a database has, because it is approximated to round it to store in a limited amount of storage. The difference between the real value, or even the exact binary value in the database will be rounded to represent it in decimal. There could always be more decimal digits which are missing from rounding, so you don't know when the zeros would have no more non-zero digits following it.
Solution for Oracle but you got the idea. trunc() removes decimal part in Oracle.
select *
from your_table
where (your_field*1000000 - trunc(your_field*1000000)) <> 0;
The idea of the query: Will there be any decimals left after you multiply by 1 000 000.
Another way I found is
SELECT 1.110000 , LEN(PARSENAME(Cast(1.110000 as float),1)) AS Count_AFTER_DECIMAL
I've noticed that Kshitij Manvelikar's answer has a bug. If there are no decimal places, instead of returning 0, it returns the total number of characters in the number.
So improving upon it:
Case When (SomeNumber = Cast(SomeNumber As Integer)) Then 0 Else LEN(PARSENAME(Cast(SomeNumber as float),1)) End
Here's another Oracle example. As I always warn non-Oracle users before they start screaming at me and downvoting etc... the SUBSTRING and INSTRING are ANSI SQL standard functions and can be used in any SQL. The Dual table can be replaced with any other table or created. Here's the link to SQL SERVER blog whre i copied dual table code from: http://blog.sqlauthority.com/2010/07/20/sql-server-select-from-dual-dual-equivalent/
CREATE TABLE DUAL
(
DUMMY VARCHAR(1)
)
GO
INSERT INTO DUAL (DUMMY)
VALUES ('X')
GO
The length after dot or decimal place is returned by this query.
The str can be converted to_number(str) if required. You can also get the length of the string before dot-decimal place - change code to LENGTH(SUBSTR(str, 1, dot_pos))-1 and remove +1 in INSTR part:
SELECT str, LENGTH(SUBSTR(str, dot_pos)) str_length_after_dot FROM
(
SELECT '000.000789' as str
, INSTR('000.000789', '.')+1 dot_pos
FROM dual
)
/
SQL>
STR STR_LENGTH_AFTER_DOT
----------------------------------
000.000789 6
You already have answers and examples about casting etc...
This question asks of regular SQL, but I needed a solution for SQLite. SQLite has neither a log10 function, nor a reverse string function builtin, so most of the answers here don't work. My solution is similar to Art's answer, and as a matter of fact, similar to what phan describes in the question body. It works by converting the floating point value (in SQLite, a "REAL" value) to text, and then counting the caracters after a decimal point.
For a column named "Column" from a table named "Table", the following query will produce a the count of each row's decimal places:
select
length(
substr(
cast(Column as text),
instr(cast(Column as text), '.')+1
)
) as "Column-precision" from "Table";
The code will cast the column as text, then get the index of a period (.) in the text, and fetch the substring from that point on to the end of the text. Then, it calculates the length of the result.
Remember to limit 100 if you don't want it to run for the entire table!
It's not a perfect solution; for example, it considers "10.0" as having 1 decimal place, even if it's only a 0. However, this is actually what I needed, so it wasn't a concern to me.
Hopefully this is useful to someone :)
Probably doesn't work well for floats, but I used this approach as a quick and dirty way to find number of significant decimal places in a decimal type in SQL Server. Last parameter of round function if not 0 indicates to truncate rather than round.
CASE
WHEN col = round(col, 1, 1) THEN 1
WHEN col = round(col, 2, 1) THEN 2
WHEN col = round(col, 3, 1) THEN 3
...
ELSE null END
What if somebody made a column as VARCHAR2(256 CHAR) and there are only numbers in this column. I would like to get the highest number. The problem is: the number is something > 999999 but a Max to a varchar is always giving me a max number of 999999
I tried to_number(max(numbers), '9999999999999') but i still get 999999 back, at that cant be. Any ideas? Thank you
the best way is to
First Solution
convert the column in numeric
or
Second Solution
convert data in you query in numeric and than get data...
Example
select max(col1) from(
select to_number(numbers) as col1 from table ) d
It has to be this way because if you call MAX() before TO_NUMBER(), it will sort alphabetically, and then 999999 is bigger than 100000000000. Note that applying TO_NUMBER() to a varchar2 column incurs the risk of an INVALID_NUMBER exception, should the column containing any non-numeric characters. This is why the first proposed solution is to be preferred.
In Oracle, the NUMBER type contains base 100 floating point values which have a precision of 38 significant digits, and a max value of 9999...(38 9's) x 10^125. There are two questions at issue - the first is whether a NUMBER can contain a value converted from a 256 character string, and the second is if two such values which are 'close' in numeric terms can be distinguished.
Let's start with taking a 256 character string and trying to convert it to a number. The obvious thing to do is:
SELECT TO_NUMBER('9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999') AS VAL
FROM DUAL;
Executing the above we get:
ORA-01426: numeric overflow
which, having paid attention earlier, we expected. The largest exponent that a NUMBER can handle is 125 - and here we're trying to convert a value with 256 significant digits. NUMBER's can't handle this. If we cut the number of digits down to 125, as follows:
SELECT TO_NUMBER('99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999') AS VAL
FROM DUAL;
It works fine, and our answer it 1E125.
<blink>
WHOA! WAIT!! WHAT??? The answer is 1 x 10^125??? What about all those 9's?!?!?!?
Remember earlier I'd mentioned that an Oracle NUMBER is a floating point value with a maximum precision of 38 and a maximum exponent of 125. From the point of view of TO_NUMBER 125 9's all strung together can't be exactly represented - too many digits (remember, max. precision of 38 (more on this later)). So it does the absolute best it can - it converts the first 38 digits (all of which are 9's) and then says "How should I best round this off to make the result A) representative of the input and B) as close as I can get to what I was given?". In this case it looks at digit 39, sees that it's a 9, and decides to round upward. As all the other digits are also 9's, it continues rounding neatly until it ends up with 1 as the remaining mantissa digit.
* Later, back at the ranch... *
OK, earlier I'd mentioned that NUMBER has a precision of 38 digits. That's not entirely true - it can actually differentiate between values with up to 40 digits of precision, at least sometimes, if the wind is right, and you're going downhill. Here's an example:
SELECT CASE
WHEN to_number('9999999999999999999999999999999999999999') >
to_number('9999999999999999999999999999999999999998')
THEN 'Greater'
ELSE 'Not greater'
END AS VAL
FROM DUAL;
Those two values each have 40 digits (counting is left as an exercise to the extremely bored reader :-). If you execute the above you'll get back 'Greater', showing that the comparison of two 40 digit values succeeded.
Now for some fun. If you add an additional '9' to each string, making for a 41 digit value, and re-execute the statement it'll return 'Not greater'.
<blink>
WAIT! WHAT?? WHOA!!! Those values are obviously different! Even a TotalFool (tm) can see that!!
The problem here is that a 41 digit number exceeds the precision of the NUMBER type, and thus when TO_NUMBER finds it has a value this long it starts discarding digits on the right side. Thus, even though those two really big numbers are clearly different to you and me, they're not different at all once they've been folded, spindled, mutilated, and converted.
So, what are the takeaways here?
1 - To the OP's original question - you'll have to come up with another way to compare your number strings besides using NUMBER because Oracle's NUMBER type can't hold 256 digit values. I suggest that you normalize the strings by making sure ALL the values are 256 digits long, adding zeroes on the left as needed, and then a string comparison should work OK.
2 - Floating point numbers prove the existence of (your favorite deity/deities here) by negation, as they are clearly the work of (your favorite personification of evil here). Whenever you work with them (as we all have to, sooner or later) you should remember that they are the foul byproducts of malignant evil, waiting to lash out at you when you least expect it.
3 - There is NO point three! (And extra credit for those who can identify without resorting to an extra-cranial search engine where this comes from :-)
Share and enjoy.
If you mean that the numbers in the column can be that big (256 digits), you could try something like this:
SELECT numbers
FROM (
SELECT numbers
FROM table_name
ORDER BY LPAD(numbers, 256) DESC
)
WHERE rownum = 1
or like this:
SELECT LTRIM(MAX(LPAD(numbers, 256))) AS numbers
FROM table_name