Great article. I have tried to solve several of these problems before with no success.
In every business there are several different groups of report users, from chief executives, to business analysts, to operational staff, who all need access to reliable and current data in order to track overall business performance, investigate the effectiveness of individual business functions, or simply for ad-hoc day-to-day reporting.
In most organizations, at least some attempt has been made to meet these reporting needs. Historically, however, the problem has been that the available reports have not always been up-to-date, or even accurate. Furthermore, individual departments have tended to adopt a "silo" approach, using different tools/systems to create reports that are useful within their silo, but not necessarily consistent or compatible with those produced by other departments. In many cases, there doesn’t even exist a shared understanding of the business data that underpin these reports.
SQL Server Reporting Services (SSRS), when it arrived, offered a much-needed means to centralize and standardize reporting across the business, and it has largely delivered. Having used SSRS 2005 for the past 4 years, I’ve found that, with a little effort, it can satisfy most business, ad-hoc, embedded, portal integration, web, and custom reporting needs. However, I’ve also found that small "gotchas" can halt progress and cause considerable frustration, as it’s not always easy to find ways round them in the documentation.
Ten Common SQL Server Reporting Services Challenges and Solutions
Random Posts
Loading…