1

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:

  1. Developer gets tools
  2. Developer starts new project and works with users to identify reporting priorities based on needs and feasibility
  3. Translate reports to specifications using spec worksheet - weed out data exports from reports
  4. Users sign off on report spec
  5. Develop and Test report
  6. Report is reviewed by team member for code and spec
  7. Report is tested by user and accepted/reject
  8. Report is deployed to production and tested by Admin, Developer and User
  9. Report is periodically reviewed for lack of usage, error codes, excessive run time

1 Answer 1

1

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.

2
  • I also use the RSScripter - it's most excellent. Using procs is also on the list - for dependency tracking primarily, but the tuning is a good feature as well. Encryption keys were backed up long ago. Thanks for your comments!
    – Sam
    Oct 16, 2009 at 1:07
  • I'll take this validation as an answer.
    – Sam
    Oct 19, 2009 at 23:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .