In response to a post I made on an unrelated topic, a reader said "I’m not really a fan of SSRS, preferring to use an ASP.NET and HTML interface…"

I’d like to move that discussion to the this thread and keep it on topic.  This is an interesting subject and one that I and many others have debated in the past.  The original thread is posted here but please reply to this topic in this thread.  Derek, I encourage you to post your previous reply to this thread.

Granted, using your suggested approach to start from scratch and write a custom application from the ground up affords more control and flexibility than some of the restrictions imposed by the Reporting Services interface.  However, unless you are dealing with nothing but very basic reporting requirements, writing a business report from the ground-up will take a number of hours exponentially greater than a report created using a capable enterprise reporting platform.  If I were to tell my clients that each of their analytical reports would take days, rather than hours, to design; they would not be able to pay for my services.  Nor would they be able to maintain or add additional features to existing reports.  Likewise, composite dashboards and the most complex reports would take months, rather than days. 

"If you only have a hammer, everything looks like a nail"…  We’ve all heard that but to extend the analogy, if all I want to do is put two boards together, a hammer an nail is a great solution.  It’s quick and easy, but if I need to build a precision instrument – let’s say a Swiss watch or a telecommunications satellite, a hammer and nail aren’t going to cut it.  Every skilled craftsman carries many different tools and uses the right one for each task.

I agree with you that the parameter interface baked into the SSRS product is rudimentary, compared to something you can create yourself.  If you need to have more control over the parameter interface, than wrap the report in the ReportViewer control and pass the parameter values to the control, letting the report take care of the hard stuff like groups, filtering, calculations, drill-down and drill-through actions.  Beyond the report design experience and and user interface, our users and clients typically use features like the ability to render/export to multiple formats, instance caching and snapshots, alerting and subscriptions.  Duplicating these capabilities in a custom-built solution could take weeks or months at great expense

Yes, coding from scratch is a good solution for certain data-centric applications and simple reporting scenarios but not for complex, multi-element analytical business reports.

I welcome your comments and thoughts.

Filed under: SolidQ, SQL Server, SQL Syndication, SSRS Design Tagged: Custom coding reports