3

I Have an SSRS 2008 Report whose dataset runs a SQL query that returns a calculated column. This dataset fills a table in the report.

The calculated column is returning up to 4 decimals. I want to round to the nearest 2 decimals. i.e., 8660.125 should become 8660.13, 1487.8521 should become 1487.85

Sample of the query:

select [Hours] * [Rate] * [Complexity] * [Efficiency] from Hours

I would perfer to perform this rounding in the SQL Query rather than the SSRS table because we are trying to keep the tables "unintelligent" so we can encapsulate all our logic in the SQL Query itself. Suggestions?

MikeTWebb
  • 9,149
  • 25
  • 93
  • 132
  • It might help if you posted a sample query or an excerpt of your query. – Aaron Kurtzhals Jan 31 '13 at 21:05
  • Often on reports, the rounding is accomplished in the display rather than altering the underlying data. Don't perform a data conversion if you don't have to. – DOK Jan 31 '13 at 21:13

2 Answers2

7

There are two issues here.

The first is the rounding. This can easily be done with the Round function in SQL:

SELECT Round(8660.125, 2);
-- returns 8660.130

The second, as you can see, is that this still returns 3 digits after the decimal point. This is due to the data type. You got your rounded value, but it is still showing an extra digit.

You can fix that this way:

SELECT Convert(decimal(16, 2), 8660.125);
--returns 8660.13 by implicitly rounding--you could round first but not needed

However, these two values above are identical numerically. And in my opinion, you shouldn't be dealing with presentation on the SQL Server side at all. If you want two decimal places, just set the cell's format in your SSRS report to #.00. This will ensure you get the number of (rounded) decimal places you want, no matter what! There is no function needed. Just a simple property.

It's the same principle for dates. The underlying value of a date is just a number. But there are myriad ways to present dates to the user--with long names or different order of the parts or using different separators. Every time you change date formats will you go all the way back to your SQL and change your Convert() style?

You don't expect your SQL Server to determine the font, color, size, padding, style, position, or visibility of these numbers in the report. Those all have to be set manually at design time, too. So why would how the value is displayed (when the values are exactly equal) be any different? In my opinion, pushing this into the SQL query is moving the area of concern to the wrong place. That is adding complexity (not "intelligence") to the query that doesn't need to be there! And I don't see setting the numeric format of a cell to be "adding intelligence" either.

It's a presentation concern, so keep it in the proper place that all other presentation elements are addressed--the SSRS report.

Update

I can think of one scenario where you would want to perform the conversion in your query, and that's when the value will be further used in more calculations and the business rules about said calculation require it. For example, if you were calculating bank interest, they could have rules like "after step 1 round to 4 decimal places, then and after step 3 finally round to 2 decimal places (dollars and cents)." But that is a different story: now the value matters, not just its display.

ErikE
  • 48,881
  • 23
  • 151
  • 196
  • @Erik....great info. On all counts. And, I agree with you on the presentation layer vs the data layer. I'll make that switch – MikeTWebb Jan 31 '13 at 21:38
0

Try something like using CAST -- it should handle the rounding for you.

SELECT CAST(col as DECIMAL(10,2))

Here is the SQL Fiddle.

With your sample query above, use:

select CAST([Hours] * [Rate] * [Complexity] * [Efficiency] as DECIMAL(10,2)) from Hours

Good luck.

sgeddes
  • 62,311
  • 6
  • 61
  • 83