Sql Server Reporting Services vs Reporting Via .NET Application

Question

My boss wants me to create a few reports in the near future and I think he wants to use SQL Server Reporting Services to deploy the reports. I'm not so sure this would be such a great idea considering that we are a pretty small organization and I cannot see us making good use of or needing the features that this solution offers such as setting up Users, Groups and Subscriptions.

Although I have not used SSRS before, I've watched a 3-day webinar on it and it looks like it's one of those things that are nice and OK for simple situations but becomes a pain & too restricted when the requirements become more complex. I would much deploy the reports as local reports (.rdlc) in a .net application because:

1. I would much rather process & format data with .NET then SQL. Sure you can use CLR, but this route just seems like it would be harder to maintain and less ideal than just processing data as I usually would in a .NET application.
2. Limitations on UI when adding parameter controls - if I remember you do not have much control over the layout.

So I guess my question would be in what situations does SSRS work good, what situations does it not work good? Are my points valid or am I just being a skeptic?

Answer 1

I use a little of both, and have found that there are trade-offs with each approach.

• For whatever reason, the designer for .rdlc is a little different than the designer for .rdl. It can get pretty confusing when an online example makes assumptions on what your designer is.
• I generally favor SSRS-deployed reports if I'm trying to be client-agnostic, as .rdlc-based reports require you to provide the client.
• I generally favor .rdlc-based reports for stand-alone applications, especially for clients that do not have a data center. These tend to be applications where both the application and the database are on the client machine.
• I like LINQ, and find it easier to use as a data source for .rdlc-based reports.
• I have a love/hate relationship with .rdlc-based reports when it comes to refactoring. Keeping your data structures in a separate library than your reports is important; otherwise, changing a property name will cause your build to fail on account of the report, but the new property won't be available on the data source for the report until you build.
• Controlling the client (.rdlc-based report) gives you limitless flexibility on how you present and collect parameter values, which is pretty nice.

At any rate, I doubt there is any dogmatic approach you should stick to, other than "do what makes sense." For me, in practice, I use .rdlc-based reports for small client applications, and deploy enterprise-grade reports to a SSRS server.

Good luck!