We're expanding our reporting services usage and are trying to set up some guidelines for developers and admins on managing and developing for the system.
Do you have any advice on keeping a reporting server running well and organized?
Is there anything you might have done differently?
We are using 2005 and are planning to move to 2008 R2 on a dedicated server in the next year.
Our planned process looks like this:
- Developer gets tools
- Developer starts new project and works with users to identify reporting priorities based on needs and feasibility
- Translate reports to specifications using spec worksheet - weed out data exports from reports
- Users sign off on report spec
- Develop and Test report
- Report is reviewed by team member for code and spec
- Report is tested by user and accepted/reject
- Report is deployed to production and tested by Admin, Developer and User
- Report is periodically reviewed for lack of usage, error codes, excessive run time
Your plan looks essentially like what we do at my company. Make sure that you have good backups of your encryption key for Reporting Services. That would be the most common thing that I've encountered with Reporting Services installations that is problemattic. I use Jasper Smith's Reporting Services Scripter to make Development to QA to Production migrations very easy. I also enforce that all reports use stored procedures which gives me flexibility as a DBA to tune the TSQL Code easier.