http://www2.sqlblog.com/blogs/adam_machanic/archive/2010/04/13/t-sql-tuesday-005-on-technical-reporting.aspxReports. They're supposed to look nice. They're supposed to be a method by which people can get vital information into their heads. And that's obvious, right? So obvious that you're undoubtedly getting ready to close this tab and go find something betterenCommunityServer 2.1 SP2 (Build: 61129.1)http://www2.sqlblog.com/blogs/adam_machanic/archive/2010/04/13/t-sql-tuesday-005-on-technical-reporting.aspx#24264Wed, 14 Apr 2010 04:40:32 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:24264Robert L Davis<p>Good post!! I ran into some of these issues early in my career when I was a database developer. one of the struggles we had was trying to find a balance between what management wanted alerts for and what was manageable. It took creating meaningful, useful reports for us to get away from mega-alerting via SQL Server.</p> http://www2.sqlblog.com/blogs/adam_machanic/archive/2010/04/13/t-sql-tuesday-005-on-technical-reporting.aspx#24270Wed, 14 Apr 2010 06:55:19 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:24270khalid<p>good idea</p> http://www2.sqlblog.com/blogs/adam_machanic/archive/2010/04/13/t-sql-tuesday-005-on-technical-reporting.aspx#24277Wed, 14 Apr 2010 12:36:14 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:24277Stefbauer<p>Good post! ... but really wanted to say THANKS for the #tsql2sday event, it is a GREAT idea to force some &quot;focus&quot; on a topic for a day, as well as give folks that blog less than other a reason to write. &nbsp;Thanks for putting it together!</p>