What a long, strange trip it’s been. … SQL Server Reporting Services is all grown up now. This product has matured quite... more

What a long, strange trip it’s been. … SQL Server Reporting Services is all grown up now. This product has matured quite a lot over the past five years or so since enjoying a favorable start in the industry. This is our third edition of this book, about a product in its third version. We’ve seen it grow from what was essentially a free download for SQL Server 2000, to a substantial but relatively untested component of SQL Server 2005, to a serious force in the industry—and a very capable, enterprise-ready reporting tool.

Since we started writing about Reporting Services for the first edition of this book in 2003, there is much more to say about this product and the rest of the integrated Microsoft SQL Server Business Intelligence platform. There are stories to tell about IT projects, training classes, and consulting engagements. Along the way, we’ve learned quite a lot from other members of the IT community about the many creative ways to use Reporting Services. We’ll tell some of those stories and discuss our experience with the past three generations of this product. But for now, let’s focus our attention on the fundamental applications and capabilities. In other words, What can you do with Reporting Services? Who should use it, and for what purpose?

The topics introduced in this short chapter are explored in greater detail in the next chapter and throughout this book. The purpose of this chapter is to provide a high-level introduction only to the concepts and capabilities of this powerful reporting tool and the data analysis platform of Microsoft SQL Server 2008. This chapter introduces common reporting scenarios, beginning with the most basic and then moving to the more advanced. In subsequent chapters, you will explore these capabilities in depth and learn to use them in your own reporting solutions.

... less

This chapter is less about Reporting Services and more about reporting and analyzing data in general. By understanding the... more

This chapter is less about Reporting Services and more about reporting and analyzing data in general. By understanding the state of data analytics in the industry and characteristics of reporting requirements, you will have a better understanding of how Reporting Services fits into the bigger picture. A Business Intelligence (BI) solution is the foundation upon which a capable business reporting platform can be constructed. Depending on your needs and your business environment, this may simply entail designing a new database. Constructing a full-scale BI solution may also encompass investing in and learning to use new database tools and technologies.

Somewhere between 1999 and 2005, the industry began to go through an important transition. Prior to this period, businesses ran reports to keep track of simple things like sales totals, invoices, inventory, and production runs. As an industry, we had reached a point where we were quite proficient at gathering and storing data. Most businesses have gigabytes and terabytes of data to report on. What we (as an industry) were less proficient in was transforming that data back into useful and actionable information. Business has changed in recent years. Today, we compete on a global scale. Business must be efficient, competitive, and adaptable. Large corporations merge, acquire, outsource, downsize, and realign their strategies more often than ever before. Today’s business leaders must be adaptable and prepared to react to industry trends and opportunities in order to thrive.

As a result of this demanding environment, yesterday’s static reporting applications are giving way to BI solutions. True, BI is more than the ability to “go get” data. It involves mechanisms that put high-level intelligence in front of leaders in the form of ad hoc report tools, dashboards, and scorecards. It proactively alerts users when important events occur and when thresholds are exceeded. A dynamic BI solution integrates with business forecasting and planning processes so that leaders can investigate the cause and effect of activities and their related metrics.

... less

To gain familiarity with Reporting Services, developers and administrators often perform a basic installation to a personal... more

To gain familiarity with Reporting Services, developers and administrators often perform a basic installation to a personal computer or development server. Although the basic installation glosses over many of the choices critical in an enterprise deployment, it provides an environment in which features and the installation process itself can be explored. Such an environment is ideal for performing the exercises and tutorials found in Books Online and within this book.

In this chapter, you will be guided through a basic installation of SQL Server 2008 Reporting Services. Then you will review some important consideration for an enterprise deployment.

... less

In this chapter, you will explore how features in Reporting Services are implemented and exposed. This information is foundational... more

In this chapter, you will explore how features in Reporting Services are implemented and exposed. This information is foundational for both administrators and developers. Subsequent chapters in this book build off concepts explored here.

You will start with a look at the reporting life cycle. This provides you the context within which Reporting Services is employed. You will then explore the various applications and utilities associated with Reporting Services.

