Skip navigation

Are You Ready for Report Builder 2.0?

Report Builder 2.0 isn’t right for every environment. To decide whether the application will benefit your organization, you need to determine whether your report developers and end users can perform the following operations:

  • Point to a specific SQL Server Reporting Services (SSRS) instance. The SSRS instance must be properly enabled and started, and users must know how to make the initial connection to the correct instance.
  • Select an appropriate report data source. Users must know what a data source is, as well as how to select a cataloged shared data source or create a new data source to point to the report database, file, or other source of data. Report Builder 2.0 makes this task easier by exposing the SSRS catalog that could expose shared data sources, but unless the report DBA created a special directory for data sources for users to use, exposing the catalog might not help much.
  • Select an appropriate report data row source. Users must know how to choose an appropriate table, view, or stored procedure to which the report DBA has granted sufficient rights. In some cases the user will need to create a SQL query to fetch the report data. Note that granting rights to even benign tables can be problematic if users don’t know how to build a WHERE clause or why doing so is important.
  • Understand the performance implications of data retrieval. That is, are the reports that users create built against live or snapshot data? Do users have access to the production database, where their queries can affect performance?
  • Understand how to use report elements to lay out reports. Another option is to use the Report wizard.
  • Save/change new reports to the SSRS catalog. Note that it’s a big decision to let users modify existing reports.
  • Access the data referenced by the queries. Although the database itself should be locked down, users need access to some of the data.
  • Understand how to deal with exceptions. Users must know how to deal with typical exceptions. Like SSRS, locally generated reports expose every exception to end users—who are least likely to be able to address such issues, even though they might have caused the issue. I suggest that you create a wiki of typical errors, including the report DBA’s suggested solutions.

Organizations that implement Report Builder 2.0 will need to invest in a considerable amount of training for their report DBAs, report developers, and end users.

TAGS: Security SQL
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish