Sams Microsoft SQL Server 2008- P4

ptg
131
Generating Reports with Visual Studio
8
Design Screen
After selecting your data, the next step is to design the presentation for the data. Layout
assistance is provided by the Toolbox, Report Data, and Design dockable windows.
Design view is a default that BIDS displays after you add a report (see Figure 8.11).
The Toolbox (shown in Figure 8.11) is accessible by selecting Toolbox from the View
menu. This has all the report item controls you might use while authoring reports. The
simplest way to use them is to drag the control you want onto the body of a report.
Data can be inserted from the Report Data window. (Just choose Report Data from the
View menu.) The Report Data window contains a tree list of available fields to use from
the data sets. If you drag a field onto the report body, BIDS creates a text box to contain
the field.
Any item on the report can be modified through the Properties window. The Properties
window can be accessed by pressing F4 or by selecting Properties Window from the View
menu. Figure 8.11 shows the Properties window for a report object.
Categorized
Alphabetical
Property pages
Properties
window
Properties
toolbar
Toolbox
Report data Main menu
Design tab
Preview tab
Report body
Context help/tip for a property

Error List window
Report items Dataset fields
Output window
Report object
(page, code, etc.)
Toolbar Solution Explorer
FIGURE 8.11
Report Design view.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
132
CHAPTER 8 Report Designer(s)
At this point in the report development process, you need to take the results of your query
and apply a layout and format to them. Let’s make a simple tabular report and add a few
bells and whistles. Complete the following steps using the Sales by Territory by
Salesperson report:
1. Drag a text box from the Toolbox to the report body. In the Properties window (F4),
select the text box. (Most likely, the text box you just added is already selected.)
Enter
Sales by Territory by Salesperson
in the text box and change the follow-
ing property values to those specified here:
Name: ReportTitle
Location: Top = 0, Left = 0
Size: Height = .5in, Width = 4.5in
Color: DarkBlue
Font: FontFamily = Tahoma, FontSize = 18pt, FontWeight = Bold
2. Drag a table and place it on the report’s body under the report title that you have
just created. By default, the table comes with three columns, which are all 1-inch

wide. Click the bar above each column; if selected successfully, the entire column
should be selected. After a column is selected, you can use the Properties window
and change the Width property to fit the information you are going to display. You
can do this for each column individually or select columns you want to change to
the same size by pressing and holding Ctrl key and selecting multiple columns.
NOTE
In SSRS 2008, the Table report item is actually represented by a new Tablix data region.
Tablix represents both Table and Matrix report items. This is why some of the menu
items and dialog boxes use Tablix even though we work with the Table report item.
3. From the Report Data window, drag the AdventureWorkDataset fields
(CountryRegionName, TerritoryName, and FirstName) to the first three columns of
the table. Note that when you drag a field over a column the entire column is
selected. Report Designer will add a value of a field to a data row of the table and the
name of a field to the header of the table. When adding a field name to table’s
header, the Report Designer will also insert spaces before each capital letter in the
field’s name.
4. To add more columns to the table, you can select the rightmost column of the table,
right-click the column, and select Insert Column, Right (see Figure 8.12). Repeat
three times. The table should now have six columns.
5. Alternatively you can continue dragging fields from the data set to the table, posi-
tioning your cursor where you want the column to be added, similar to Figure 8.13
where we add a column to the end of the table. Note how the cursor changes to
indicate an addition to the table.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
133
Generating Reports with Visual Studio
8
FIGURE 8.12

Adding columns to a table.
6. Click the button next to the report header row. After the row is selected, use the
Properties window to set the following properties:
FIGURE 8.13
Adding columns to a table by dragging data fields.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
134
CHAPTER 8 Report Designer(s)
BackgroundColor: #1c3a70
Color: White
Font: FontFamily = Tahoma, FontSize = 11pt, FontWeight = Bold
7. Click the button at the upper-left corner of the table. When you do this, the entire
table should now be selected. The Properties window now should reflect the table’s
properties. You can modify table properties as you consider appropriate. For
example, you can change table’s
BorderStyle
property to
Solid
to display a border
around the table.
8. Click the Preview tab to see what the report looks like.
We should fix some formatting to make a report more visually appealing. You may
have noticed that country and territory names are not ordered, and Sales columns
are not formatted as currency.
9. Click the Design tab. Holding the Ctrl key, select cells that contain sales data. For
the format, enter
C
. (The single letter C is a formatting for currency.)

10. Click anywhere on the table, and then right-click the button at the upper-left corner
of the table.
11. Select Tablix Properties from the context menu.
12. Now display the Sorting tab.
13. Click the Add button three times to add three columns to sorting. Select the follow-
ing columns for sorting: CountryRegionName, TerritoryName, and LastName. Leave
the default sorting order A to Z (see Figure 8.14).
FIGURE 8.14
Adding columns for sorting.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
135
Summary
8
14. Click OK to complete the sorting assignment, and display the Preview tab to see
what the report looks like (see Figure 8.15).
This concludes the starter report. Preview mode has full report-viewing capabilities and
allows navigating multipage reports and exporting a report to a different format (such as
XML, Word, and Excel). Preview mode also has print capabilities (such as print preview
and page setup).
Summary
BIDS is nothing more than the shell of Visual Studio. Both products house the main
report development tool from Microsoft: SQL Server Report Designer. Over the next
several chapters, you will see how to use Report Designer to develop powerful and visually
appealing reports for all kinds of end users. You’ll learn more about client-side ad hoc
reporting in Chapter 18.
Find control: text
to find, find first,
find next

Zoom
Printing control: print,
print preview, page setup
Export report in
a different format
(such as XML)
Multipage report control: first,
previous, go to page, next, last
Browsing control:
back, cancel, refresh
Report Viewer toolbar
FIGURE 8.15
Completed report in Preview mode.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
This page intentionally left blank
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
CHAPTER
9
Report Definition
Language
IN THIS CHAPTER
. Language: A Way to
Communicate
. Use of XML
. Declarative Programming
. Report Elements

T
he preceding chapter introduced you to Report Designer
and Report Builder. This chapter takes a look at the output
from these tools.
SSRS is unique in that it uses Extensible Markup Language
(XML) to generate reports. This chapter provides an insight
into why Microsoft uses XML as their report-generation
language, and then delves into the structure of the result-
ing document.
Language: A Way to Communicate
At first glance, the name Report Definition Language (RDL)
might appear to be a misnomer. As you’ve already seen, it is
nothing more than an XML document, just like any other
XML document. Why would they call this a language? After
all, there is no compiler necessary, and the syntax is
nothing like C++, C#, or any other programming language.
To answer this, you need to think of things at a bit higher
level than most programming paradigms allow.
Remember, one of the goals of SSRS is to remain an open-
ended environment.
Likewise, as you have already seen, SSRS is composed of
many different components: There is the database server, the
Windows Service, the Report Server Web Service, and so on.
Most important, at least from an end-user perspective, are
the report designers and the rendering engine. As you
have seen, Microsoft already offers three designers: Report
Designer and Report Builder 1.0 and 2.0.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg

138
CHAPTER 9 Report Definition Language
All designers use the same rendering engine, and even within this engine there are multi-
ple formats. For all of this to work together seamlessly, all these components need to
communicate with the same underlying principles. This is where the common language
comes in to play; it is just a common way to communicate instructions between the
various entities.
Use of XML
Most enterprise reporting solutions use proprietary binary formats. This locks developers
into using that vendor’s tools to generate and deploy reports. Obviously, this runs counter
to the SSRS design goal of generating open standards. The other thing to note about SSRS
is the idea to keep report designers and generators separate. This poses the fundamental
challenge of what open format allows such disparate things to communicate. Thankfully,
the answer already existed: XML.
XML is already in use throughout the Web and even in many non-Web systems as a
communication mechanism. It easily allows anyone with a text editor to create an XML
file. XML is similar to Hypertext Markup Language (HTML) in that it is a form of markup
language. There are a few major differences.
With XML, a document has to be well formed, meaning every beginning markup tag
(called a node) has to have a corresponding ending tag. Second, HTML only has a few
keywords that can be used to mark up text. XML doesn’t have any such limitation
because the end user is the one responsible for the creation of tags. The tags are used to
describe the data encompassed by them. This is in stark contrast to HTML, which
describes how to handle presentation of data. This makes XML an ideal communication
medium or language.
The one drawback about such a flexible medium is, ironically enough, its flexibility.
Immediately, you might wonder the following: If any node can be in any place, and any
node can have any attribute, how can this be effective? There have to be some rules. To
solve this problem, you need to create an XML schema. An XML schema allows the
creation of a contract to adhere to between different systems by defining when and where

