SSRS Reports As User Interface Part II

SSRS Reports As User Interface
Last week I explained how I came to use SSRS Reports as user interface. This week I’ll discuss how I was able to very quickly provide users with an administrative console to adjust the configuration of a web based application using only Reporting Services and SQL Server.

Before I begin, I should probably point out that what I’m about to describe is pretty far off the beaten path for Reporting Services. Security, usability and support are all legitimate concerns that would need to be justified before I would recommend anyone else taking this approach. However, given the right set of circumstances that I don’t believe are all that extraordinary, you might find this useful.

The first question you might have is, “Why would I want to do this? If I have SSRS installed in my environment, wouldn’t I also have IIS, ASP.Net, VB.Net and or C# available to create a proper UI?.” My answer is yes, you most likely would and those are far better tools. However, in my case the company did not allow anyone outside of the development group to make enhancements to the product and without a request from the business group, new features rarely saw the light of day, or even budget consideration.

Your next concern might be, “So you are telling me the connection I use for my reports is going to be inserting and updating data? You are crazy! Security would have my badge and laugh me out of the building.” Again, I would say you are probably correct. If your report users log into the Report Manager and have admin privileges, with this kind of access they have the potential to do some harm. In the cases I am about to describe though, I have exposed only read and execute SQL privileges to my report user connection and have complete control over stored procedures in the database. Yes, if a devious employee had access to upload an RDL AND knew the names and usage of stored procedures in the system, they could alter data in unintended ways.