Basics of SQL Server 2005 Reporting Services
Part 1
Basics and Introduction to SQL Server 2005 Reporting Services
This topics include Part1, Part 2 ,Part 3, Part 4 for better understand for beginners.
Building
and deploying basic reports
If ever there was job for
"real" developers to shuffle to their juniors, it is building
reports. It's not real development anyway; it's more like glorified formatting.
Besides, the esoteric tools that you use to build reports try to provide an
abstraction layer, which often prevents you from having any real control over
the report. I've heard all these arguments before. If this sounds like a
conversation you've had by the water cooler, then I invite you to take a closer
look at SQL Server 2005 Reporting Services (SSRS).
SSRS 2005 is the latest version of
SQL Reporting Services, and ships with all versions of SQL Server 2005. SSRS
allows you to quickly and easily create reports from multiple database sources.
The finished reports can be presented directly from the reporting services
website, or they can be displayed in your web- or Windows-based applications.
Reports can be exported to multiple formats, including comma delimited text,
XML, portable document format (pdf) and Microsoft Excel.
This article is the first of four
parts, which will provide in-depth coverage of SQL Server 2005 Reporting
Services:
- Part 1 covers the basics of the SSRS. It demonstrates how to build quick, simple reports and will familiarize you with the basic Report Designer environment
- Part 2 will cover use of custom functions, aggregate functions, sub-reporting, the matrix control, drill-downs, and sorting.
- Part 3 will take an in-depth look at the charting control
- Part 4 digs into the actual Report Definition Language (RDL) and the new Report Builder tool.
Installing
and configuring Reporting Services
After much debate, we decided that
full installation and configuration details were outside the scope of an
article focused on how to build basic reports using SSRS, especially as there
are already several online resources that treat this area in detail. See, for
example:
http://msdn2.microsoft.com/en-us/library/ms143736.aspx
and
http://www.awprofessional.com/articles/article.asp?p=357694&seqNum=1&rl=1
Well worth reviewing are the details
in the latter on the need to install SSL on any machine hosting SSRS.
---Editor's installation notes---
In order to test the reports in this article, I went through a single-machine installation on Windows XP (meaning that SQL Server 2005, Reporting Services, and much more, are all installed on my poor laptop). Since I didn't install SSRS when I installed SQL Server 2005 (I didn't have IIS installed at the time), I had to first install IIS 5.1, and then Reporting Services (from the SS2005 disks). I then jumped immediately into Reporting Services Configuration Manager tool (All Programs ¬ SQL Server 2005 ¬ Configuration tools). The left panel acts as a sort of checklist of items to configure:
In order to test the reports in this article, I went through a single-machine installation on Windows XP (meaning that SQL Server 2005, Reporting Services, and much more, are all installed on my poor laptop). Since I didn't install SSRS when I installed SQL Server 2005 (I didn't have IIS installed at the time), I had to first install IIS 5.1, and then Reporting Services (from the SS2005 disks). I then jumped immediately into Reporting Services Configuration Manager tool (All Programs ¬ SQL Server 2005 ¬ Configuration tools). The left panel acts as a sort of checklist of items to configure:
All went well until the Database
Setup. Because I had not installed SSRS at the same time that I installed
SQL Server, the ReportServer and ReportServerTempDB were not
created by default. These databases hold all the report definitions and
reporting server configuration information. Connecting to SQL Server using Service
Credentials, the databases appeared to be created, but I received an error
suggesting that I didn't have permissions to perform the requested task, and a
red cross remained next to the Database Setup icon. This had me stumped
for a while – eventually I appeared to solve it by hopping to the Server
Status section, stopping the Report Server, opening SSMS and deleting both
the ReportServer and ReportServerTempDB databases, and then
restarting the Report Server and trying again! Even though I swear this didn't
work the first time I tried it, it seemed to do the trick the second time
(while I was on the phone moaning to Steve that I couldn't get it to work!).
However, I'm still not clear why I had the problem in the first place – or why
it suddenly went away.
This wasn't quite the end of my
problems. Installing SSRS creates two new virtual directories under the default
website on IIS. By default, they are named Reports and ReportServer.
The ReportServer site hosts a web service for running and managing
reports. The Reports site allows you upload reports from a browser and
run reports over the web. When I tried to navigate to
http://localhost/ReportServer I received the following error: "Failed to
access IIS metabase". Fortunately, the information on the error page is
quite useful (for a change) and this, coupled with a quick Google search, led
me to grant access to the metabase to the ASPNET user account by executing the
following from the directory housing the aspnet_regiis executable
(WINDOWS\Microsoft.NET\Framework\v2.0.50727, in my case):
spnet_regiis
-ga ASPNET
This did the trick, and I was up and
running. I received some raised eyebrows here when I proposed to install SSRS.
It made my long-suffering sys admin team particularly nervous. The 2000 version
of SSRS seems to have a very bad reputation among the Red Gate team, both as a
performance nightmare, and in one case for "completely annihilating"
a developer's machine. However, the above slight quirks aside, the SSRS 2005
experience seems pretty smooth and I've had no real performance, or other,
issues. So far.
-----End of Editor's note----
-----End of Editor's note----
Once you've completed the
installation and configuration process, the first thing to do is download the
code file for this article (see the Code Download link in the speech bubble to
the right of the article title). The code file contains a sample Visual Studio
project and a SQL Script for creating the ReportDemo database. You will
need this database if you want to follow the examples in this series of
articles so go ahead and create the database using the ReportingDemoDatabaseScript.sql
script or, alternatively, by restoring the provided ReportingDemo.bak file.
If you are using SQL Server
Authentication on your SQL Server you will also need to set up a login with
permissions to the ReportDemo database (for the examples, I set up a
login called DemoUser as a DBO on my ReportDemo database).
Using
the Report Wizard
There are two ways to create SSRS
Reports. You can build the report manually, or you can use the Report Wizard to
give yourself a head start. For this first report, we are going to take
advantage of the wizard. Start a new Business Intelligence project in Visual
Studio 2005. Then, from the menu, select Project > Add New Item.
Select the Report Wizard option and call the file
"FirstReportWZ.rdl". Click Add. Click Next on the
Welcome screen and this will bring you to the Select the Data Source
screen:
Select the New data source
radio button and give the data source a name. Select Microsoft SQL Server
as the type.
Note:
Use of the Shared data source option is actually a better option in most cases but, for the sake of this example, we will just create a new data source. We're going to set up a shared data source later in this article.
Use of the Shared data source option is actually a better option in most cases but, for the sake of this example, we will just create a new data source. We're going to set up a shared data source later in this article.
Click the Edit button to
bring up the Connection Properties dialog:
Enter or select a server name. The
default is to log on using Windows Authentication. If you are using SQL
Server Authentication, choose that setting, and enter the username and
password. Finally, select a database, in this case ReportingDemo. Make
sure you test the connection before you click OK.
Next up is the Design the Query
screen. You can use the Query Builder by clicking the button at the top left,
but in this case simply enter "Select * From Customer" into the Query
string text box and click Next. On the Select the Report Type simply
select the type you prefer (tabular or matrix) and hit Next.
This brings up the Design the
Table screen:
Select State in the Available
fields box and click the Group button. This will group the data in
the result set by State. Select Next. On the Choose the Table
Layout page, select the Stepped option and check the Enable Drilldown
checkbox. On the next screen, choose a style for your report (I chose Ocean)
and click Next.
This brings up the final screen, Completing
the Wizard:
It shows a summary of your report
options, and gives you an opportunity to rename the report and to preview it.
Click Finish to end the wizard.
You should be shown the report in
the standard Report Designer:
There are three tabs: Data, Layout
and Preview. You should be on the Layout tab. Click on the Preview
tab to view the report. Since this report doesn't take any arguments, it will
run as soon as you click on the tab.
Use the +/- symbols next to
the State abbreviations to expand and collapse the grouping of the
report.
Manual
report creation
The previous section, while perhaps
overly simplistic, does show you how to get a report up and running with zero
code and zero property setting. Obviously, such reports will not meet most
development requirements, but do not discount this option as a starting point
for more complicated reports. Once you've created a report with the Report
Wizard, you are free to make any modifications to it.
In this section, we are going to
create a more realistic report from scratch, including how to create and use a
shared data source object, stored procedures, and how to format your report,
set report properties and use report parameters.
Creating
a shared data source
Before we start the report, we are
going to build a shared data source i.e. a data source that is common to, and
can be used by, all of the reports on a reporting server. While each report can
contain its own connection information, it is good practice to use shared data
sources, as it will save you a lot time and headaches. This way, you only have
to set the connection information once. For example, let's say your company has
Development, Test and Production environments. If you put the connection
information into each report, you will have to change it each time when you
publish to Development, Test and Production. If you use a shared data source,
you still have to set up a data source object for each of three environments,
but you can simply publish the report to each environment, and they will
automatically use the connection information associated with that environment.
From the menu select Project >
Add New Item > Select Data Source. On the General tab, call the
data source "ReportsDB". Leave the Type as Microsoft SQL Server.
Click the Edit button on the right, and enter the connection information
for Reporting Demo, as before. Click OK on the Shared Data Source
screen and the data source is done.
Add
a new report
From the menu select Project >
Add New Item. Select Report and name it
"FirstReportMan.rdl". A new report will be added to the project, and
the Report Designer will open at the Data tab. At this point,
let's take a closer look at the Report Designer tool. At the top of the
Report Designer window are three tabs: Data, Layout and Preview.
The Data tab is used to build data sources for your report. The Layout
tab is the physical report designer where you set up the header, the footer and
the data presentation of the report. The Preview tab allows you to
actually run the report from Visual Studio 2005, without having to publish it
to a report server first. If your report takes parameters, the Preview
tab will ask you to fill them out before it runs the report.
The first thing we need to do is get
data into our report. At the top of the Data tab choose <New
Dataset…> from the dropdown list:
The Dataset dialog opens:
Name the dataset
"ReportData", and select the ReportsDB data source from the
dropdown. Select StoredProcedure as the command type, and enter
"spr_CustomerSelectAll" in the query string box. Click OK to
close the dialog.
Note:
spr_CustomerSelectAll is a very
simple, parameter-less stored procedure that selects all of the columns from
the Customer table. The source code is included in the
ReportingDemoDatabaseScript.sql script with the code download.
Test the dataset by clicking on the
big red exclamation point at the top of the report designer. This executes the
query and displays the results. You can repeat these steps if you wish to add
multiple datasets to your report.
Setting
up the report display
Next, switch to the Layout
tab. This is where you actually build the report display. Start by dragging a
table from the Toolbox, onto the Body section of the report. By default, the
table shows a header row at the top, a detail row in the middle and a footer
row at the bottom. You can add additional columns to the table by
right-clicking on one of the columns and selecting one of the two Insert
Column options.
Click on the Datasets tab
under Toolbox on the left-hand side of the Visual Studio environment. You
should see the ReportData dataset. Expand it, select FirstName
and drag it to the first cell of the body row of the table. This will display
the First Name field in the first column. Now put the LastName in the
second column, and the CustomerStatus in the third:
Note that, when you drag the column FirstName
into the body row of the table, SSRS make a guess as to what to call the row.
It calls it "First Name". You can click on the Preview tab to
view the report.
Adding
formatting
OK, so we have a basic, very plain,
report. Let's add some formatting to make it look good. Let's add the DateOfBirth
column to the table. You can expand and shrink the size of the columns by
highlighting and dragging:
If you wish to get rid of the footer
row of the table and then click on any field in the table. You will see a grey
box surround the table. Right-click on the icon at the beginning of the body
row and then click the Table Footer option to deselect it.
The table header is next. To format
all the cells in the header in the same way, click and drag over all the cells
to select them. Open the Properties window and set background color,
font, and so on.
Note, however, that if you wish to
change the justification of the text or the size, then you do so using the main
menu at the top, not via the properties window. Again, you can click on the Preview
tab to view the report.
Add
a report header
The table already has a header, but
the report can also have a header and footer. Report headers and footers appear
on every page of the report. Put the Report Designer in Layout
mode and select Report > Page Header from the menu. A new band
labeled Page Header appears on the report above the body. Drag a text
box onto the header and click directly on it. Type "My First Report",
not in the Properties window, but right on the control.
To adjust the text style and size of
your heading, highlight the text box and use the option from the top menu.
Formatting
Each field can have formatting.
Let's deal with that ugly Date of Birth field. The time information is
superfluous, so let's format the date properly. Right-click on the cell that
contains the date of birth, and choose Properties. Next, select the Format
tab.
Click on the second button (labeled "…")
to the right of the Format code field. When the dialog opens, use the
standard options. Select Date in the list on the left, then choose the
sample date format you want on the right. Click OK to close the dialog.
Click OK to close the Properties
window and then click on the Preview tab to view the report.
Setting
report properties
To access the report properties, you
need to be on the Layout tab of the Report Designer. When you
click on this tab, a new menu item, Report, activates. This menu gives
you options for turning on and off the report header and footer sections (as we
have seen), adding embedded images, setting report properties, and setting
report parameters.
Setting up the report print settings
is not intuitive, compared to other products. In the report Layout tab
you see your report with a ruler across the top. That ruler is set up in
inches. A standard sheet of paper is 8.5 x 11 inches. The default setting in
SSRS is to have a 1-inch margin all the way around the content area. So, at 8.5
inches wide with a 1-inch margin on the left and another on the right, you have
6.5 inches for content. Any more, and the content beyond the 6.5 inches will
spill over onto a second sheet of paper when printed. It will not
automatically shift to Landscape.
To get Landscape reports, you have
to make the proper report settings. Navigate to the Layout tab of the Report
Designer. From the Report menu select Report Properties.
Switch to the Layout tab of the dialog box. To switch to Landscape
printing, you need to change Page width to 11in and the Page height
to 8.5in.
On the same Layout tab, you
can also get up your report to display the data in multiple columns, and you
can control the margins. By default, all the margins are set at 1 inch.
Remember, if your report width, plus the right and left margins, is greater
than the width of the printer, you will get spill-over when you print out your
report.
Using
parameters
There are two ways to add parameters
to your reports. The first is to use parameters in the queries in your data
sources. The second is to set up parameters through the Report Parameters
dialog box. We will do both.
Query
parameters
First, we will set up parameters
using a data source query. Navigate to the Data tab, and click the "…"
button right next the Dataset dropdown box. The Dataset dialog
box opens and allows you to edit the query for the dataset. Change the Query
string from "spr_CustomerSelectAll" to
"spr_CustomerSelectByState".
Note:
spr_CustomerSelectByState accepts a parameter called StateCD that allows us to filter the data from the Customer table by State. Again, the source code is included in the ReportingDemoDatabaseScript.sql script with the code download.
spr_CustomerSelectByState accepts a parameter called StateCD that allows us to filter the data from the Customer table by State. Again, the source code is included in the ReportingDemoDatabaseScript.sql script with the code download.
Click OK and then run the
query by clicking the red exclamation point (!) on the Data tab toolbar.
You will be prompted to enter a parameter value for StateCD (the State code).
Enter "CA" and click OK. The query should return all the
customers that live in California.
Switch to the Preview tab.
Instead of the report just running, there should be a place for you to enter a
value for the "StateCD" and run the report. Enter "CA" and
click the View Report button. You should see your report filtered by
state.
To edit the parameters, or to add
new ones, switch to the Layout tab of the Report Designer and
open the Report Parameters dialog from the Report menu. First, we
are going to make the "State code" prompt a little more friendly.
Select StateCD in the Parameters list box then, in the Parameters
Properties box, change the prompt to read "State". In the Available
values section enter "California" and "CA" on the first
line. Enter "Louisiana" and "LA" on the second line.
This will make the prompt for
"State value" into a dropdown. You can also build additional datasets
into your report, and use the values in those datasets as criteria for
dropdowns.
Report
parameters
Now let's add a parameter that is not
used in a query. Click the Add button in the Report Parameters
dialog from the Report menu. Give the new parameter the name
"ReportTitle". Its Data type should be String. Set the Prompt
to "Report Title". Click OK and close the dialog box.
Drag a new text box onto the report
header area. Right-click on it and choose the Expression option. In the Edit
Expression dialog select Parameters. Double-click on the ReportTitle
parameter. This text box will now display the value you pass to the Report
Title parameter.
Switch to the Preview tab and
try it out.
Publishing
your reports
Up to now, you have been running
your reports in the Visual Studio 2005 environment but, to make them useful,
you must publish them to a report server. The easiest way to do this is to have
Visual Studio publish your reports.
Start by right-clicking on Project
in the Project Explorer and choose Properties.
Set TargetServerURL to the
URL of your report server. Use the TargetReportFolder property to set up
a folder for your reports. If the folder does not exist, the Publisher will
create it for you. The other key thing to pay attention to here is the OverwriteDataSources
property. When this property is set to "True", it will automatically
copy over all your data source objects when you publish. When set to
"False", it will copy any new data source objects, but it will not
overwrite existing ones. This is important when dealing with development, test
and production servers. You can publish a set of data source objects to each
server, pointed at the correct database, and never have to worry about what
database your reports are hitting in each environment.
From the Build menu select Deploy
Solution. This will publish the project to the selected folder on your
report server. You can also deploy individual reports by right-clicking on the
file in the Solution explorer and selecting Deploy.
Once your report has been published,
you can access and run it on your server through the browser at http://<servername>/<reportservername>.
From the Home page, you should be able to find the folder you published
to, with the reports in it. Select a report to run. At the top of the page you
can enter any values for report parameters, and then run the report. From here,
you can also print or export the report.
Wrap
up
That's everything you need, to build
a very basic report. In the next articles we'll get into adding some more
advanced options such as drill-downs, sorting and custom functions. Stay tuned.
Steve Joubert continues this
introductory article in Beginning SQL Server 2005 Reporting Services Part 2.
If you enjoyed this article, make sure you see Ten Common SQL Server Reporting Services Challenges and
Solutions and other Reporting Services articles in our Reporting Services section.
Source:
https://www.simple-talk.com/sql/reporting-services/beginning-sql-server-2005-reporting-services-part-1/
No comments:
Post a Comment