in the document a set of XML nodes should appear, and which nodes should have attrib-
utes describing them.
The RDL specification is the XML schema that describes the layout of the XML used to
create reports. The XML itself basically becomes the programming language of the report.
Declarative Programming
Just as a programming language lets a programmer tell a computer how and what to
produce to the end user, the RDL tells the Report Server what data to use and how to lay it
out. Now, there is a little trick here: Most programming languages communicate a what
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
139
Report Elements
9
and a how to do something. There is no way to tell ASP.NET to produce a web page just by
giving it a template. However, that is what the RDL does. The RDL communicates what
the output is to look like and where the source data is to come from. This leaves the appli-
cation free to decide how to generate the defined look and feel, regardless of the program-
ming language or underlying architecture. This model is called the declarative model.
A producer application is an application that is used to generate RDL files. Business
Intelligence Development Studio (BIDS) and Report Builder fall into this category. For
most users, it is helpful to have a graphical user interface (GUI), although you can develop
a report purely in your favorite text editor.
A consumer application is simply one that takes the RDL from the producer and creates
the desired output. In its simplest form, it queries for the data and displays the results in
the specified format. This is where a lot of the custom elements come in. Using the
custom elements, it is possible to send instructions for one output format, which could
then be ignored by all others.
Report Elements
To create a report, you need to know a few things:

. Where and what is your source data?
. What is the report layout?
. Are there any other properties, such as external images or parameters?
To cover this much information, the RDL schema has many elements. The RDL specifica-
tion (schema) itself is an open schema, and Microsoft fully expects third parties to add
onto it to extend it. In the scope of this book, it would be time-consuming and arduous to
cover every element, so this book covers just a few key elements. You can find more infor-
mation about the RDL schema on the Microsoft website at />sqlserver/reporting/2008/01/reportdefinition/ReportDefinition.xsd.
If you’d prefer to see the RDL’s elements in a graphical form, you can find it in the Books
Online or in its web version at or
by simply searching for “Report Definition XML Diagrams” at .
You can also view the XML of any report by opening the report in BIDS and selecting the
Code from the View menu while in Design view. Alternatively, you can view a report’s
XML by right-clicking the report in Solution Explorer and selecting View Code from a
drop-down menu.
Let’s examine several SSRS elements.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
140
CHAPTER 9 Report Definition Language
Report Element
The
Report
element is the highest-level element in the RDL’s XML hierarchy. The
Report
element contains all the information needed to process the report. There can be only one
Report
element in every report. In fact, every other element is a child node of the
Report

element. Examples of these child elements include
PageHeader
,
Body
,
PageFooter
,
DataSources
,
DataSets
, and
Parameters
.
The following code listing shows an example of the
Report
element. The RDL is of an
empty report with a
Line
report item:
<?xml version=”1.0” encoding=”utf-8”?>
<Report xmlns:rd=” />xmlns=” /><Body>
<ReportItems>
<Line Name=”Line1”>
<Top>0.0175in</Top>
<Height>0.25in</Height>
<Width>1in</Width>
<Style>
<Border>
<Style>Solid</Style>
</Border>

</Style>
</Line>
</ReportItems>
<Height>2in</Height>
<Style />
</Body>
<Width>6.5in</Width>
<Page>
<Style />
</Page>
<rd:ReportID>a045101c-aa05-4334-940f-b728efb81635</rd:ReportID>
<rd:ReportUnitType>Inch</rd:ReportUnitType>
</Report>
ReportParameters Element
For the
ReportParameters
element, there are following entries in the RDL schema:
...
<xsd:element name=”Report”>
<xsd:complexType>
<xsd:choice minOccurs=”1” maxOccurs=”unbounded”>
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
141
Report Elements
9
...
<xsd:element name=”ReportParameters” type=”ReportParametersType” minOc-
curs=”0” />