Following this, you will dig a little deeper into Reporting Services itself by examining the architecture of the Reporting Services Windows service, its components and supporting databases. By the end of the chapter, you will have a solid understanding of how all these pieces come together to deliver Reporting Services’ functionality.

This chapter covers:

• The reporting life cycle

• Reporting Services tools

• Reporting Services Windows service

• Reporting Services processors and extensions

• Reporting Services application databases

... less

If you are new to Reporting Services, you’ll get started in this chapter with some basic report design concepts. If you have... more

If you are new to Reporting Services, you’ll get started in this chapter with some basic report design concepts. If you have had prior experience with earlier versions of Reporting Services, you may be able to skip ahead after we introduce a few things that have recently changed. In order to meet the needs of those readers who are new to the product and also those who have done report design with SQL Server 2000 or 2005, we have organized this section on report design to make it easy for you to learn what you need without having to read each of these chapters from start to finish. Using this approach, you also shouldn’t have to learn about all the low-level details if you simply want to know the basic steps. But you also shouldn’t have to read through an elementary introduction of the topic if you are ready to take on advanced report design.

... less

You have numerous options for presenting information in a report. One of the most important factors in report design is to... more

You have numerous options for presenting information in a report. One of the most important factors in report design is to understand these options and to provide an appropriate report layout to meet the needs of your users and their business requirements.

This chapter will introduce the features of report layout and formatting in the following areas. For most of these features, I will provide brief instructions to implement that feature and show some examples:

• Basic report layout types, including the table, matrix, list, and chart reports

• Page layout options for tabular, matrix, list, chart, dashboard, and composite reports

• Report navigation features

• Formatting properties for visually enhancing various reports

• Pagination control

Over the years in some industries, we have been presenting data the same way for a long time. I think this is the case for a variety of reasons. The primary reason is that many of us started out using restrictive tools that only provided limited options. Another reason is that the business community has become accustomed to doing things the same way for a long time, even if there might be a better way. I’ve become a firm believer in getting the requirements at the beginning of a project. This way, we know up front what kind of reports we are designing, and what a report should and shouldn’t do. This chapter is about report design options and the elements you will use in later report design.

I like to shake things up sometimes, and I think change can be a healthy thing in business. But we also need to maintain some consistency. For some of your users, the reports you create will be their lifeline to important business information. The manner in which you present data may affect business decisions and the way people go about doing their jobs. When I start a report project or a new set of reports, I try to carefully consider these factors and take the time to show users and business leaders a selection of report layout options and then discuss the pros and cons of each option, to decide which are most appropriate and valuable to the people who will be using them.

Your challenge as a report designer is to find the best way to present information to business users so that it’s logical, makes sense, and is appealing and readable. The right format for your business users may be different for someone in a different industry, culture, or discipline.

I learned an important lesson a few years ago when I was asked to design a set of reports for a large, commercial airplane manufacturer. The users were all structural and aerospace engineers, and they had been using the same, static, mono-spaced, spreadsheet-like reports for ages. I decided to add some flair to the new reports with charts and graphics. I made them colorful and attractive. I made a point to use different font sizes and weights. I added background shading and borders. Proud of the updated design, I created a standard report template with the company colors and logo in the report header, as I had for other clients in the past. When the users saw the first report, they immediately shot them down and complained about the “fluff” and “pretty pictures.” In their rigid, engineering world, data is a serious matter and shouldn’t be dressed up and decorated. At the request of our project sponsor, I took out the graphics and embellishments and changed all the text to one size of Courier New. They were elated with the design.

... less

Chapter 6 used the new Report Builder 2.0 to design some simple reports. As of the initial release of SQL Server 2008, Report... more

Chapter 6 used the new Report Builder 2.0 to design some simple reports. As of the initial release of SQL Server 2008, Report Builder 2.0 doesn’t include the Graphical Query Designer and Report Wizard tools; these features are due to be added in a service pack or subsequent product release. To demonstrate the full report design experience, this chapter uses Business Intelligence Development Studio (BIDS). The differences between the two report designers are minor enough that it really shouldn’t make a difference, and you should be able to use either.

A big part of the report design process is often query design. In nearly all cases, your reports are based on a data source of some kind. Therefore, the first order of business when designing a report is to create a connection and define the queries necessary to retrieve the report data. This chapter discusses the essential first steps of report design—how to consume data. Although this is typically simple and straightforward, there are several options to be considered when designing data sources and queries. Although SQL Server Reporting Services is packaged with the SQL Server database product, it may be used with other database products as data sources. This chapter discusses the following topics:

• Creating stand-alone and shared data sources

• Designing queries and data sets

• Grouping and filtering data in a T-SQL query

• Using parameters to filter data at the database

• Using parameters to filter data at the Report Server

• Obtaining data from other data sources

Every report will have at least one data source (with the rare exception of a special-purpose report that doesn’t use any data). The simplest of reports will have a single data source to provide data for a single data set. The data source defines a connection as a string of text stored either in the report definition file or in a separate shared data source file that can be shared among several reports. This connection information may include security credentials. The data set defines a query expression or a reference to query objects stored in the database. The data set is also contained within the report definition. Figure 7-1 depicts how data flows to the report. The data source provides the ability to connect to the database, and the data set contains a query expression that populates the report with data.

More complex reports may require multiple data sets to provide data for different data ranges or items in the report or to feed values to parameter value selection lists. Data sets can be based on query expressions from the same data source, as shown in Figure 7-2:

Multiple data sets can get their data from multiple data sources. This model would enable a report to have parameter selection values to be obtained from a local database and report data to be obtained from a central data store. In some cases, data regions, subreports, and various report items might obtain data from multiple sources through associated data sets, as shown in Figure 7-3.

As you can see, almost anything is possible in terms of combining data sources and data sets. Data sources can be practically any database product or any data source you can query by means of standard connection libraries or drivers. Reporting Services consumes data using the .NET data providers, which include support for SQL Server, Oracle, and all OLE DB providers. These include almost any database product that supports ODBC access or a capable ISAM driver. Data sets in Reporting Services are always Read Only, so there is no need to specify cursor types or locking options.

... less

In Chapter 5, you learned about basic report design components and building blocks for simple reports. Chapter 6 showed you... more

In Chapter 5, you learned about basic report design components and building blocks for simple reports. Chapter 6 showed you how to lay out a report using these report items and data regions. In this chapter, you will learn how to use these same essential components to assemble more complex and useful reports. You can follow along using the sample reports contained in the Chapter 8 project that is included with the book downloads at Wrox.com.

The real power behind Reporting Services is its ability to creatively use data groups and combinations of report items. Calculations and conditional formatting may be added by using simple programming code. Whether you are an application developer or a report designer, this chapter contains important information to help you design reports to meet your users’ requirements, and to raise the bar with compelling report features.

The following topics are covered in this chapter:

• Advanced data grouping features

• Headers and aggregation

• Lists and data regions

• Links and drill-through reports

• Building advanced expressions

• Using custom code to extend formatting and apply business logic

• Advanced charting features

... less

SQL Server 2008 Analysis Services is used to store and aggregate data, specifically to support decision-support systems,... more

SQL Server 2008 Analysis Services is used to store and aggregate data, specifically to support decision-support systems, ad hoc reporting, and business data analysis. Once designed, cube data is easy to navigate to produce complex, business-relevant results for business leaders and information workers.

This chapter will introduce some of the basic concepts of OLAP and multidimensional storage systems. You will use the Report Designer to create Multidimensional Expressions (MDX) language queries, with and without the MDX Graphical Query Builder. You will learn to build advanced and compelling reports using parameters, pivot tables, and KPI indicators in a table or matrix report.

Finally, you will learn to use cube actions and apply best practices and safety checks to your report solutions that use OLAP data stores.

... less

This chapter serves as a practical guide to designing reports and building reporting solutions in the real world. It contains... more

This chapter serves as a practical guide to designing reports and building reporting solutions in the real world. It contains a few examples of advanced and creative report designs as recipes to solve specific business problems. This is a high-level guide and not step-by-step instructions. You will use the techniques you’ve learned in the previous chapters to implement specific functionality. Specifically, this chapter covers the following topics:

• Reporting project guidelines, key success factors, and the solution scope

• Defining and managing report specifications and the development process phases

• Migrating and converting reports from other reporting tools

• Working with the strengths and limitations of the Reporting Services architecture

• Recipes and models for several advanced reporting features and techniques

In the previous chapters, you’ve learned what you can do with Reporting Services, and you have been given several options to implement various report functionality. The last edition of this book provided a chapter that offered practical guidance for designing reports based on real-world experience. This chapter takes a different approach to introducing report development patterns by focusing not on what you can do but what you should do. Over the past three years, I have spent the majority of my professional time building reporting solutions for consulting clients. Collectively, we’ve developed reporting solutions for a very large software producer, one of the world’s largest media and entertainment companies, a global aerospace manufacturer, an international investment bank, utility companies, retail services, food services, telecommunications providers, and government agencies. I’ve made it a point to build the content for this chapter over time while working on different projects. These and other projects have afforded us challenging opportunities to discover effective patterns for designing a variety of report styles.

We have also had the opportunity to work closely with members of the Reporting Services product team at Microsoft to better understand the long-term goals for Reporting Services’ features and capabilities. This has provided insight into the mechanics of the product’s components and why they behave as they do. Without fully understanding the design goals in constructing the architecture of this product, it’s easy for a report designer to ask questions like, Why does it work that way? . . . Why did that do that? Reporting Services has some limitations that may not make sense to the casual user. I’ve found that most advanced capabilities that I would like to include in reports can be implemented, but not necessarily using my chosen technique. As I’ve run up against limitations and have discussed these with the product architects and product managers, the answers are often in the vein of: “That feature wasn’t designed to work that way. You can accomplish the same thing by using this other feature or technique.” My goal is to share these techniques and capabilities with you.

Unlike the previous chapters on report design, I’m not going to do much hand-holding in this chapter. By now, you should know how to use the features of the Report Designer and how to change properties, create queries, and use all of the report items. For each of the report design techniques that follow, I’ll give you enough information to explain the concept and demonstrate the technique, but I won’t walk you through the entire process from start to finish. This will save time and avoid redundancy with material covered in the previous chapters.

... less

A report model is a predefined way to access data that has already been set up by an experienced report designer. The model... more

A report model is a predefined way to access data that has already been set up by an experienced report designer. The model provides end-users with all the data they will need to build the reports that interest them. Without the report model, end-users would have to track down each piece of data in the database system, likely with the help of a Database Administrator (DBA). The correct data is often in disparate tables throughout the database system. The model allows for these end-users to then use this model data and perform ad hoc queries against it. A report model can be built against a SQL Server database, a SQL Server 2005 or later Analysis Services cube, or an Oracle database running version 9.2.0.3 or later. To better understand how report models are built and which features they include, you will do a simple walk-through using the AdventureWorksDW2008 database.

This chapter covers:

• Creating Reporting Services report models

• Working with report model data sources

• Creating report model data source views

• Setting report model properties

• Deploying report models

• Creating report models for Analysis Services

... less

This chapter looks at using the traditional Report Builder application to perform ad hoc reporting. The traditional Report... more

This chapter looks at using the traditional Report Builder application to perform ad hoc reporting. The traditional Report Builder application discussed in this chapter has not changed since SQL Server 2005 Reporting Services and is the recommended tool for users who want to continue benefitting from the query design experience as well as the infinite drill capability. As of this writing, Microsoft is working hard on a new version of Report Builder—Report Builder 2.0. Microsoft’s plans for the new version of Report Builder are discussed below in this chapter.

In March 2004, Microsoft purchased a company called ActiveViews. ActiveViews had a technology that allowed users to build a user-friendly model on top of their data. This model has become the backbone of ad hoc reporting in Reporting Services.

As you move through this chapter, you will be introduced to the Report Builder application. Report Builder has a traditional Microsoft Office interface for building reports. You will also see how to use different report layouts to fulfill various reporting needs. Once you understand the report layouts, you will move on to formatting and filtering data. The chapter ends with a few administrative items you need to be aware of when deploying this tool to your users.

... less

As discussed in Chapter 4, reports are made available through a three-phased process of authoring, management, and delivery... more

As discussed in Chapter 4, reports are made available through a three-phased process of authoring, management, and delivery. This is referred to as the reporting life cycle.

