Sorry to ask a dumb question, but this one's got me stumped.
SELECT
81234 / 160000 * 100 AS Try1,
CAST((81234 / 160000 * 100) AS float) AS Try2
The answer is 50.77125 but both values return zero. What's the problem?
Thanks,
Try using a decimal point.
Something like
SELECT
81234 / 160000 * 100 AS Try1,
CAST((81234 / 160000 * 100) AS float) AS Try2,
81234. / 160000. * 100. AS Try3
SQL Fiddle DEMO
From / (Divide) (Transact-SQL)
If an integer dividend is divided by an integer divisor, the result is
an integer that has any fractional part of the result truncated.
you're implementing a division by int
Try this:
SELECT
cast(81234 as float) / cast(160000 as float) * 100
or
SELECT
81234.00 / 160000.00 * 100
the cause of that is that 81234 / 160000 is an integer division so it returns 0, force it to be float like 81234. / 160000 and it will work
Try this
SELECT
81234.00 / 160000 * 100 AS Try1,
CAST((81234.00 / 160000 * 100) AS float) AS Try2
You're dividing a number that is considered an integer. Thus, by adding two decimals it is converted to a decimal number and decimals are displayed.
In your case, the division 81234 / 160000 resulted in a 0, which multiplied by 100 is still 0.
You are doing integer divides. 81234/160000 gives zero. Multiply by 100 and it's still zero.
Try converting to floats before doing the division.
Change your query like below
SELECT
81234.00 / 160000 * 100 AS Try1,
CAST((81234.00 / 160000 * 100) AS float) AS Try2
** 81234.00 / 160000 return 0.5077125 by manual through sql it will think as Integer Division so it will return the value 0.
Actually the value 81234 is integer and if you devide an integer it will return integer only concerting 81234 in to float will return float
SELECT
(CONVERT(FLOAT,81234) / 160000) * 100 AS Try1,
((CONVERT(FLOAT,81234) / 160000 * 100) AS Try2
Thanks
Ashutosh Arya
Related
Code :
days_between("Created Time","Locked Time")*24
Result table :
Avg Response time (Hours)
2.91
6.00
9.13
3.65
1.17
0.00
0.77
32.47
The table above is the result i get after the code but currenlty I want to remove all decimal place right before i get this result with the days_between("Created Time","Locked Time")*24 i am using, So how can I do this. I tried to use cast and round () but is not working. Can someone help out. Thank you
Try code:
days_between("Created Time","Locked Time")*24 , 0) AS INT ) AS Response_Time
According to your sample data I guess:
with t(d) as (
values (2.91), (6.00), (9.13), (3.65), (1.17), (0.00), (0.77), (32.47)
)
select d, cast(d/24 as decimal(5,2)) from t;
I have a similar query running on MSSQL, and I can do it as:
SELECT TOP 10 a.SizeBytes AS originalValue
,COALESCE(a.SizeBytes, 0.00) / (1024 * 1024) AS defaultOperation
,CAST(COALESCE(a.SizeBytes, 0.00) / (1024 * 1024) AS INT) AS withCast
,FLOOR(COALESCE(a.SizeBytes, 0.00) / (1024 * 1024)) AS withFloor
,ROUND(COALESCE(a.SizeBytes, 0.00) / (1024 * 1024), 0) AS withRound
FROM filesUploaded a
WHERE a.SizeBytes > 0
Resulting in:
Note that I limited my query to the top 10, for speed generating this example, as my table contains millions of rows.
Also my starting value is integer, so I had to add the decimals in order to be able to see decimals. Probably you don't need to do that as the average should already have decimals, but in my case just dividing returned an integer result for the division without using the COALESCE before dividing.
I have an Oracle function. Due to privacy issues, I can't include the whole function, but the relevant line is :-
WHEN in_tariff_length = 36 THEN round( ( ( (in_agreed / 100) * 80) * in_uplift) / 100,2) * 3
..which is rounded to 2 decimal places, and returns 1655.58
When I use
WHEN in_tariff_length = 36 THEN round( ( ( (in_agreed / 100) * 80) * in_uplift) / 100,3) * 3
..which is rounded to 3 decimal places, and returns 1655.568
The result I need is 1655.57.
All values sent to and returned from the function are NUMBER.
You can't round something, multiply by 3 and get 1655.57
551.86 * 3 = 1655.58
551.856 * 3 = 1655.568
1655.57 / 3 = 551.856666667
I suggest multiply first, then round.
Please look closely at the second function
round( ( ( (in_agreed / 100) * 80) * in_uplift) / 100,3)
Round( something, 3) means round to 3 decimal places but not to 2
I had the table, resulted from a query as follow:
Lasiorhinus 100
Macrotis 100
Myrmecobius 100
Panthera 50
Sarcophilus 100
The query is sth like this:
select round (count(A) / count(B), 1)
But I'd like the numbers to be formatted as follow:
Lasiorhinus 100.0
Macrotis 100.0
Myrmecobius 100.0
Panthera 50.0
Sarcophilus 100.0
Could anyone help me to format the integer 50 => 50.0 with ROUND(number, 1) function? thank you.
One solution (SQL Server) would be:
select format(round(count(A) / count(B), 1), 'N1')
Ref.:
Round()
Format()
I am trying to work out this statement but can't get anywhere.
From what I have found so far, I think I need to use an nullif clause for each divisor, but when I try and do this it still does not work.
Here is the statement with no nullif's that produces a divide by zero error.
(1 - (1 - (x1.hup / (x1.hup / (x1.dp / 100)))) / (1 - (x2.sdp / 100)))
There may be simpler ways to express this. I think this is all you need:
(1 - (1 - (x1.hup / (x1.hup / nullif(x1.dp / 100, 0)))) / nullif(1 - (x2.sdp / 100)), 0))
This is Not the Answer
Create a function to check zero like this
CREATE FUNCTION [dbo].[IsZero] (
#Number FLOAT,
)
RETURNS FLOAT
AS
BEGIN
IF (#Number = 0)
BEGIN
SET #Number = 1
END
RETURN (#Number)
END
Not very elegant but will do the job.
SELECT CASE WHEN (1 - (x2.sdp / 100) = 0 THEN NULL
WHEN (x1.dp / 100) = 0 THEN NULL
WHEN (x1.hup / (x1.dp / 100)) = 0 THEN NULL
WHEN (x1.hup / (x1.hup / (x1.dp / 100))) = 0 THEN NULL
ELSE (1 - (1 - (x1.hup / (x1.hup / (x1.dp / 100)))) / (1 - (x2.sdp / 100)))
END AS field
FROM yourtable
Coalescing to zero isn't the magic bullet you're looking for.
Just try to the simplify your problem; if you have 42 / x and x is null, replacing it with zero will just result in a division error.
I don't know about the formula you are applying in this case, but the main thing you are lacking is validation. In my example above, if x equals to 0 we've got a problem.
Similarly, in 23 / (100 - x), x can't ever be 100, so you must check that beforehand and handle the situation accordingly. No expression can result in 0 if it`s a divisor.
So, try to establish which constraints should be watched before processing; for instance, your statement must not accept 0 for x1.dp or x1.hup, and x2.sdp can be anything but 100 (1 - 100/100 = 0, right?). Should one of these situations happen, you could return an error or something.
We have a fairly complicated SQL Server 2008 r2 sp2 query with this as one of the lines :-
SUM((t.Quantity * contract.ValueOfOnePoint) * ((
CASE contract.Style
WHEN 3
THEN 1 / (1.0 + ((100.0 - Val) / 100.0 * 90.0 / 365.0))
WHEN 2
THEN 1000 * (6.0 * (1.0 - (POWER((1.0 / (1.0 + ((100.0 - Val) / 200.0))), 20.0))) / ((100.0 - Val) / 200.0) + (100.0 * (POWER((1.0 / (1.0 + ((100.0 - Val) / 200.0))), 20.0))))
END
) - (
CASE contract.Style
WHEN 3
THEN 1.0 / (1.0 + ((100.0 - t.Price) / 100.0 * 90.0 / 365.0))
WHEN 2
THEN 1000 * (6.0 * (1.0 - (POWER((1.0 / (1.0 + ((100.0 - t.Price) / 200.0))), 20.0))) / ((100.00 - t.Price) / 200.00) + (100.0 * (POWER((1.0 / (1.0 + ((100.0 - t.Price) / 200.0))), 20.0))))
END
)
)) AS NativeAmount
I am testing this on a single row which has a style of 3 so only the first line in the case statement should have any affect yet leaving the "WHEN 2" clause in it reduces the accuracy of the formula.
Eg. if I remove both WHEN 2 conditions I get an answer such 123.45678 but with the WHEN 2 line left in I get 123.46. It seems to be rounding for some reason even though the second WHEN should never be in-play.
Any thoughts would be really appreciated - going mad!
Thanks.
James.
You need to combine two things. The return type of the case statement is the same for all the then and else clauses. This is a quote from the documentation:
[The case statement] returns the highest precedence type from the set of types in
result_expressions and the optional else_result_expression. For more
information, see Data Type Precedence (Transact-SQL).
So, the SQL Engine does care about all the clauses in the query (which is the answer to your question).
I don't fully understand what is happening in this case. When you call the power() function, the compiler has to decide on the precision of the numeric value, based on the constants and column types. Based on this SQL Fiddle, it chooses a precision of 38 and a scale of 1. However, simple arithmetic on the values produces a precision of 36 and a scale of 23. I'm not sure why, in the end, this results in rounding the value to two decimal places. Perhaps the logic for assigning types for the into clause doesn't quite match the logic for typing of expressions.