Many years ago I worked on a project converting a Windows application into a web site. One of the interesting things about the project was the aspect of reporting. The original windows application used Crystal Reports for reporting. It was bundled with Visual Studio, and freely distributed. We used Chrystal Reports in our Proof of Concept web site, and found it worked pretty well. Then we started looking at the costs for going into production, and purchasing the licenses for hosting Crystal Reports on a web server. We were surprised to find the necessary license fees for Chrystal Reports alone, for our intended implementation, was almost One Million Dollars USD. It was time for a new plan.
It turns out that Microsoft SQL Server Reporting Services was in a final beta stage for the very first version. Microsoft released Reporting Services just before the release of SQL Server 2005, using a version that worked with SQL Server 2000. As things turned out, SQL Server Reporting Services saved our project. Even after being released, the product license for our implementation was a few thousand dollars USD, instead of the large amount we had found before. Moreover, the cost of converting our reports was minimal since we were creating a new web site from scratch.
Although Reporting Services still works primarily as a Two Tiered report generator, the report viewer in modern versions of Visual Studio can be used for report presentation as well. If you use the report viewer tool, you can build reports that work without being connected directly to a database. You can define your data sources to work with Data Tables, which can be populated using any technique available to you. So, you can still run a query or stored procedure against a database and use it as a data source for your report. Or, if you prefer, you can build a data table from scratch, and then bind that data table to a report in Dot Net code.
The only problem with this solution is that you do not have access to the other features build into Reporting Services. The report scheduler, paging, Email distribution, and other features are not accessible outside of reporting services. I’m interested in how folks are using SQL Server Reporting Services with data stores other than relational databases. Are you using ODBC to connect with non-sql data stores? Are you rolling your own implementation using some other technique? What have you found that works for you. You can share your experience by leaving a comment below.
Cheer
Ben