Jeffrey Williams wrote:
It really comes down to how you want to architect your reporting solution. If you need to embed the reports into your application - then using RDLC reports is a good option. If you want to host the reports separate from the application then traditional SSRS reports would be a good option.
Regardless - a changing schema won't affect a report as long as the query/procedure utilized returns the same data elements in the same order with the same signature. That is - if column lengths are constantly changing, column names are changing - etc... then SSRS is going to break, regardless of methodology.
One option to handle that is to use stored procedures and cast the columns being returned to the report to a large enough size that any data length changes in the underlying system will not affect the output. For example, if column1 can increase in size - you could cast that to a varchar(100) in the code so that those changes do not change what SSRS is expecting.
Jeffrey, I agree with you that RDLC files are a wonderful solution. I've used it, multiple times in my previous job, with success.
However, I am working with some co-workers who, for whatever reason, do NOT get it. We've been "trying" to use RDLC files for the last two years in this project. It's a WPF project, written in C#. In my previous job, handling this with RDLC was easy-peasy. All you must do is include the NuGet package Microsoft.SqlServer.Types into the project. That is, it. But where I work, they've got a horrible habit of copying .DLL files from one project into another, where they reference it within the Visual Studio project, then continue development. Because we're all developers, we have Admin privileges on our own dev boxes, so this is not an issue. However, it is always an issue when deploying the app. Since it's a WPF app, we use ClickOnce to deploy the app. ClickOnce cannot be run with elevated privileges. (Or at least it cannot be run with elevated privileges by our users, none of which are admins on their boxes.) Since the ClickOnce deployment is handled by our build system, then those same coworkers blame me. They say the build failed. Doesn't matter that the build log shows a successful build, they claim it is my fault. I have written instructions as to how to use NuGet and not use the Microsoft.SqlServer.Types.dll. I have sent this to them for various projects over at least the last 5 years, I estimate between 10 and 15 times. Those coworkers still go back to putting the Microsoft.SqlServer.Types.dll into the project, resulting in the users being unable to install the app. Then those coworkers go back to blaming me for their actions.
So, because they either cannot grok it, I'm giving up. Better to just put it into a SSRS Report server, to at least reduce much of the problem. I still suspect that at least one of them will continue to include the Microsoft.SqlServer.Types.dll into a project that doesn't use it, only because it's a habit of theirs to copy and paste DLLs from one project to another.
Kindest Regards, Rod Connect with me on LinkedIn.