Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m about to set up a web-page where my SSRS will be viewed. I see that there are three options(Report Server Web service, ReportViewer controls for Visual Studio, and URL access)
I wanted to know about the main difference between “ReportViewer controls for Visual Studio” and “URL access” – does the “ReportViewer controls for Visual Studio” require the end user to have extra plug-ins? Thanks!
ReportViewer needs to make calls to the SSRS Server via SOAP requests I believe. It is basically a window into the SSRS site and has all the functionality in the services available visually at once. The viewer usually presents the report in a format like:
The URL access is generally the webservice of SSRS doing the work for you directly with commands given to it directly. It is important to note that I believe the web service does all the work for both but the site access also has visual studio on the host and client location also doing some after market CSS rendering and other things from their default locations. The Webservice is just rendering the report and potentially the header where the parameters are. You can even pass in parameters in the URL if you know what you are doing with SSRS. However this does not present a usable object for rendering except in a browser.
EG: say I have a report that takes two parameters: A ‘Start’ datetime and an ‘End’ datetime. I can call the web service and render the report and input the parameters at the same time. I could host this in my own browser viewer, but not really do much with the object without developing something else to consume it.
You can also do your own calls in .NET with talking to the SSRS web services or creating your own proxy classes. This is for applications when you want to render in custom formats with events triggered from potentially an application that is not on a set schedule or you want to decouple from the SSRS site and maintain your own settings without relying on the server being the decider of when things happen.