...
<xsd:complexType name=”ReportParameterType”>
<xsd:choice minOccurs=”1” maxOccurs=”unbounded”>
<xsd:element name=”DataType”>
<xsd:simpleType>
<xsd:restriction base=”xsd:string”>
<xsd:enumeration value=”Boolean” />
<xsd:enumeration value=”DateTime” />
<xsd:enumeration value=”Integer” />
<xsd:enumeration value=”Float” />
<xsd:enumeration value=”String” />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name=”Nullable” type=”xsd:boolean” minOccurs=”0” />
<xsd:element name=”DefaultValue” type=”DefaultValueType” minOccurs=”0” />
<xsd:element name=”AllowBlank” type=”xsd:boolean” minOccurs=”0” />
<xsd:element name=”Prompt” type=”StringLocIDType” minOccurs=”0” />
<xsd:element name=”ValidValues” type=”ValidValuesType” minOccurs=”0” />
<xsd:element name=”Hidden” type=”xsd:boolean” minOccurs=”0” />
<xsd:element name=”MultiValue” type=”xsd:boolean” minOccurs=”0” />
<xsd:element name=”UsedInQuery” minOccurs=”0”>
<xsd:simpleType>
<xsd:restriction base=”xsd:string”>
<xsd:enumeration value=”False” />
<xsd:enumeration value=”True” />
<xsd:enumeration value=”Auto” />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>

<xsd:any namespace=”##other” processContents=”skip” />
</xsd:choice>
<xsd:attribute name=”Name” type=”xsd:normalizedString” use=”required” />
<xsd:anyAttribute namespace=”##other” processContents=”skip” />
</xsd:complexType>
You may notice that
ReportParameters
is a child of
Report
and is of a
ComplexType
called
ReportParametersType
. A complex element has child elements and, optionally, attributes,
whereas a simple element does not have children or attributes. By this definition, the
Report
element itself is a complex type, and a
DataType
is a simple type that can be only
one of the following values:
Boolean
,
DateTime
,
Integer
,
Float
, or
String
.

Graphical report designers, such as Report Designer in BIDS, map elements to some graph-
ical presentation. Figure 9.1 presents the General tab of the Report Parameter Properties
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
142
CHAPTER 9 Report Definition Language
FIGURE 9.1
Report Parameter Properties dialog box.
dialog box. Here you can clearly see a mapping between
ReportParametersType
and
graphical elements:
Name
,
Prompt
,
Data Type
, and so on.
Armed with an understanding of the RDL, you can write your own graphical report
designers if you so choose. SQL Server Books Online have an example of such a generator
under the title “Tutorial: Generating RDL Using the .NET Framework,” which is also avail-
able online at The RDL genera-
tor in the example simply uses .NET’s
System.Xml.XmlTextWriter
class to stream RDL
elements to a file.
In limited scenarios, an understanding of the RDL would also help you edit RDL files
manually. In general, we recommend minimizing manual RDL editing because text editors
(such as Notepad) do not check the resulting changes against the RDL’s schema, and if

your changes are incorrect, the SSRS will return errors. However, in a few cases, you might
be pressed to manually edit RDL. For example, you are troubleshooting a report that
worked perfectly in a test environment and now fails in production. You have less than an
hour to fix the report because it contains the company’s quarterly financials and the
submission deadline is coming up. You realize that the production database is case sensi-
tive and that you can quickly solve the problem by manually editing a query in report’s
RDL using Notepad. In a perfect world, this would never happen; in reality, it might.
We present child elements of
ReportParametersType
and their description in the Table 9.1.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
143
Report Elements
9
TABLE 9.1
Report Parameters
Element Name Required or
Optional
Type Description
Name
Required
String
Unique name of the parameter. (The value of
this element is used when other expressions
need to refer back to this parameter.) Note:
Parameter names must be unique within the
ReportParameters
parent element.

