I am getting this error
Arithmetic overflow error converting float to data type numeric
when I try to run my view but not sure what am I doing wrong with my calculation. I have researched but could not solve it so far.
Here is the line of code that is causing the error:
ISNULL(CAST(CAST(TOTAL_APPTS.APPT_CNT AS FLOAT) / TOTAL_RECS.PAT_CNT AS NUMERIC(3, 2)), 0) AS [CONVERSION RATE]
Your precision and scale arguments to NUMERIC are very small. Have you tried increasing those? Your numeric value can only handle numbers up to 9.99.
You should peruse this page:
decimal and numeric (Transact-SQL)
It's too much to explain here, but basically the first argument (precision) is the max number of digits (in your case 3) and the second argument (scale) is the number of digits to the right of the decimal point, which always takes away from the number of digits you can have to the left of the decimal point. So in your case, 3-2 = 1 digit allowed to the left of the decimal point, which is why your max value can only be 9.99.
Related
Arithmetic overflow error occurred converting expression to data type bigint when I am applying cast function on a 60 digit number.
The largest positive value which BIGINT can store is 2^63-1, which is roughly 1x10^18. Using DECIMAL or NUMERIC would get you larger storage, up to 1x10^38. But neither can accommodate 60 digits of precision.
You might want to ask yourself whether you really need to maintain so much precision for a large number as this.
I have a problem with round in SQL Server 2014: when I round a number to 2 decimal places sometimes the rounded number is different if I cast to float before or not.
For example, if I execute:
select round(cast(3.945 as float),2)
select round(3.945,2)
I have:
3.94
3.950
But if I execute:
select round(cast(3.935 as float),2)
select round(3.935,2)
I have:
3.94
3.940
It seems incorrect, rounding 3.935 and 3.945 casting to float before, I obtain the same value. Is this a bug?
The problem here is that float is a binary floating point type, where the representation is an approximation of the value. Floats do not losslessly convert to or from base 10, because there is no power of 10 that is also a power of 2. So when this is converted it is done in a way that leaves a roundoff error that pushes the value just before the rounding threshold.
Oddly I cannot reproduce the same behaviour on PostgreSQL and I am not entirely sure why (it may be that on PostgreSQL, round takes a numeric value and this forces a conversion back).
Never use floats where absolute accuracy is required. This occurs not only in databases, but in almost every programming language as well.
As #ChrisTravers says in his answer the issue with rounding a float is that you're not getting exact arithmetic. i.e. That explains why round(3.945,2) rounds up to 3.95 whilst round(3.945E0,2) effectively rounds down to 3.94.
If you're wondering why you see more than 2 decimal places in some cases, that's because of the type you're dealing with. i.e. 3.94 is a float, so doesn't have a specified number of decimal places; whilst 3.950 is the result of rounding a decimal(4,3); which even though we've rounded to 2 decimal places doesn't affect the precision of the type (i.e. it's still decimal(4,3); not converted to decimal(4,2) or decimal(3,2)).
If the purpose of this rounding is for display purposes, you're best of using the str function. i.e.
select str(3.945,4,2) --decimal
select str(3.945E0,4,2) --float
In the above the 4 is the length of the string (i.e. includes the decimal point as a character), and the 2 is the number of decimal places to show.
NB: In this scenario you're chaning the data type to varchar(4).
The below code allows you to see what type you get after performing an operation:
declare #result sql_variant = str(3.945E0,4,2)
select sql_variant_property(#result, 'BaseType') [BaseType]
,sql_variant_property(#result, 'MaxLength') [MaxLength]
,sql_variant_property(#result, 'Precision') [Precision]
,sql_variant_property(#result, 'Scale') [Scale]
I am facing an error on my SQL script:
Arithmetic overflow error converting numeric to data type numeric
select x.MemberName,x.DOB,x.FilePath,x.Medication,x.NDC,x.Directions,x.Name,x.Strength,x.GenericName,x.QtyOrdered,x.DaysSupply,x.DateFilled,
CASE
WHEN x.test = 0 THEN 'N/A'
WHEN compliance > 100.0 THEN '100.0'
ELSE CONVERT(VARCHAR(5), CAST(FLOOR(compliance *10)/10.0 AS DECIMAL(3,1)))
END as [Compliance]
I am facing the error on just above syntax line.
Here's your problem:
declare #compliance decimal(10,5)
set #compliance = 100.0 -- <----------------
select CAST(FLOOR(#compliance *10)/10.0 AS DECIMAL(3,1))
Throws "Arithmetic overflow error converting numeric to data type numeric" error. Changing to DECIMAL(4,1) works, or as #paola suggests, change your condition to >= 100.0
decimal(p,s):
p (precision) is the maximum total number of decimal digits that will
be stored, both to the left and to the right of the decimal point. The
precision must be a value from 1 through the maximum precision of 38.
The default precision is 18.
s (scale) is the number of decimal digits that will be stored to the
right of the decimal point. This number is subtracted from p to
determine the maximum number of digits to the left of the decimal
point.
In your case decimal(3, 1) means a total of 3 digits with 1 digit to the right of the decimal point,
99.9
whereas decimal(4,1) provides a total of 4 digits with 1 digit to the right of the decimal point,
999.9
This questions has already been answered, but the why is important.
Numeric defines the TOTAL number of digits, and then the number after the decimal.
So DECIMAL(4,1) shows 123.4
DECIMAL(4,3) shows 1.234
In both cases you have a total of 4 digits. In one case you have 1 after the decimal, leaving 3 in front of the decimal. And vice versa.
i am having hard time determining the length of a Decimal data type. The data i have in column is like 0.08,1.2,12.35,121.36. Now if i go for (2,2) it throws an error : Arithmetic overflow error converting numeric to data type numeric. Just wondering should it be (6,2)? and if yes can anybody tell me Why 6 and 2?
In syntax like
NUMERIC(precision, scale)
precision is the total number of digits (count digits on both sides of the decimal point), and scale is the number of digits to the right of the decimal point.
From your examples, should be NUMERIC(5,2) - meaning five numbers in total and 2 after the decimal point.
I have a column which has decimal value of 18,8. I was asked to extend it to 18,18 to hold more places after ,.
ALTER TABLE [dbo].[TransakcjeGotowkowe]
ALTER COLUMN TransakcjeGotowkoweKwota decimal (18,18) NULL
Msg 8115, Level 16, State 8, Line 1
Arithmetic overflow error converting numeric to data type numeric.
The statement has been terminated.
I have also tried to do it by GUI. Nothing else changes just want to hold more data after ,.
Is there other way to do this ?
The Decimal datatype is made up of (precision, scale)
Precision is the total number of digits to the left AND the right of the decimal point.
Scale is the number of digits to the right of the decimal point.
If you want to increase the number of digits to the right to 18 you will need to increase the overall precision. In your case increase it by 10.
So you will need decimal(28,18)
MSDN Article on Precision & Scale
You would need to change it to 28,18 Your current column allows 10 digits to the left of the decimal point.
Changing it to 18,18 would only allow a range between +/-0.999999999999999999