Client side reporting you'd use if you've got something like a winforms client that you can't guarantee will have constant access to the data source. It might have a set of data cached on the client side which you need to report on even if the connection to the server is unavailable.Server side reporting you'd use in the scenario where you either need to simplify the report distribution and deployment as you just deploy the reports to one place and everyone can access them. This has the downfall of always requiring a connection be available to the server. Client side reporting is also handy when you have a client gathering data from very different sources. We have an in-house corporate application that calls internal services to get data from financials as well as our separate production database, and it combines them into a single dataset which it passes to a ReportViewer control.From an aesthetic point of view, it's nice to integrate reporting into an application so that the user doesn't feel that they're leaving the app to print or export the app's data. Client site reportingIf one of the following is true then you should use client site reporting:. If you have the data only on the client and not in the network or on the server.
Sql Server Reporting Services Download
This is mostly true for desktop applications. There is no server (Home systems).Server site reportingIf one of the following is true then you should use server site reporting:. The data is on the server or on a static place in the network. You only have thin clients. The reporting should be scheduled. The license cost for a single server is smaller than for many desktop installations.
Reporting Services Client Tools Inc
Report templates are shared and can change frequently. It depends what you call 'server' in this case. As you mention SSRS I am assuming you consider the database (SQL Server) as the server.It all depends on the application/project structure and requirements.