Strip decimals in SSRS expression without rounding - reporting-services

In my report I'm trying to remove the decimals without rounding. I'll be using this to set the minimum value in the vertical axis of the area chart.
So I tried =Format(98.56, "N0"), but this returns 99, which is incorrect. It should return 98.
I've been searching specifically for SSRS, but most of the results are for tsql.
My question: How can I remov decimals in SSRS without rounding?
Thanks

Try using "Floor". It effective rounds down to the nearest integer. You'll find this under the Math functions.
=Floor(Fields!Number.Value)
Note, there's also a Floor function in Transact-SQL that works the same way in case you need to do some of the processing in your SQL script.
Update based on request in comments
If you wanted to achieve the same result after the decimal point, all you need is a little algebra.
=Floor((Fields!Number.Value*10))/10
That should turn 99.46 into 99.4. Given that it shaves off the remainder, you could then tack on any additional zeroes you wanted.

I ended up converting to Int. The following expression in SSRS returns 98:
=Int(98.56)

I know the question is quite old, but as I ended up here having the same question I would like to share my answer:
While FLOOR and CEILING are fine if you take extra measures to handle numbers <0 or know they are always >=0, the easiest way to simply strip off the decimals is to use
=Fix(Fields!Number.Value)
FIX only returns the integer part of a number, without any rounding or transformation. For negative numbers Int rounds up.
Source: Examples for Fix, Floor and Ceiling
Source: Difference between Int and Fix

Related

SQL avg then trailing numbers

I'm trying to get the average number, and then remove the trailing, pointless zeros afterwards, (new to SQL) but I can't understand why it wont remove them, do I have the wrong idea??
So far I have;
SELECT total,
AVG(total(TRUNCATE(total/1,2))
I think you are looking for cast as below.
select cast(17.800000 as dec(3,1))
Result:
val
----
17.8
so you query will be
SELECT total, cast(AVG(total) as dec(3,1))
considering you just need 2 digit before . If you need more digits, you can adjust it accordingly.
DEMO
Assuming you are using SQL Server then you can cast the answer to a decimal with one decimal point:
select cast(avg(total) as decimal(9,1))
This SQLFiddle shows it: link
SELECT
TRUNCATE(AVG(myFloat), 2),
AVG(myFloat),
ROUND(AVG(myFloat), 2)
FROM docs
You should probably use ROUND instead of TRUNCATE.
The stuff after the decimal is odd because of floating point math, and there are occasions where floating point math is internally calculated as .009999999 instead of .01000000000
I believe these answers that use a CAST may have the same truncation problem.
You simply want to avoid casting or truncation when you are removing the decimal places beyond what you're interested in. Be explicit in what you are doing and less mistakes will pop up later.

Having a rough time decided on FLOAT, DOUBLE, or DECIMAL

Currently using MySQL version 5.1.6
This is my first real world build and so far I have actually been enjoying it; however, I now am stuck on a decision regarding a field datatype and hoping someone could sort it out for me.
I essentially have 10 fields that are all different test results. The numbers range from -100 to 100 and can have a decimal with one spot after the actual point.
For example, -5.1, 0, 1, 16.3, 99.2, and 100 are all possible data. From what I have read, one should use DECIMAL for those things that we usually measure and are exact (which these are), whereas FLOAT and DOUBLE are approximations, which I do not really want (though I am sure at this level, the approximation is very small if existent at all).
If I use DECIMAL, do I have to include a space for the '-' at the beginning if used? I.E, would I use DECIMAL(4,1) or DECIMAL(5,1) or am I way off here? I might be overthinking this a bit.
DECIMAL(4,1) will be enough, the sign digit does not need to be included.
More info: http://dev.mysql.com/doc/refman/5.1/en/precision-math-decimal-changes.html
For example, a DECIMAL(3,0) column supports a range of -999 to 999
Decimal will be indeed the best option for your needs. Float and Double can give you ugly numbers (e.g. 0.2 cannot be represented as float, you'd get 0.19999999)
The negative symbol does NOT count as a digit in your calculation, so DECIMAL(4,1) should be fine.
Edit: That also seems like the right field to use for your purposes. Try it out!

round in mysql doesn't work very well

The round function sometime doesn't work very well. I have in my db a row like this:
field_1= 375
field_2= 0.65
field_3= 0.1
field_4= 11
So we know that: field_1*field_2*field_3*field_4 = 268.125 so if I round it to 2 decimals -> 268.13.
But in mysql I got 268.12 -> Select round(field_1*field_2*field_3*field_4) from my table -> 268.12
This situation just happens with these values, I tried with other numbers and no problem the round works.
Any workaround about it. I tried in mysql 4.1.22, and 5.1.44 and I get the same issue. I read in other forum http://bugs.mysql.com/bug.php?id=6251 that it is not a bug, they said that it depends on the C library implementation.
What data type are you using for those columns?
If you want exact precision then you should use NUMERIC or DECIMAL, not FLOAT, REAL, or DOUBLE.
From the manual:
The DECIMAL and NUMERIC types store exact numeric data values.
These types are used when it is important to preserve exact precision,
for example with monetary data.
If applicable you can use FLOOR()
If not applicable you will be better off handling this on the application side. I.e. do the entire calculation application side and then round, or just round application side.
SELECT (field_1*field_2*field_3*field_4) AS myCalculation FROM my table

mysql returns not exact value in max function when dealing with floats?

Look at this query please
SELECT max( val_amd ) FROM `best_deposits`
I have the max value in the table equal to 14.6(the fields has type float),
But it returns 14.3599996566772
why does it happen, and how can i get the exact value?
Thanks much
floats are evil!
NEVER use floats for storing amounts or prices. instead of that, use an int and store the amount in cents. thats the only way to get around those problems forever.
why this happens: because floats can't be saved exactly in many cases (such as 0.6 in your case)
PS: we had those questions a hundret times for different languages till now:
Use Float or Decimal for Accounting Application Dollar Amount?
PHP rounding problem (5.2.3)?
Rounding problem with double type
Javascript rounding v c# rounding
Python rounding problem
... and a lot more
EDIT: to your comment: as i said:
use an int and store the amount in
cents
(alternatively you could use an DECIMAL(10,2) (or how big/how much decimal places you need)... not sure about how this works)
Or you better use "decimal" with length 10,2 or something like that for storing prices.

How can I always round up decimal values to the nearest integer value?

On a report I have the following code for a field:
=Sum([PartQty]*[ModuleQty])
Example results are 2.1 and 2.6. What I need is for these value to round up to the value of 3. How can I change my field code to always round up the results of my current expression?
This is an old Access trick I learned a very long time ago, and it makes use of the way Access handles fractional, negative numbers. Try this:
-Int(-[DecimalValue])
It's odd, but it will always round your numbers up to the nearest whole number.
you could do
=Int(Sum([PartQty]*[ModuleQty]))+1
I think. That would get the Int part of the sum (2) and then add 1. you might need to be a little more clever as this will probably give you 3 even if the sum is exactly 2, which is probably not what you want.
not tested it but something along these lines might work (access syntax is not that great, but should give you the right idea) :
Iif(Sum([PartQty]*[ModuleQty])-Int(Sum([PartQty]*[ModuleQty]))=0,
Sum([PartQty]*[ModuleQty]),
Int(Sum([PartQty]*[ModuleQty]))+1)
Test this:
Round(yournumber + 0.5, 0)