Optimizing Microsoft SQL Server Reporting Services: Execution Log Reporting: Preparation as a Data Source
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.
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