At dotnet Report, were always striving to improve our report building solution and design more awesome features that would help your end users. Ultimately, we want to help you bring more value to your software application by adding useful features. An example is one of the recent updates where we added the ability to add date range comparison data to your time line reports.
So for our next release, one of the key new feature we are working on is adding Stored Procedure Support. You can see the progress here in this github branch.
Using Stored Procedures to create reports is a pretty established technique, and is one of the main ways .Net developers use to create reports for their users, especially if they are using Microsoft SQL Server Reporting Services. It is also one of the most common feature requests we get, since dotnet Report Builder doesn’t support Stored Procedures yet.
The main reason we didn’t prioritize stored procedure for reporting was because our platform is all about less coding and letting end users pick different columns from different tables and just create reports easily that way, and we did not want our users to start writing Stored Procs just like they did for SSRS. Plus, we have an alternate workaround to create Views instead of Stored Procedure, and that what we advised our users. This alternate works in most situations, so we have the 80/20 rule going in our favor.
Yet as we are constantly looking for new reporting features to add and what fits with our vision for dotnet Report, stored procedure support has definitely been on the table for a while. One key reason is that if software developers were using SSRS with stored procedures, they can easily port them over to dotnet Report and it could become a lot more seamless transition to the dotnet Reporting engine when switching.
Our goal is to still let your end users create customized reports extremely easily and seamlessly embed our friendly report builder inside your application. So adding stored procedures support will be done in a similar manner. In the “Setup” section, we will be adding a new tab to add stored procedures, that will be used in the front end as a new report type named “Custom Reports”. When an end user chooses the “Custom Report” type, they will be shown the list of stored procedures they can choose, instead of showing them Data Tables and Columns. When saving and running the report, it will execute the stored procedure instead of a custom built SQL statement, and the output will still be presented as a table. This would essentially be the first phase, with additional options for Report Output added later.
So please feel free to review the code and progress in GitHub and provide any feedback you have on our vision for using stored procedures for reporting. We look forward to hearing your feedback and having Stored Procedure available in dotnet Report within the next couple of months!
-The dotnet Report Development Team