DataType
Required
Enumeration
Programmatic data type of the parameter.
Because it is a required value, there is no
default.
Boolean
|
DateTime
|
Integer
|
Float
|
String
.
Nullable
Optional
Boolean
Whether the value of the parameter can be
null. Defaults to
False
if excluded.
DefaultValue
Optional
Element
Value used for the parameter when not
supplied by the end user. If the
Prompt
element is omitted, the value is null.

DefaultValue
becomes required when there
is no
Prompt
element and when either
Nullable
is
False
or a
ValidValues
element exists that does not contain
Null
(an omitted value).
AllowBlank
Optional
Boolean
Whether an empty string is an acceptable
value for the parameter. The default value is
False
, and the element is ignored if the
DataType
is not
String
.
Hidden
Optional
Boolean
Determines whether a user should be
prompted to enter a parameter.
If this element is

False
, the user interface
will prompt a user to enter the parameter.
NOTE
Because all XML is character based, technically, any data type is a string. To be more
specific about a range of possible string values, this book generally uses acceptable
type names (Type column in the Table 9.1). For example,
Boolean
indicates that the
string value could be
True
or
False
.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
144
CHAPTER 9 Report Definition Language
DataSets Element
The
DataSets
element is a collection of individual
DataSet
elements (see Table 9.2). As a
whole, the collection contains information about how to get the data used in the reports.
Each individual
DataSet
element has to have a unique name element. The
DataSet

element itself contains elements for basic properties, such as
AccentSensitivity
,
CaseSensitivity
,
Collation
, and so on.
TABLE 9.1
Continued
Element Name Required or
Optional
Type Description
MultiValue
Optional
Boolean
Determines whether a parameter can have
more than one value at runtime.
UsedInQuery
Optional
String
enumeration =
{
True
,
False
,
Auto
}
Default =
Auto

. If a
ParameterA
is included
in an expression or a query for a
ParameterB
, this element determines how to
handle a refresh of a default value for
ParameterB
when
ParameterA
changes.
Auto
relies on SSRS to determine whether a
dependency exists.
ValidValues
Optional
String
Helps to improve security when you define a
parameter of type
String
. If you do not use
this option, your report may be vulnerable to
a SQL injection attack.
Prompt
Optional
String
The
Prompt
element designates the text that
the user interface should display when

prompting the user for parameter values. If
the element is omitted, the user will not be
prompted for a parameter’s value, and the
parameter cannot be modified any other way.
For example, it can’t be modified through URL
access.
The Report Designer does not allow this
element to be blank. If you edit RDL manually
and set this element to blank (or remove this
element), the effect is similar to setting the
Hidden
element to
True
.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
145
Report Elements
9
The actual database query is contained in the
Query
element. Each data set can have only
one query. When using the
Query
element, you can see some of the influences of the .NET
Framework, particularly ADO.NET. The child elements are
CommandText
,
CommandType

,
DataSourceName
,
QueryParameters
, and
Timeout
.
The
Fields
collection contains
Field
elements. In an online transaction processing
(OLTP) system, the
Fields
collection usually maps to the columns returned by your data-
base query. There is also the ability to add calculated fields. The field name is the name
referenced in the layout sections of the report. The
Field
element must have either a
DataField
child element or a
Value
child element, but not both. As you might have
guessed, the
DataField
simply maps to a query column. A
Value
element should contain
TABLE 9.2
DataSet

Elements
Name Required,
Optional, or
Multiple
Type Description
Name
Required
String
Unique name given to the data set. This
cannot be the same name given to any data
region or grouping.
Fields
Optional
Element
List of fields that are included in the data set.
They may map to columns in the data set.
Field
Multiple: 1-N
Element
The field name is the name of the field as it
is referred to within the report.
Filters
Optional
Element,
Filters-
Type
List of filters. Each filter contains a
Filter
expression (such as
=Fields!ProductID.Value

), operator (such
as
Equal
), and a value of one of a data types
(such as
Integer
).
Interpret
Subtotals
AsDetails
Optional
String
Restricted to
True
,
False
, or
Auto
. Directs
whether to interpret results of a query that
returns subtotals as detail rows instead of
aggregate rows. Subtotals are interpreted as
detail rows when this element is set to
True
and the report does not use the
Aggregate()
function to access any fields in the data set.
Query
Required
Element