Much of the material in the preceding chapters focused on the authoring phase of the life cycle. This chapter marks the book’s transition in focus to the management and delivery phases. The goal of this and many of the subsequent chapters is to show you how to effectively put content you have spent hours, days, or even weeks developing into the hands of your users. All readers, including those primarily focused on report authoring, are encouraged to understand this material.

In this chapter, you explore the management of Reporting Services content. Reporting Services content includes reports, report models, shared data sources, and report resources, as well as the folder structure within which these are maintained. Shared schedules, used by reports for subscriptions, history, and snapshots, are also addressed in this chapter, although these items are maintained at the site level, outside the folder structure.

In Native mode, Reporting Services content management is performed primarily through the Report Manager application. Scripts executed through the RS utility provide an alternative means of performing these tasks.

In SharePoint Integrated mode, content-management activities are performed in a similar manner but through the SharePoint site or through the ReportServer2006 web services endpoint. In this mode, Report Manager and the RS utility are not available.

This chapter focuses on content management in Native mode installations. If you are running in SharePoint Integrated mode, it is important that you understand the concepts explored here and then review the SharePoint-specific aspects addressed in Chapter 16.

This chapter covers:

• Using Report Manager

• Content-management activities

• Item-level security

• Automating content management

... less

To ensure the integrity and reliability of your Reporting Services environment, it is important that you develop a comprehensive... more

To ensure the integrity and reliability of your Reporting Services environment, it is important that you develop a comprehensive administrative plan for it. This plan should address the following general concerns:

• Security

• Backup and recovery

• Monitoring

• Configuration

In this chapter, you will explore these topics as they relate to Reporting Services. This will provide you the basic knowledge you will need to then engage users, developers, and IT administrators in the development of a plan tailored to the specific needs of your organization.

... less

Reporting Services was designed to be a flexible reporting technology that can be easily integrated into a variety of scenarios... more

Reporting Services was designed to be a flexible reporting technology that can be easily integrated into a variety of scenarios. Many reporting needs will never expand beyond the out-of-the-box functionality provided by Reporting Services. However, if the requirement arises, Reporting Services includes endless opportunities for integration with custom-built applications. The next chapter will explore integrating Reporting Services into a SharePoint environment. However, there are also organizations that maintain a custom corporate reporting portal. In these situations, developers might need a way to display numerous reports in a Web environment. Reporting Services can also be embedded into any of the lines of business applications. Developers might want to use Reporting Services to create invoices or purchase orders directly from their applications. Some organizations may decide that the default Report Manager is not robust enough for their needs. In this situation, a custom reporting management application can be built that completely replaces and expands on the functionality of the out-of-the-box Report Manager.

All these issues can be solved with the features available in Reporting Services. In this chapter, you will take a look at the following three methods of rendering reports from Reporting Services:

• Using URLs to access reports

• Using the Reporting Services Web service to programmatically render reports

• Using the MicrosoftReportViewer controls to embed reports

• URL access allows you to quickly incorporate Reporting Services reports in applications such as web portals. Programmatic rendering allows for creating custom interfaces. Developers can do anything from implementing their own security architecture around Reporting Services to creating their own parameter interface.

• In this chapter, you learn about:

• The syntax and structure for accessing Reporting Services through the URL

• The reporting items that can be accessed through the URL

• The parameter options that can be passed to the URL to control report output

• Creating a Windows application that renders reports to the filesystem

• Creating a web application that returns rendered reports to the browser

• Easily embedding reports in a Windows application using controls

... less

This chapter explores the integration of SQL Server 2008 Reporting Services with the SharePoint technologies. In recent years... more

This chapter explores the integration of SQL Server 2008 Reporting Services with the SharePoint technologies. In recent years, SharePoint has become a web portal centerpiece for collaboration and information sharing. As a result, Microsoft has tightly integrated their reporting solution with the SharePoint technologies.

Integration of SQL Server 2008 Reporting Services and SharePoint allows for a user to navigate to their intranet portal and have instant access to company information as well as personalized business reports and key performance indicators (KPIs). The reports can be embedded directly into web portal pages for seamless integration for the user.

