To Proc or Not to Proc – Building SSRS Reports

  • I'd like to hear some others' opinions on this.

    If you are building an SSRS report which requires a non-trivial amount of T-SQL, do you tend to embed the SQL in the report itself, or do you put the T-SQL in a stored procedure and call that from your SSRS report?

    I'm having this discussion with a colleague who has the opposite point of view to mine, though I won't say which way I prefer just yet.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • I have a (bad) habit of putting the SQL into the reports when building, but I do think that Procs are actually better; I just end up not always migrating them over cause I was lazy. A few of reasons for my thinking procs are better are:

    1. If you need to correct the SQL, then it's far easier to find the procedure in your prefer tool, ALTER it, and deploy, than load up the SSRS project, find the report, open the report data, past that into SSMS (or similar), fix, paste back, and deploy.
    2. SSRS suffers with the AddWithValue issue; it treats all string data types as an nvarchar. As a results a clause like WHERE VarcharColumn = @StringParameter can be terrible for performance.
    3. Testing changes to the SQL is much easier too, in my opinion. You can have VS and SSMS open, for example, and them just ALTER the proc and refresh the report, no need to come out of the preview, etc, and reload the report, and hope SSRS doesn't choose to use the cached data (I "love" it when it does that...).

    Thom~

    Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
    Larnu.uk

  • I try to always use procs. I don't know of a good reason not to. It's visible, editable , & reviewable in superior query-editing tools such as SSMS. And it's available to other clients besides SSRS in case you change or supplement reporting strategies or use in other applications.

  • Thanks for the replies. Thom, that caching behaviour you describe catches me out approximately once a month!

    I'm glad that you both think along the same lines as me. I can imagine, for example, having a hundred reports deployed and then going through a refactoring exercise where one of the well-used DB columns is renamed. Pretty straightforward to handle when all of your code is in procs, but mighty time-consuming if all of the RDLs have to be checked and (maybe) edited. And after that, the release itself requires additional coordination.

    I have not tested this to any degree, but the fact that the code in the procs is compiled should also help performance.

    Everything feels more controlled when as much logic as possible is in the database itself ... in the hub of the wheel rather than in several of the spokes. Trying to assess the effects of database changes when code is spread across different systems takes longer and introduces a greater risk that something will get missed.

    I would like to hear more counter-arguments though, in addition to laziness! One might be that changes to a report require only an SSRS release, rather than DB + SSRS.

    • This reply was modified 5 months, 3 weeks ago by  Phil Parkin.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • Those are all good points in favor of using stored procedures.  Something else to consider though is who is in charge of creating reports?  What permissions do they have in SQL?  Is a DBA going to have to get involved anytime a report gets changed or migrated?  Plus a lot of changes will likely require modifying the report itself too.

  • What's the best way to segregate the SSRS stored procedures from the rest, put them in their own schema, and then grant users execute on the schema? (and SSRS devs create/modify rights?)

    ... says the guy who is absolutely not a DBA.

  • pietlinden wrote:

    What's the best way to segregate the SSRS stored procedures from the rest, put them in their own schema, and then grant users execute on the schema? (and SSRS devs create/modify rights?)

    ... says the guy who is absolutely not a DBA.

    An answer from one non-DBA to another!

    Own schema ... yes, I do that. But I don't do the GRANT EXECUTE bit. Instead, we use a single read-only user for the database connections in SSRS and control access to the various reports from within SSRS, usually at folder level. If a user has access to a report, they can see all of the data that is available to that report, and that works for us.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • ZZartin wrote:

    Those are all good points in favor of using stored procedures.  Something else to consider though is who is in charge of creating reports?  What permissions do they have in SQL?  Is a DBA going to have to get involved anytime a report gets changed or migrated?  Plus a lot of changes will likely require modifying the report itself too.

    We're a small team in a small company. Only developers modify reports, so the issues you are hinting at are not (usually) issues in our environment. However, if there are unrelated database changes being developed and we want to quickly make changes to a report and promote to production, we may have to get creative with our VCS (git) to keep QA and production database branches in line. Embedding all code in the SSRS report avoids this issue.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • I use stored procedures for ease of amending. But only for more involved queries, and very rarely for the queries that build the SSRS parameter lists of values. The one big downside though is passing a multi-valued parameter to the stored procedure. IIRC - don't use SSRS now - it has to be passed as a single varchar and then 'split' within the stored procedure.

  • kuopaz wrote:

    The one big downside though is passing a multi-valued parameter to the stored procedure. IIRC - don't use SSRS now - it has to be passed as a single varchar and then 'split' within the stored procedure.

    Good point, though I don't see it as a down-side. I usually split out all of the items straight into a temp table with a clustered PK and then join from that temp table to whichever table I am filtering (assuming that's what the parameter is doing).

    Took a bit of extra time for the initial implementation in the very first proc, but now pretty much boiler-plate code.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • I must admit, the lack of support for table type parameters in SSRS is frustrating. Though, I also feel like the opposite syntax that SSRS allows (SomeColumn IN (@Variable) ) teaches people incorrectly that that syntax works in T-SQL, where as what SSRS actually does is it removes the reference to @Variable and replaces it by injecting the literal values. For long lists, this can actually have some very poor performance. And (as I mentioned earlier), all these values are likely (injected as) nvarchar values, which for many may well cause implicit casting of the column in the WHERE; which we all know is awful for performance. I'd take a delimited list I can control over injection from an application I can't any day.

    Thom~

    Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
    Larnu.uk

  • My answer is that it depends. Sometimes the report parsing logic is so specialized that it will never be used elsewhere. In those cases I sometimes just slap it in the report. The safe answer is to use procs. If there is a performance issue that would definitely matter. I have never noticed much of a performance difference between the two.

  • You know what I'm going to say, Phil.  SSRS is... an application.  You already know the rest.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • But I don't know the rest, Jeff - what do you mean?

  • kuopaz wrote:

    But I don't know the rest, Jeff - what do you mean?

    Understood.

    There are other things to consider but let's start off with some of the basics...

    Ask yourself what it takes to make changes in the SQL code that's embedded in SSRS... even just a small tweak that changes nothing about the interface with the actual report.  Then ask yourself how much of that you would have to do if SSRS were calling a proc instead.  Also ask yourself how quickly you could roll back a change if it went awry once it hit prod.  Last but not lease, ask yourself how you would deploy such changes to multiple installations of SSRS.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

Viewing 15 posts - 1 through 15 (of 18 total)

You must be logged in to reply to this topic. Login to reply