Information used to gather data from the data
source. This parameter includes connection
information, query text, query parameters, and
so on required to get the data from the data
source.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
146
CHAPTER 9 Report Definition Language
an expression used to calculate a field. In the designer, this shows up as a calculated value.
An example of the
Fields
collection follows:
<Fields>
<Field Name=”FirstName”>
<DataField>FirstName</DataField>
<rd:TypeName>System.String</rd:TypeName>
</Field>
<Field Name=”CountryRegionName”>
<DataField>CountryRegionName</DataField>
<rd:TypeName>System.String</rd:TypeName>
</Field>
</Fields>
In a lot of cases, a database query or stored procedure returns more information than most
readers would like or need. In this case, you can apply a filter to the data set through the
Filters
collection. Each individual
Filter
element contains a collection of

FilterExpression
,
Operator
, and
FilterValues
. Basically, for every row in the data set,
the report-processing engine is responsible for evaluating the expression against that row
and using the operator to compare it to the list of values. So, keep in mind that depending
on the expression, this can be time-consuming.
The following code listing displays an example of the
Query
and
Filter
elements:
<DataSets>
<DataSet Name=”AdventureWorks”>
<Fields>
<Field Name=”ProductID”>
<DataField>ProductID</DataField>
<rd:TypeName>System.Int32</rd:TypeName>
</Field>
<Field Name=”Name”>
<DataField>Name</DataField>
<rd:TypeName>System.String</rd:TypeName>
</Field>
</Fields>
<Query>
<DataSourceName>DataSource1</DataSourceName>
<CommandText> SELECT ProductID, Name
FROM Production.Product</CommandText>

<rd:UseGenericDesigner>true</rd:UseGenericDesigner>
</Query>
<Filters>
<Filter>
<FilterExpression>=Fields!ProductID.Value</FilterExpression>
<Operator>Equal</Operator>
<FilterValues>
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
147
Report Elements
9
<FilterValue DataType=”Integer”>866</FilterValue>
</FilterValues>
</Filter>
</Filters>
</DataSet>
</DataSets>
The schema definition element for a
DataSet
is in the following listing. To shorten the
listing, we have skipped several child elements for a
DataSet
that determine how a Report
Server sorts data:
AccentSensitivity
(when text is accent sensitive, the character
’a’
is

not equal to the character
’ã’
),
WidthSensitivity
(determines whether single-byte and
double-byte representation of the same character is identical), and
KanatypeSensitivity
(sensitivity to two types of Japanese characters).
...
<xsd:element name=”DataSets” type=”DataSetsType” minOccurs=”0” />
...
<xsd:complexType name=”DataSetsType”>
<xsd:sequence>
<xsd:element name=”DataSet” type=”DataSetType” maxOccurs=”unbounded” />
</xsd:sequence>
<xsd:anyAttribute namespace=”##other” processContents=”skip” />
</xsd:complexType>
...
<xsd:complexType name=”DataSetType”>
<xsd:choice minOccurs=”1” maxOccurs=”unbounded”>
<xsd:element name=”Fields” type=”FieldsType” minOccurs=”0” />
<xsd:element name=”Query” type=”QueryType” />
<xsd:element name=”CaseSensitivity” minOccurs=”0”>
<xsd:simpleType>
<xsd:restriction base=”xsd:string”>
<xsd:enumeration value=”True” />
<xsd:enumeration value=”False” />
<xsd:enumeration value=”Auto” />
</xsd:restriction>
</xsd:simpleType>

</xsd:element>
<xsd:element name=”Collation” type=”xsd:string” minOccurs=”0” />
...
<xsd:element name=”Filters” type=”FiltersType” minOccurs=”0” />
<xsd:element name=”InterpretSubtotalsAsDetails” minOccurs=”0”>
<xsd:simpleType>
<xsd:restriction base=”xsd:string”>
<xsd:enumeration value=”True” />
<xsd:enumeration value=”False” />
<xsd:enumeration value=”Auto” />
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
148
CHAPTER 9 Report Definition Language
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:any namespace=”##other” processContents=”skip” />
</xsd:choice>
<xsd:attribute name=”Name” type=”xsd:normalizedString” use=”required” />
ReportItems Element
ReportItems
define the contents of the report. They are under the
PageHeader
,
Body
, and
PageFooter
elements.

