SSRS Calculations: in the dataset or in the report

Hi folks,

For those you you that write SSRRS reports pulling data from Tessitura db stored procedures ... where do you do your calculations? In the Stored Procedure that gives you the datasetor in the Report

I like having most of my numbers counted in the Stored Procedure as it's easier to juggle in my head and plan. But in debugging an old report that is displaying differently in iOS and Android or Windows I'm working with a different style of build where a fair ammount is calculated in the Report (mainly column math).

Interested to hear your preferences.

Heath

Parents
  • Hey ,

    I also tend to do as much as possible in the procedure as I can.  I agree that doing the work in the procedure also dates back to the InfoMaker days for me as well.  Also, as a database person in general, I think we all tend to want to default to doing things in our "natural habitat", as it were.

    That said, as a SLIGHT counterpoint, when it does come to column math/aggregations, I HAVE found it useful to leave some up to the report as well.  Some things are just annoying to do in SQL.  Like getting a percent out of a bunch of INT columns.  Not impossible by any stretch; just annoying, and, if it is intended as a fairly straight-forward result in the report, why not let it do the work for you?

    But it is all a matter of need.  I think column math/aggregations in the report is an easy do when it is a straight forward thing.  E.g. all rows will ALWAYS show, or you are always percenting (new word?) on two columns in the same row.  But if you are building a complex report with tons of hidden rows, weird references and complex summations... while I have always found that there IS a solution in the report writer in one shape or another, it almost always just seems so much easier to me to do the work in SQL.

    Hope that whole project is going well!

    John A. Moskal II

Reply
  • Hey ,

    I also tend to do as much as possible in the procedure as I can.  I agree that doing the work in the procedure also dates back to the InfoMaker days for me as well.  Also, as a database person in general, I think we all tend to want to default to doing things in our "natural habitat", as it were.

    That said, as a SLIGHT counterpoint, when it does come to column math/aggregations, I HAVE found it useful to leave some up to the report as well.  Some things are just annoying to do in SQL.  Like getting a percent out of a bunch of INT columns.  Not impossible by any stretch; just annoying, and, if it is intended as a fairly straight-forward result in the report, why not let it do the work for you?

    But it is all a matter of need.  I think column math/aggregations in the report is an easy do when it is a straight forward thing.  E.g. all rows will ALWAYS show, or you are always percenting (new word?) on two columns in the same row.  But if you are building a complex report with tons of hidden rows, weird references and complex summations... while I have always found that there IS a solution in the report writer in one shape or another, it almost always just seems so much easier to me to do the work in SQL.

    Hope that whole project is going well!

    John A. Moskal II

Children
No Data