none
Getting Parameter Values - Need Perspective

    Question

  • Have several server reports (RDLs, not RDLCs) that use report parameters (text boxes, dropdowns, etc).  Is it possible to view these reports in web pages using the report viewer control and use the report parameters as they were originally intended?

    From what I've experienced so far, reports behave as if parameter data was not entered.  I've tried to extract parameter values, but only know how to find the parameter metadata.

    Do I need to hide the report parameters and substitute them with visible web controls instead?  I know how to programmatically set the report parameters, just don't know the best, if not the only way to extract user input.

    Wednesday, April 19, 2006 3:53 PM

Answers

  • I just finished a 70+ page chapter on the ReportViewer control for my new book "Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)". In this chapter I spent considerable time discussing how to deal with parameters of all kinds.

    When referencing RDL reports (already deployed to the server) it's easy to let the RV take over and manage the parameters for you--that's the default behavior. Simply point to the Server report server and URL path and go for it. However, if you want to set these parameters or hide the Report Parameters "window" you'll need to do some programming. In the book I show how to build your own controls (combo boxes or textboxes) to capture the permitted values and set the values. This is done via the ServerReport's GetParameters and SetParameters methods and a number of underlying ReportInfo... classes.

    As far as RDLC reports go you're in charge of the parameters (period). You prompt for them, you fill the  pick lists, you cascade the parameter values and everything else that the RDL report would do for you. This means you'll need to build windows forms dialogs or equivalent ASP UI elements to capture the values. This can be a lot of work and unless you figure out a way to automatically generate the UI (which I demonstrate in the chapter) you'll have to write custom code for each report--not a simple job.

    I think the best approach depends on the report and the user. Sometimes it's just fine to let the user set the parameters (or better yet CHOOSE the parameter value from a pick-list). Sometimes you want more control or you want to change the pick list based on other sources not visible to the server. You'll need to accommodate your approach to the situation. No, I don't think there's an OSFA (one-size-fits-all) solution here. 

     

    Wednesday, April 19, 2006 5:02 PM

All replies

  • I just finished a 70+ page chapter on the ReportViewer control for my new book "Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)". In this chapter I spent considerable time discussing how to deal with parameters of all kinds.

    When referencing RDL reports (already deployed to the server) it's easy to let the RV take over and manage the parameters for you--that's the default behavior. Simply point to the Server report server and URL path and go for it. However, if you want to set these parameters or hide the Report Parameters "window" you'll need to do some programming. In the book I show how to build your own controls (combo boxes or textboxes) to capture the permitted values and set the values. This is done via the ServerReport's GetParameters and SetParameters methods and a number of underlying ReportInfo... classes.

    As far as RDLC reports go you're in charge of the parameters (period). You prompt for them, you fill the  pick lists, you cascade the parameter values and everything else that the RDL report would do for you. This means you'll need to build windows forms dialogs or equivalent ASP UI elements to capture the values. This can be a lot of work and unless you figure out a way to automatically generate the UI (which I demonstrate in the chapter) you'll have to write custom code for each report--not a simple job.

    I think the best approach depends on the report and the user. Sometimes it's just fine to let the user set the parameters (or better yet CHOOSE the parameter value from a pick-list). Sometimes you want more control or you want to change the pick list based on other sources not visible to the server. You'll need to accommodate your approach to the situation. No, I don't think there's an OSFA (one-size-fits-all) solution here. 

     

    Wednesday, April 19, 2006 5:02 PM
  • Thanks for the plug for your book.
    However, as it might be in the bookstore, and i am at my desk at work, it would have been nice if you would have provided an excerpt on how to programatically set parameters at run time.

    -Edward
    Monday, October 02, 2006 9:45 PM