Optimizing Microsoft SQL Server Reporting Services: Performance and Access Reports from the Execution Log

37. Click the OK button on the Package Execution Results message box to close it.

38. Click Done to close the Executing DTS Package viewer.


We return to the DTS Designer.


39. Select Close under the Enterprise Manager icon in the upper left corner of the DTS Designer, as shown in Figure 22 (NOT Exit under File in the adjacent main menu).




Figure 22: Closing the DTS Designer to Return to Enterprise Manager

A DTS Designer message box appears, asking if we wish to save our changes to the DTS package, as depicted in Figure 23.


Figure 23: DTS Designer Message Box Asks If Changes Are to Be Saved

40. Click Yes to save our changes, and to close the message box and Executing DTS Package viewer.


We return to the Enterprise Manager console. A quick query or online browse of the new tables of the database that we have assembled will confirm the fact that they are, indeed, populated. The database we have created is “reporting ready,” as we will see in our next session. A simple reverse-engineer of the database from MS Visio generates the schema shown in Figure 24.


Figure 24: Simple Database Diagram (MS Visio) of the New Reporting Database

In our next article, we will examine the uses to which the new database might be put. We will perform setup and publication of the sample reports provided with Reporting Services as a “starter set,” and then go beyond that set and create a customized report to show the ease with which we might help the information consumers we support to meet general and specific needs. We will propose other considerations that will add value to this already rich resource, and discuss ways in which we can leverage Execution Log reporting to make us better report writers from multiple perspectives.

Summary

In this article, we introduced the Execution Log, discussing its nature in general, and several ways in which its contents can assist us in understanding the performance of our reports, the actions of users, and a host of other details about the reports we create in Reporting Services. We conducted a brief preview of the steps involved in establishing the capability to perform Execution Log reporting, using the tools provided as samples with the Reporting Services installation. We then set the scene for our practice example, describing a hypothetical scenario where we determine that we can provide multiple benefits to the information consumers within a client organization by “installing” the Execution Log reporting capability.


We discussed reasons for creating a reporting database as opposed to simply using the Execution Log in its original state, and then set about creating and populating the database. After copying the sample files included with Reporting Services to make this process easier for us, we opened and executed the table creation script to create the schema for our new reporting database. We then loaded and executed the DTS package provided to transform the Execution Log data and populate the new database tables, paving the way for exercises in reporting from the Execution Log data, which we will begin in our next article.

Copyright 2005 by the author.

]]>

Leave a comment

Your email address will not be published.