We have an issue where the ASP .net Reporting Application we are using is running at a significantly slower pace than the Report Manager portal, when it comes to running large reports. One of the possible solutions being considered is switching from RDL (server-based reports) to RDLC format (client-side-based). Is this a feasible solution for such an issue? Initial research suggests that performance can be significantly improved using RDLC. However, we have over 100 reports that currently reside on our Report Server. Do we need to do any major configuration or individual tweaking on each of these to convert them to RDLC? Furthermore, I have read that the Report Viewer control does not support local parameter prompting. This is because the Report Viewer does not execute queries itself, but merely displays the results executed by the host application. How would this affect the current server-side reports, some of which use up to a dozen parameters each to populate stored procedures used for their report datasets? Would switching from RDL to RDLC be worth it considering these issues? Any insights or suggestions would be really appreciated!
RDL files invoked by a client browser collect parameters from the web page. The submitted parameters are then used to construct the SQL create server result set, render the page and return to client browser. RDLC files however don't instigate the communication with the database. The client application via it's user interface collects all of the parameters to build SQL which when executed creates a data set. This returned data set is bound to the client side report viewer and uses the local client to render the page. RDLC can access a dataset constructed from any source, relational, flat file, hand coded and more so is more flexible. RDL reports can be scheduled, offer security controls, auditing and end user flexibility. I believe they use the same schema so can rename RDL files RDLC and import them into Visual Studio (with various version issues). However VS will ignore any parameters defined in the report.
The client application if it's web based or windows formed based call stored procedure or execute dynamic SQL to populate lists, combo boxes or date pickers in the same way that any application would. Whatever values are picked are then used as parameters to construct the final SQL that populates the dataset that the report viewer is bound to.