ReportItems
contain user interface elements, such as
Tablix
,
Image
,
Line
,
Subreport
, and
Rectangle
. Because SSRS allows you to nest controls, you can also
find report items within other report items. Each report item must contain at least one
child element.
Because many elements inherit from a report item, it is advantageous to be familiar with
the shared properties. These are mostly related to presentation.
Height
,
Width
,
ZIndex
,
Top
,
and
Left
are all used to size and position an item. Each report item can have its own style
section. The
Action
,

Visibility
, and
DrillThrough
elements all aid in reporting interac-
tivity. Generic RDL of a report item that contains some common elements is shown in the
following code listing.
{REPORT ITEM}
abbreviates any report item, such as
Textbox
,
Tablix
, and so on. Most common child elements of a report item are noted in the follow-
ing listing:
<ReportItems>
...
<{REPORT ITEM} Name=”...”>
<Style>...</Style>
<Top>...</Top>
<Left>...</Left>
<Height>...</Height>
<Width>...</Width>
<ZIndex>...</ZIndex>
<Visibility>...</Visibility>
<ToolTip>...</ToolTip>
<Bookmark>...</Bookmark>
<DocumentMapLabel>...</ DocumentMapLabel>
<RepeatWith>...</RepeatWith>
<CustomProperties>...</CustomProperties>
<ActionInfo>...</ActionInfo>
<ReportItems>...</ReportItems>

<DataElementName>...</DataElementName>
<PageBreakAtStart>...</PageBreakAtStart>
<PageBreakAtEnd>...</PageBreakAtEnd>
</{REPORT ITEM}>
...
</ReportItems>
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
149
Report Elements
9
Table 9.3 describes some common elements of a report item.
You can find additional information, including more discussion about RDL, in subse-
quent chapters.
TABLE 9.3
Common
ReportItems
Elements
Name Required or
Optional
Type Description
Name
Required
String
Unique name given to the report item.
Style
Optional
Element
The style information such as padding, color,

font, and so on for the element.
Action
Optional
Element
An action such as a bookmark link or a
drillthrough action that is associated with the
report item. This aids in making reports inter-
active.
Top
Optional
Size
Distance between the top of the report item
and the top of the containing object. If
excluded, the value becomes 0 inches.
Left
Optional
Size
Distance between the left of the report item
and the left of the containing object. If
excluded, the value becomes 0 inches.
Height
Optional
Size
The vertical size of the item. If omitted, the
value defaults to the height of the containing
object minus the
Top
value.
Width
Optional

Size
The lateral size of the item. If omitted, the
value defaults to the width of the containing
object minus the
Left
value.
PageBreakAtStart
Optional
Boolean
Instructs the Report Server to put a page
break before a report item.
PageBreakAtEnd
Optional
Boolean
Instructs the Report Server to put a page
break after a report item.
Visibility
Optional
Element
Specifies the initial visibility of an item and a
toggle trigger item for the visibility.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
ptg
150
CHAPTER 9 Report Definition Language
Data Regions
Data regions are the primary mechanism used to display data and a base class of controls
that generate repeating content based on data in a data set. Data regions include Tablix
(implements a table, list, and a matrix), Chart, and Gauge. Each data region is unique in

its own way and, therefore, has many of its own specialized elements and attributes.
Because all the data regions display data, all have the
<DataSetName>
tag. We provide more
information about the specifics of data regions later in this book.
Summary
This chapter covered why and how Microsoft chose to use XML in SSRS. This chapter also
covered the programming model that arose as a result, and explained some of the key
elements and their derivations.
The following chapters build on this information, some indirectly and some in a more
direct way. Report Builder and Report Designer are nothing more than fancy RDL genera-
tors. Therefore, this chapter provided a cursory look at what they generate. The following
chapters really do nothing more than show how to use them to build bigger and better
reports by generating more advanced RDL. Later chapters of this book provide more infor-
mation about RDL, specifically with regard to report items and data regions.
From the Library of STEPHEN EISEMAN
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.