MSAS Architect Bill Pearson concludes his examination of
Execution Log reporting. In this article, we practice the rapid deployment of
the core report set and create a sample custom report, to become familiar with
basic performance and auditing reporting in Reporting Services.
About the Series ...
article is a member of the series MSSQL Server 2000 Reporting Services.
The series is designed to introduce MSSQL Server 2000 Reporting Services ("Reporting
Services"), with the objective of presenting an overview of its features,
together with many tips and techniques for real-world use. For more information
on the series, as well as the hardware / software requirements to prepare
for the exercises we will undertake, please see my initial Database Journal article, A New Paradigm for Enterprise Reporting.
assumptions underlying the series are that you have correctly installed
Reporting Services, including Service Pack 1, along with the applications
upon which it relies, and that you have access and the other rights / privileges
required to complete the steps we undertake in my articles. For details on the
specifics of the adjustments necessary to quickly allow full freedom to
complete the exercises in this and subsequent articles, as well as important
assumptions regarding rights and privileges in general, please see earlier
articles in the series, as well as the Reporting Services Books Online.
article also relies upon sample files that are not automatically installed
along with Reporting Services. If the samples have not been installed in, or
were removed from, your environment, the samples can be found on the Reporting
Services installation CD. We will discuss accessing these files within the
steps of our practice session.
About the BlackBelt Articles ...
have stated in earlier BlackBelt articles, one of the greatest
challenges in writing tutorial / procedural articles is creating each article
to be a freestanding document that is complete unto itself. This is important,
because it means that readers can complete the lesson without reference to
previous articles or access to objects created elsewhere. When our objective
is the coverage of a specific technique surrounding one or more components of a
report, a given administrative function surrounding all reports, and other
scenarios where the focus of the session is not the creation of reports,
per se, can be challenging because a report or reports often has to be in place
before we can begin to cover the material with which the article concerns
articles represent an attempt to minimize the setup required in simply getting
to a point within an article where we can actually perform hands-on practice
with the component(s) under consideration. We will attempt to use existing
report samples or other "prefabricated" objects that either come
along as part of the installation of the applications involved, or that are
readily accessible to virtually any organization that has installed the
application. While we will often have to make modifications to the sample
involved (we will actually create a copy, to allow the original sample to
remain intact), to refine it to provide the backdrop we need to proceed with
the object or procedure upon which we wish to concentrate, we will still save a
great deal of time and distraction in getting to our objective. In some cases,
we will have to start from scratch with preparation, but my intention with the BlackBelt
articles will be to avoid this, if at all possible.
example we undertake in this article represents an infrequent exception to the "freestanding"
objective. To complete the steps we describe in this article, you will need to
have prepared for it by completing the steps detailed in the immediately
preceding article in the series, Prepare
the Execution Log for Reporting.
more information about the BlackBelt articles, see the section
entitled "About the BlackBelt Articles" in BlackBelt
Components: Manage Nulls in OLAP Reports.
introduced our previous article, Prepare the
Execution Log for Reporting, with a discussion about a valuable source of information
for performance and auditing analysis, identifying the Report Server
Execution Log as a great place to start for this sort of reporting. We
noted that the Execution Log captures data specific to individual reports,
including when a given report was run, identification of the user who ran it,
delivery destination of the report, and which rendering format was used, among
discussing the nature of Execution Logging in general, we touched upon
several of the ways in which it 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. Working within a practice example
where we responded to the expressed business needs of a hypothetical group of information
consumers, we then performed transformation of the data in the Execution Log
to a user-friendly reporting data source. We used the tools provided as samples
with the Reporting Services installation to create and populate a MSSQL Server
database, noting several of the benefits that would accrue to the information
consumers. For the detailed steps we undertook, and to prepare to accomplish
the steps of this article, please see Prepare the Execution Log for Reporting.
in this article will be an examination of some of the uses to which the new Execution
Log database might be put. Our examination will consist of hands-on 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.
session we will:
hypothetical business requirements behind the procedures in this and the preceding
Review the Execution
Log reporting database we created in our last lesson, focusing on its
schema and the information it contains;
possible value-adds that come with Execution Log reporting;
Make copies of
the sample report set provided with Reporting Services in a convenient
sample report copies, for execution within Report Manager;
copy of a popular report, to meet extended business requirements from the
information consumers group.
Execution Log Performance and Audit Reports
Objective and Business Scenario
As a basis for our
practice examples in both our last and current sessions, we established a
Reporting Services business requirement of a group of information consumers at a hypothetical client
location. The consumers expressed the need to monitor report activity, for
purposes of performance and auditing evaluation, for their recently implemented
Reporting Services installation. The consumers asked that we work with them to
create a database that is populated and maintained with this data for many
potential uses. We accepted the project, informing the group that, while we
had created numerous relatively elaborate databases of this sort for clients in
the past, our initial pilot in this instance would include Execution Log
reporting capabilities that could be implemented rapidly and easily, using the
tools that accompany the installation of Reporting Services.
We made it clear that
we would likely expand the capabilities to many other measures for overall
performance and auditing monitoring after our pilot. We explained that
beginning with the prefabricated "starter set" would be efficient, because
Reporting Services provided a script to construct a basic reporting database to
house the Execution Log data that it generates. In addition to the
creation script, a DTS package to transform the data, and to populate (and
prospectively update) the new database, was also included. Finally, a set of basic
sample reports were included in the same "extras" bundle, which we
could run as soon as we had transformed data from the Execution Log to
the newly created database.
We pointed out that we
had found this approach to be a "quick win" with regard to getting
basic functionality in place; we also indicated that this was a great time in
the Reporting Services implementation to be making performance and audit
analysis capabilities available - just as we were beginning to write our first
enterprise reports. The sample reports would serve several complementary,
value-added functions, including:
Provision of a
means for the Administrator to immediately see who was performing what actions
within the new system;
an excellent learning tool for new report authors, whereby they could obtain
confirmation that their new reports had executed;
- Presentation of basic report
samples, upon which the ultimate users could base requests for customization. (This
could save a great deal of time in obtaining the requirements from users who,
although they knew they needed these reports, may not have known "where to
start" in providing a useful specification for their design.)
- Facilitation of optimization of
reports and their underlying queries, both at times during and after creation,
and at various points in time as a part of ongoing system upkeep and
maintenance (tuning could be suggested, for example, as data sources grew in
size, as the number of information consumers increased, as security needs
changed, and so forth).
With the Execution
Log data source now in place, we are ready to proceed with aligning and
publishing the sample report set to kick off the new reporting efforts. Included
on the Reporting Services installation CD is a group of sample Execution Log
reports. These reports include the following titles:
Executed by Day
sample files also include the Visual Studio project (.rptproj) and solution
(.sln) files for the report set, together with a data source connection file
(.rds). The reports and objects are designed to be used with the Execution Log
database we created and populated in our last session. A database diagram of
the database is shown
in Illustration 1.
Illustration 1: Simple
Database Diagram (MS Visio) of the New Reporting Database
The Execution Log Database
We discussed reasons
for creating a reporting database as opposed to simply using the Execution
Log in its original state in our previous session. We then opened and
executed the provided table creation script, using MSSQL Server
Query Analyzer, to create the schema for our new reporting database. We
then loaded and executed the accompanying DTS package to transform the Execution Log data and populate the
new database tables.
information contained in the transformed data includes details that can assist us in determining
report efficiency and frequency of usage, together with myriad details that
assist in resource planning, monitoring the activities of users, and so forth.
Specific data items that we can obtain from our Execution Log database
The name of
the Report Server Instance that handled a given request;
Type (either User or System);
Format of the report;
values used for the execution of a given report;
The Start and
Stop times of a given report process, from which duration is
of Processing Duration spent retrieving the data, processing the
report, and rendering the report;
(including Live, Cache, Snapshot, or History) of
Processing for a
given report (indicating either a successful process, or the code of the
first Error Condition encountered);
of each generated report.
of rows returned from query(ies) underlying each report.
Considerations and Comments
Before we can work with the sample
reports, we need to take several preparatory steps to establish connectivity.
As part of our setup, we will create a Data Source Connection, then upload the report files we have relocated to a
convenient location, as well as performing various read, and other, actions
with the sample reports. We will also be modifying a copy of a report to
customize it to fit a specific consumer need, to get some practice in creating
new capabilities within our report
set, as well as performing other actions within Reporting Services.
To complete the procedures we will undertake,
you will need to have the appropriate access and privileges, at the MSSQL
Server 2000 level, and within Reporting Services, MSSQL Server Analysis
Manager, and the file system, to perform the respective actions. You will also need access to the Reporting Services
installation CD, from when we will be copying the sample report files to our
Populating a Folder with the Components We Will Need
prepare for our session with the Execution Log sample reports, we will
create a folder to house the reports, along with other objects that we will
need to complete our practice exercises. The folder can be created anywhere on
the PC that is convenient from a local perspective.
to launch Windows Explorer.
Navigate to a
convenient place to create the folder that will contain the "collateral"
for our practice session.
folder named as follows:
folder appears similar to that depicted in Illustration 2.
Illustration 2: New
Folder in Place to House Lesson Components
Reporting Services installation CD on an accessible CD drive.
the following folder (or it's equivalent, substituting your own CD drive for "F:"
F:\extras\Execution Log Sample Reports
of the Execution Log Sample Reports folder appear similar to that shown
in Illustration 3.
Illustration 3: The
Sample Execution Log Reports Appear
--> Select All from the Windows Explorer
contents of the Execution Log Sample Reports folder become highlighted.
--> Copy from the main menu.
the new RS014 folder we created above.
from the context menu that appears, as depicted in Illustration 4.
Illustration 4: Select
Paste to Place the Sample File Copies
copied files (there should be eleven) appear as shown in Illustration 5.
Illustration 5: The
Sample Report Files Appear
next step will be to upload the samples into Report
Manager, where we can review them and see what information they can deliver
to the information consumers. The first step of this process will be to
establish a Data Source Connection, as we learned in my Database
Journal article Managing
Reporting Services: Data Connections and Uploads. We will use Report Manager,
versus the Report Designer interface, for this purpose, but keep in mind
that the upload / publication process can also be managed from within Report
a Data Source Connection
We learned in Managing
Reporting Services: Data Connections and Uploads that the purpose of the Report
Server is to serve, or to act as a presentation platform, for our
reports. It connects to data sources to retrieve the data that
it presents in the reports it "hosts." When we refer to a data
source in Reporting Services, we are referring to a collection of
properties, in effect, that represent a connection to a given data source.
This collection of properties has a name, as it does in other applications
where data sources exist (a scenario with which most of us are familiar). Data
sources contain the following, where applicable:
of the data processing extension we use to process queries of the type for
which we intend to use the connection;
string that allows us to locate the source;
credentials involved in allowing us to read the data within the source.
As we have noted in
various articles of the series, a data source connection can be embedded
in a report (where it is typically defined within the creation process); it can
also be defined as a shared data source item that is managed by a Report
Server. We will be establishing a shared data source item for the Execution
Log reports, so that the entire set can reference the same self-contained, underlying
data source. In addition to ease of referencing in the reports, our shared data
source will provide the benefit of maintenance from a single location, as we
will create a shared data source for the reports before we upload them
to provide an immediate mechanism to link them to the data they are intended to
present. The data source connection will be independent of the reports
themselves. Our set of sample reports will share data housed in a single
source, the RSExecutionLog database, an excellent application of a
shared data source.
NOTE: For the setup of the RSExecutionLog
database, which we will require to complete prospective steps of our
practice example, see Prepare the Execution Log for
first step is to start Report Manager.
the Reporting Services program group that installs within a
typical setup. The equivalent on my PC appears as depicted in Illustration
Illustration 6: Navigate
to Report Manager ...
Manager to initialize the application.
NOTE: If Report Manager does not
appear in the manner shown, whether because you declined setup of the program
group, a disablement of the feature, or other, unknown reason, simply get there
by typing the appropriate URL into the address bar of your web browser. The
default URL is as follows:
As an example, my <webservername> would be MOTHER1,
the name of my server, and would appear, in this approach, in my browser Address
line as shown in Illustration 7.
Illustration 7: Navigate
to Report Manager ... Alternative Route
arrive at the Report Manager Folder View. Let's create a new
folder, within which we can isolate the reports we will be uploading.
The New Folder page appears.
following into the Name box:
Execution Log Reports
following into the Description box:
Performance & Auditing Reports based upon the Report Server Execution Log
our input, the New Folder page appears as depicted in Illustration 8.
The New Folder Page, with Input
returned to the Home page Folder View, and see our new folder
appear on the Contents tab, as shown in Illustration 9.
The Execution Log Reports Folder, on the Folder View - Contents Tab
Click the link
for the new Execution Log Reports folder, to open it.
enter the Execution Log Reports folder, which is empty at present.
Data Source atop the Folder View, as depicted in Illustration 10.
Illustration 10: Click
New Data Source atop Report Manager Folder View
The New Data Source page appears.
following into the Name box:
following into the Description box:
Shared Data Source for Execution Log Reporting
the checkbox to the left of Enable this data source is checked (the
Ensure that Microsoft
SQL Server is selected in the Connection Type selector.
following into the Connection String text box:
data source="(local)";persist security info=False;initial catalog=RSExecutionLog
Using, select Windows NT Integrated Security.
NOTE: Adapt the Data Source and authentication settings to
your own environment, as necessary (for example, if the RSExecutionLog database
is on another server and access is being attempted across a network, etc.)
our input, the New Data Source page appears as shown in Illustration 11
The New Data Source Page, with Input
to accept the shared data source.
returned to the Execution Log Reports page, Folder View, and see
our new data source appear on the Contents tab, as depicted in Illustration
The Data Source Appears on the Folder View, Contents Tab
created a data source, we will now upload the sample Execution Log
reports from the Report Manager. We will then marry the reports to the
common data source we have created.
will perform the upload of the sample Execution Log reports, by taking
the following steps within Report Manager:
File atop the Folder View, Content tab.
File page appears.
Navigate to the location of the sample reports, folder RS014,
which we created and populated in the first part of our practice procedure
RS014 appears in the Choose File dialog, once located, as shown
in Illustration 13.
Click the RS014
folder to open it.
sample report definition files (.rdl's) and other object files
appear. At this point, we will select the Today's Reports report
Click the todays
reports.rdl file, as depicted in Illustration 14.
Selecting the Today's Reports File from among the Sample Set
Click the Open
button on the dialog.
default name in the Name box to the following:
reports.rdl file, along with modified title, appears in the respective
boxes of the Upload File page, as shown in Illustration 15.
The Today's Reports File - Selected for Upload
report file uploads. We can see it appear listed on the Folder view, Content
tab, where we saw the new data source appear earlier.
Repeat steps 1 through 7
above, for each of the following files in the RS014
folder (giving each a logical name within the respective Name box), from
which we uploaded todays reports.rdl:
longest running reports.rdl
we have uploaded the individual reports, we can see them appear listed on the Execution
Log Reports page, Folder View, Content tab, as
depicted in Illustration 16.
The Execution Log Reports Appear in the Folder View - Content Tab
uploaded the seven reports listed above, we can click on each to ascertain that
the report is executing properly. Should any connectivity issues emerge, see Testing the Reports - and
Resolving Data Source Issues in my article Managing
Reporting Services: Data Connections and Uploads, as well as the Books
Online, for guidance.
Open each report, executing it
to overview the data it presents and other features.
now have a working data source, as well as a group of sample reports that not
only provide a "quick start" for the information consumers'
performance and auditing reporting efforts, but which also act as a good set of
reports to follow when constructing new reports along the same lines. We will
create a custom report next, to obtain a little more familiarity with the source
data, as well as with a representative report's layout and other
Close the browser, when
finished exploring the various reports.
a Custom Audit Report
will perform modifications to a copy of one of the existing Execution Log
reports we have uploaded, to customize it to meet a local requirement. The
procedure that we follow would be similar for modifications of any of the
sample reports, with obvious differences arising in varying layouts (use of a
table data region versus a matrix data region, etc.), and so forth. As we have
mentioned already, the reports provide an excellent starting point from which
to build a more "environment sensitive set," and we will pose a simple
scenario where this is just the action we take.
say that, upon review of the Execution Log reports we have uploaded, the
client information consumers group with whom we are working are excited with
the results we have been able to obtain so quickly. Almost immediately,
requests for modifications are communicated, but, then, that was just the
reaction we had hoped for. This sort of feedback will get us to the ultimate
report destination far faster than beginning with a blank drafting board, and
asking the group (a team with only minimal exposure to Reporting Services in
the first place) to describe "everything they wish to see in a performance
/ access report based upon the Execution Log."
the first requests is for a modest set of changes to a report that has met with
immediate popularity: the Today's Reports report. The information
consumers tell us that, with the addition of 1) a report type (report,
snapshot, etc.) and 2) the physical location of the report (i.e., the
folder within which it is stored), Today's Reports will be perfect to
fit a current requirement. While more elaborate requests will no doubt follow,
we agree to make the changes once we confirm our understanding of them.
First, we will launch Reporting
Services' Report Designer, found in Microsoft Visual Studio .NET 2003.
the Microsoft Visual Studio .NET 2003 in the Programs group, as
appropriate. The equivalent on my PC appears as shown in Illustration 17.
Accessing Microsoft Visual Studio .NET 2003 ...
Studio .NET opens
in the Design Environment.
--> Open from the main menu.
from the cascading menu, as depicted in Illustration 18.
Selecting a New Project
Project dialog appears.
the executionlog.rptproj file, which we copied into the RS014 folder
we created earlier, as shown in Illustration 19.
Illustration 19: Navigate
to the Execution Log Sample Reports Project File
Click the executionlog.rptproj
file to select it.
Click Open to
open the project file.
project file opens. Let's make a quick clone of the report file we want to
modify, so as to keep the other samples intact for now. (I like to keep a "pristine
set" around for just such situations as this).
In the Solution
Explorer, right-click the Reports folder.
--> Add Existing Item from the cascading menus, as
depicted in Illustration 20.
Existing Items dialog appears.
the RS014 folder.
the todays reports.rdl file, within the RS014 folder.
from the context menu that appears, as shown in Illustration 21.
Illustration 21: Copy
the File in the Add Existing Item Dialog (Partial View) ...
the white space to the right of the files in the same dialog.
from the context menu that appears, as depicted in Illustration 22.
Illustration 22: Select
Paste to Place the Report File Copy ...
titled Copy of todays reports.rdl appears in the folder.
the Copy of todays reports.rdl file.
Select Rename from the context menu that appears, as
shown in Illustration 23.
Illustration 23: Select
Rename from the Context Menu ...
following into the write-enabled file title:
the title to accept the modification / close the Edit capability.
renamed report file clone, Custom_Todays_Reports.rdl, appears in the Add Existing Item Dialog,
as depicted in Illustration
Illustration 24: The
Report Clone Appears (Circled) in the Dialog
Double-click Custom_Todays_Reports.rdl to select and add it to the
The report file appears
in the Solution Explorer, as shown in Illustration 25.
Illustration 25: The
Report Clone Appears (Circled) in the Solution Explorer
Double-click Custom_Todays_Reports.rdl in the Solution Explorer to
open it in Layout view.
The report file opens,
and appears on the Layout tab, as depicted in Illustration 26.
Illustration 26: The
Report File Opens in Layout View
stage, we need to add the data fields Report Type and Path (the
file system location for the report file) to the DataSet. To do so, we
will modify the DataSet on the Data tab.
Click the Data tab.
Click the Graphical Query Designer
button, as necessary, to shift to the graphic designer, which consists of a
toolbar and four panes, as shown in Illustration 27.
the white space to the right of the tables, within the Diagram pane.
Table ... from the context menu that appears, as depicted in Illustration 28.
Illustration 28: Select
Add Table ...
Table dialog appears, defaulted to the Tables tab.
Types from the tables listed in the dialog, as shown in Illustration 29.
Illustration 29: Select
the Report Types Table ...
to dismiss the Add Table dialog.
Types table appears, along with the other tables, in the Diagram pane.
In the Report
Types table, click the checkbox to the immediate left of Name, to
select the field into the existing query.
In the Grid
pane (the pane containing rows and columns, just below the Diagram pane),
type the following into the Alias column of the grid for the Name
row (likely the bottom row in the Grid pane), to replace the default
In the Reports
table, click the checkbox to the immediate left of Path, to select
the field into the existing query.
The Diagram and Grid panes appear,
with our selections / additions, as depicted
in Illustration 30.
Illustration 30: Our
Selections and Additions in the Diagram and Grid Panes (Circled)
Now, let's go to the Layout
tab and make the additions to the report layout.
Click the Layout
Click the box
containing the words "Total Executions."
gray column and row headers for the table data region appear.
the column header above the box containing the words "Total Executions."
Column to the Right from the context menu that appears, as shown in Illustration
Inserting a Column into the Table Data Region
new column appears.
following into the top text box of the new column:
Click the Type
field in the Fields List of the Fields window.
Drag the field
to the bottom row of the new column we created, and labeled Type above.
Drop the field
into the textbox.
field appears in the bottom textbox of the new Type column, as depicted
in Illustration 32.
Illustration 32: The
Type Field Appears in the New Type Column
NOTE: If the Fields window is not initially visible in the
Report Designer, select View --> Fields from the main menu to resurrect it.
the column header for the column we just added above, now labeled Type.
(Click anywhere in the column to make the header reappear, if necessary).
Column to the Right from the context menu that appears, once again.
new column appears.
following into the top text box of the new column:
Click the Path
field in the Fields List of the Fields window.
Drag the field
to the bottom row of the new column we created, and labeled Location
Drop the field
into the textbox.
field appears in the bottom textbox of the new Location column as shown
in Illustration 33.
Illustration 33: The
Path Field Appears in the New Location Column
Test the New Custom Audit Report
Let's test the new report by moving to the Preview tab.
1. Click the Preview tab.
2. Select a date from the Select Date parameter selector atop the Preview tab.
NOTE: Keep in mind that the DTS update script we ran in our previous article to populate the Execution Log reporting database (also created in our last article) will need to be rerun to update the tables for any execution activity that has transpired since the last update. The DTS update script can, of course, be scheduled to do this at predetermined intervals (such as overnight, or far more frequently), but the updates will obviously determine the dates that appear in the parameter selector, as the picklist is populated via a query against a table in the database.
3. Click the View Report button to execute the report.
The report executes, and the preview, similar to the one depicted in Illustration 34 appears.
Illustration 34: Inserting a Column into the Table Data Region
4. Expand ("drill down") on a line item in the report by clicking the "+" sign to its left.
5. Repeat the drilldown at the next level.
The report, with a selected line item expanded, appears similar to that shown in Illustration 35.
Illustration 35: Report Preview, with Expanded Line Item
Our new fields appear at the proper levels, and we see that we have met the requirements of the information consumers.
Far more customization can be accomplished with the sample report set, as most of us can appreciate, to add / rearrange various data fields that originate in the Execution Log. Moreover, numerous enhancements can be made to further refine the reports (an example might be to exclude the Execution Log audit and performance reports themselves from selection within our report structures, to allow for focus upon actual production reports, etc.).
From the perspective of data upon which we can report, the information housed in the Execution Log is only the beginning. Performance, auditing, and other data elements, from a host of other sources (including web servers, the Windows Event Log, trace files, and many others) can be added to a central "administration" database for a host of uses. We have only to create DTS tasks to move the data from the repositories that house them, and to bring them into our central reporting data source, to provide an integrated view of many aspects of our business intelligence operations. (I will focus on various administrative reporting scenarios in prospective articles, where I will share some of the administration / metadata reporting databases I have created for current and past clients.) The complementary power of the MSSQL Server components can be leveraged to produce virtually any data source we might require, with a little forethought and know-how. Reporting Services can then present that data in virtually any layout we can envision, and deliver it through numerous channels to the appropriate knowledge workers.
6. Select File --> Save All to save all work to this point.
7. Exit Visual Studio .NET when desired.
Summary and Conclusion ...
In this article, we continued the examination of Execution Log performance and audit reporting begun in the previous article of the series, Prepare the Execution Log for Reporting. Our focus here was an examination of some of the uses to which the Execution Log database, created in the previous session, might be put. We began this article with a review of the steps we took to prepare the data contained in the Execution Log for reporting, and then moved into a hands-on practice session with the sample reports provided with Reporting Services as a "starter" set.
After discussing multiple benefits that the sample reports can provide, and after reviewing the business requirements of a hypothetical group of information consumers (which dictated the steps we took in the practice session that followed), we prepared our environments for our practice exercises. Next, we uploaded copies of the sample reports, to see Reporting Services in action with the Execution Log data we had transformed in the previous article.
We then created a custom report, in accordance with specifications received from the information consumers based upon their initial interaction with the published reports. Once the required additions were made, we verified the effectiveness of our customized report by viewing it in Report Designer, ensuring that it returned data as expected. Throughout the session we commented on relevant considerations as they arose, noting the results we obtained for each step we took in the practice examples, as well as commenting on ways to extend the Execution Log data source for other uses.
» See All Articles by Columnist William E. Pearson, III
Discuss this article in the MSSQL Server 2000 Reporting Services Forum.