SQL Server 2008 Reporting Services can be installed in either Native mode or SharePoint Integrated mode. In Native mode, a user would interact with Reporting Services using two web parts (Report Explorer and Report Viewer). In Integrated mode, SharePoint takes over all the duties of the Report Manager as well as adds SharePoint document management values such as a consistent and user-friendly experience, versioning, security trimming, alerts, enterprise search, and, when properly configured, the meeting of regulatory compliance requirements, to just name a few.

This chapter covers:

• A brief overview of the SharePoint technologies, including Windows SharePoint Services, Microsoft Office SharePoint Server, and SharePoint web parts

• SharePoint integration with SQL Server Reporting Services in Native mode

• SharePoint integration with SQL Server Reporting Services in Integrated mode

• SharePoint integration architecture

• A comparison between Native and Integrated mode

... less

As you learned in Chapter 2, Reporting Services is a robust and scalable product for enterprise report processing. In addition... more

As you learned in Chapter 2, Reporting Services is a robust and scalable product for enterprise report processing. In addition, Microsoft has created Reporting Services using a modular extensible architecture that gives users the ability to customize, extend, and expand the product to support their enterprise business intelligence (BI) reporting needs. This chapter introduces you to most of the areas within Reporting Services that allow customization and some of the reasons that you may wish to extend the product. The basic requirements for implementing each type of extension are discussed, followed by a detailed example of creating and deploying a data processing extension.

In this chapter, you will learn about the extensibility of Reporting Services and the areas that currently support customization. These include:

• Extensibility options

• Reasons for extending SQL Server Reporting Services

• How to create custom extensions

• How to install custom extensions

Reporting Services currently supports extending its behavior in the following areas:

• Data Processing Extensions (DPEs)—Custom DPEs enable you to access any type of data using a consistent programming model. This option is for you if you cannot access your data using one of the currently supported providers (Analysis Services, Hyperion Essbase, ODBC, OLE DB, Oracle, Report Model, SAP BI NetWeaver, SQL Server, and XML). Microsoft has also released a Feature Pack for SQL Server that provides customized extensions, such as SAP Relational DB and DB2, in addition to the ones built into the product.

• Delivery Extensions—In Chapter 13, “Content Management,” we discussed “subscribing to a report.” During this process, one of the required options is the method of delivery. Do you want the report sent to your cell phone in image format, or perhaps delivered to a file share for your perusal at a later date? The ability to extend SSRS with delivery extensions allows you to choose.

Delivery extensions allow you to deliver reports to users or groups of users according to a schedule. E-mail, network file shares, and SharePoint content are the delivery mechanisms currently built into the product. Creating a delivery extension is really a two-part process. You must create the extension itself, as well as a UI tool to manage the extension if you want it to be usable from the SSRS Report Manager. The difficulty in creating a delivery extension is primarily a function of the delivery mechanism.

• Rendering Extensions—Rendering extensions control the type of document/media that gets created when a report is processed. Theoretically, you could have Reporting Services create any type of media given the ability to extend the product in this area. Microsoft provides the following rendering extensions out of the box:

• HTML—The HTML extension will generate HTML 3.2 for use with older browsers and HTML 4.0 for browsers that support the dynamic HTML standard.

• MHTML (Web Archive)—MHTML is another HTML standard that was created to allow disconnected viewing of HTML documents. All the images in the page are encoded into the document, which increases its size but allows it to be viewed both online and offline.

• Excel—The Excel extension creates Excel-specific MHTML.

• Image—The Image extension allows you to export reports as images in the EMF, GIF, JPEG, PNG, TIFF, and WMF formats.

• PDF—This extension allows the generation of reports in the PDF format.

• CSV—Comma Separated Values emit the data fields separated by commas. The first row of the CSV results contains the Field names for the data.

• Security Extensions—In its first release, Reporting Services only supported Integrated Windows Security for report access. This was a pretty big problem for some enterprise players. Most companies have heterogeneous networks with multiple operating systems and products. In a perfect world, all our networks, applications, and resources would support some form of “single sign-on,” or at least would allow us to build this ourselves. If Microsoft wanted SQL Server to be a key part of an Enterprise Business Intelligence platform, it had to play nice with others. Microsoft fixed this problem in service pack 1 for SQL Server 2000 and made it a part of the RTM version in 2005. The release contained fully documented security extension interfaces and an example using ASP.NET Forms–based authentication. You may now implement your custom security model using SSRS.

• Report Processing Extensions (Custom Report Items)—This extension type came with the 2005 release of Reporting Services, and it allowed us to create custom report items that were processed by the report processing engine. This enables us to extend the RDL standard in order to include functionality not natively supported by the RDL, such as custom maps, horizontal lists, and re-pivotable matrices. Developers can also extend current report items to provide alternative versions that better fit their needs.

• Report definition customization extensions—This is the latest addition to the list of available extension options supported in the 2008 release. This extension type provides a hook into the pre-processing of the report definition, and enables you to plug in custom code that can modify the report definition stream before it gets processed. This is handy, for example, if you need to modify the layout of the report based on a culture, locale, or user identity that is specified with the report request. Note that you are not guaranteed where or when in the request pipeline the customization will occur, but you are guaranteed that it will always happen before the processing of the report definition takes place. For this extension, a new interface was included and is required to be implemented: IReportDefinitionCustomizationExtension.

... less

The Report Definition Language (RDL) is a schema-defined XML specification for how a report file should be structured. In... more

The Report Definition Language (RDL) is a schema-defined XML specification for how a report file should be structured. In order for Reporting Services to interact with the structure of a report, it needs to understand the RDL schema so that it knows which elements represent which pieces of functionality within the report. Although a simple parsing of the XML document, using the XML Document Object Model (DOM) and an XML querying language such as XPath, would technically enable you to extract this information, it would make for very lengthy and cumbersome code to maintain.

Instead, Reporting Services provides a representation of the RDL schema in an object-oriented fashion. What that means is that the RDL schema in Reporting Services was modeled using objects and properties, all available from a public library, which can be used to examine and manipulate the RDL document. This piece of functionality is called the RDL Object Model.

In previous versions of Reporting Services, the object model was not released as a public library and was only available internally to Reporting Services. This meant that a developer had to generate his or her own custom object model based on the RDL schema provided.

You might be asking, “When would I need to use the RDL Object Model?” If you have requirements to generate RDL files on-the-fly or to change any properties of report items, programmatically, this is a great way to do so. It allows for a very flexible platform that could enable your application’s users to design simple reports and save them, to be later deployed into a Report Server.

The new object model library also provides methods to upgrade RDLs from previous versions to the current 2008 version, as well as from 2000 to 2005 versions.

Now that we’ve defined the RDL Object Model, let’s see it in action.

... less

SQL Server 2008 recognizes up to four parts of object names. Depending on the context of an expression, some parts may or... more

SQL Server 2008 recognizes up to four parts of object names. Depending on the context of an expression, some parts may or may not be necessary when referencing an object. When a script runs on a different server or when you are using a different database, related object names may be required. Note that both SQL Server 2005 and SQL Server 2008 recognize the schema name in the third position, whereas SQL Server 2000 and earlier versions recognized the object owner name in the third position. The following table summarizes valid syntax for referencing database objects:

... less

Variables and functions are often used interchangeably. SQL Server Books Online documents some variables as though they were... more

Variables and functions are often used interchangeably. SQL Server Books Online documents some variables as though they were functions. However, it’s important to note that variables are used in expressions to obtain a value, whereas functions process specific business logic and may return a value. Many functions accept input arguments.

This Appendix, specific for SQL Server 2008, is not meant to be a comprehensive reference, but to provide a convenient guide to many functions and variables. For complete details and samples of usage, consult Books Online.

... less

This Appendix provides information on those aspects of the SQL Server 2008 implementation of the Multidimensional Expressions... more

This Appendix provides information on those aspects of the SQL Server 2008 implementation of the Multidimensional Expressions (MDX) language relevant to Reporting Services authors. The material provided here is intended to provide a quick reference and not to be fully instructional. Nor is it intended to provide an overview of SQL Server Analysis Services. For a complete reference on these topics, please refer to Professional Microsoft SQL Server 2008 Analysis Services with MDX (Wrox).

... less