Click here to monitor SSC
  • Av rating:
  • Total votes: 88
  • Total comments: 5
Robert Sheldon

Report Builder 3.0: Creating a Basic Report

24 August 2012

Report Builder is underrated as a BI and report-authoring tool. It is a free stand-alone application from Microsoft that provides an intuitive way for anybody to create  reports from data. It uses an interface that is similar to Microsoft Office, and supports the full capabilities of SQL Server 2012 Reporting Services.  Rob Sheldon starts a short course in how to use it.

Report Builder 3.0 is a report-authoring tool that’s part of the Reporting Services suite of tools available in SQL Server 2008 R2. However, Report Builder is a free, stand-alone application that can be used by SQL Server developers and business users alike to create reports rich in data visualizations. It provides an Office-like interface that makes it easy to connect to a variety of data sources—such as SQL Server, SQL Azure, Oracle, and SAP NetWeaver BI—and to display the data from those sources in tables, charts, lists, gauges, and maps.

In this article, you’ll learn how to use Report Builder to create a report that displays data from a SQL Server database. Keep in mind that this article is only the first in a series of articles about Report Builder. This one covers only what you need to know to build a basic report. As we progress through the series, you’ll learn how to use other Report Builder elements that let you create a variety of interesting and informative reports.

You can download Report Builder at the Microsoft Download Center. There you’ll find details about system requirements and additional information about the installation process. You can also download sample reports that you can open in Report Builder.

To try out the examples in this article, you’ll need Report Builder 3.0 installed on your system. You’ll also need access to a SQL Server instance with the AdventureWorks sample database installed. The database will provide the data you need to create your report based on the examples I demonstrate here. On my system, I used a local instance of SQL Server 2012 with the AdventureWorks2012 database installed. But you can use different versions of both SQL Server (2005 and on) and the AdventureWorks database.

The best way to learn Report Builder is to jump right in. In this article, I walk you through the steps necessary to connect to a data source, define a dataset, and present the data in a formatted table. The goal of the article is to provide you with the foundation you need so you can create other types of reports as you need them. Of course, I can’t show you everything in a single article, but I can give you the information you need to start working with Report Builder right away.

Getting Started with Report Builder

All it takes to use Report Builder is to have it installed on your system. Of course, to create a report, you’ll also need to have access to a data source, such as a SQL Server database. But everything else is available through the Report Builder interface, so to get started, your initial step is to launch the application.

When you first open Report Builder, the GettingStarted dialog box appears, as shown in Figure 1. (You can see the Report Builder interface behind it.) The dialog box provides several options for creating a new report or opening an existing one. For the purposes of this article and the ones to follow, we won’t be using this dialog box. If you like, you can select the Don’t show this dialog box at startup option so you don’t have to mess with it going forward. Or you can simply close the box by clicking the red Close button in top-right corner.

The welcome screen that appears when you open Report Builder

Figure 1: The welcome screen that appears when you open Report Builder

After you close the GettingStarted dialog box, you’re presented with the Home tab of the Report Builder interface, which is shown in Figure 2. At the top of the interface is the type of ribbon you’ve become familiar with in Microsoft Office products. It contains the options necessary to create and design your report. For each tab of the interface, the ribbon contains a different set of options. (You’ll learn more about these options as we progress through this article and the ones to follow.)

The Home tab of the Report Builder interface

Figure 2: The Home tab of the Report Builder interface

At the left edge of the Report Builder interface is the ReportData window, which provides a hierarchical view of the built-in fields, parameters, images, data sources, and data sets available to your report. As with the ribbon options, we’ll dig into these more as we progress through this series. Same thing for the RowGroups and ColumnGroups windows, which, as you might expect, are tied to the way you group data on your report.

The main part of the Report Builder interface is the layout window (outlined in red). This is where you construct your report. Here you can add and configure the elements necessary to display your data, such as tables, graphs, and charts. You can also add elements such as text, images, and lines—many of the things that make your reports more appealing and effective.

Report Builder also includes a set of options that apply to the application as a whole. To access these options, click the Report Builder button (the large round button at the top-left corner of the screen), and then click the Options button. This launches the ReportBuilderOptions dialog box, shown in Figure 3.

The Report Builder Options dialog box

Figure 3: The Report Builder Options dialog box

The dialog box opens to the Settings page, which lists a number of options related to the Report Builder interface and report deployment. For now, the only setting that might concern you is the option Use this report server or SharePoint site by default. When you installed Report Builder, you might have specified a Reporting Services (SSRS) report server where you would eventually deploy your reports. If you provided an incorrect URL or that URL has changed, this is the place to enter the correct information. If the information is incorrect, you will have to wait for Report Server to verify the connection every time you start the application, which can be somewhat time-consuming. So if this issue applies to you, enter the path and then click OK.

Note: If you’re connecting to a Reporting Services instance other than the default, you append the instance name onto the path, preceded by an underscore. For example, the report server on my system was installed as part of SQL Server instance ws02/SqlSrv2012. As a result, I appended _sqlsrv2012 onto the URL http://ws02/reportserver so it became http://ws02/reportserver_sqlsrv2012, as you can see in Figure 3.

You might have noticed that the ReportBuilderOptions dialog box also includes a Resources page, which provides access to details about Report Builder and to additional information available online.

One other feature you should be aware of before we get started is how to save a report. When you first open Report Builder, you are essentially starting a new report. You can save this report and then access it as you work on it. To do so, click the ReportBuilder button and then click Save. This launches the SaveAsReport dialog box, shown in Figure 4.

Saving a report in Report Builder

Figure 4: Saving a report in Report Builder

Although the SaveAsReport dialog box shows several option for saving a report, you essentially have two choice: save to the file system or save to the report server you designated in the ReportBuilderOptions dialog box. For now, we’ll simply save our report file to the local file system. On my system I navigated to the C:\DataFiles folder and named the report Annual Sales, which becomes the file name.

Notice that Report Builder reports use the .rdl extension, just like Reporting Services reports. Reporting Services reports and Report Builder reports are created using the Report Definition Language (RDL), an XML-based language that defines how data is retrieved and a report is laid out.

Once you’ve named and saved your report file, you’re ready to start creating your report. Be sure to save the file regularly as you develop your report. That way, you can always come back to the report and start where you left off. So, with that in mind, let’s get started.

Adding a Data Source to Your Report

Before you can add data to a report, you must be able to connect to a data source. The data source provides the connection necessary for your report to retrieve the data used to populate its contents. To add a data source, right-click the Data Sources node in the ReportData window, and then click AddDataSource. This launches the DataSourceProperties dialog box, shown in Figure 5.

Adding a data source to your report

Figure 5: Adding a data source to your report

As you can see in the figure, you provide a name for your data source and then choose whether to use a shared connection or a connection embedded in the report. The first option lets you browse to a shared data source that has been published to a report server. Since we have not set up any shared data sources, we’ll go with the second option, which means we need to configure the connection we want to embed in the report.

So provide a name for your data source—I used AdventureWorks on my system—and then select the option Use a connection embedded in my report. When you select this option, new options appear in the DataSourceProperties dialog box, as shown in Figure 6. Notice that you must now select a connection type and define a connection string.

Configuring your data source

Figure 6: Configuring your data source

A Report Builder data source supports numerous connection types. To see a full list of what’s available, click the down arrow on the Selectconnectiontype drop-down list. You can then select the connection type you want to use. For this article, we’ll be using the MicrosoftSQLServer connection type, which is the default value, so in this case, you don’t need to take any steps to specify the connection type.

Next, you must build your connection string. The connection string shown in Figure 6 (in the Connectionstring text box) is the one I built for our examples. To build the connection string, click the Build button. This launches the ConnectionProperties dialog box, shown in Figure 7.

Building a connection string for your data source

Figure 7: Building a connection string for your data source

From the Servername drop-down list, select the SQL Server instance that contains your source data. Then, if necessary, select an authentication model for connecting to that SQL Server instance. If you plan to use Windows Authentication, you don’t need to do anything. However, if you’ll be using SQL Server Authentication, you must select the Use SQL Server Authentication option and provide the necessary credentials. (To keep things simple for these exercises, I used Windows Authentication and ran Report Builder as an administrator.)

Next you must select the database that contains the source data. Since I’m using the AdentureWorks2012 database, that’s the one I selected. Figure 8 shows you what the ConnectionProperties dialog box looked like on my system after I finished configuring the connection properties.

Configuring the connection properties

Figure 8: Configuring the connection properties

After you’ve configured the properties, you should test your connection. Then click OK to close the dialog box. You’ll be returned to the DataSourceProperties dialog box, which should now look similar to the one shown in Figure 6.

You might have also noticed that the DataSourceProperties dialog box includes a Credentials page. (So far, we’ve been working on the General page.) As shown in Figure 9, the Credentials page lets you change the credentials used to connect to the data source. You can configure this page only if your data source connection is embedded in the report (otherwise the options are grayed out). The report server can then use these credentials to connect to that data source. This enables other users to run the report without having to provide credentials for the underlying data source connection.

Changing the credentials used to connect to a data source

Figure 9: Changing the credentials used to connect to a data source

For now, we don’t need to be concerned about setting these credentials. So return to the General page if necessary and again test your connection. Then click OK to close the DataSourceProperties dialog box. Your new data source is added to the DataSources node in the ReportData window.

Adding a Dataset to Your Report

The next step in building your report is to create a dataset. A dataset defines the actual data that you want to retrieve from your data source. For example, if you’re data source is a SQL Server database, the dataset will be based a query or stored procedure that returns a result set you can use to populate your reports. The dataset acts as a bridge between your report and the data source. The data source establishes the connection, and the dataset defines what data is retrieved through that connection.

To create a dataset, right-click the Datasets node in the ReportData window, and then click AddDataset. This launches the DatasetProperties dialog box, shown in Figure 10. The dialog box opens on the Query page, which is the only page we need to be concerned about for now.

Adding a dataset to your report

Figure 10: Adding a dataset to your report

As with the data source, you can use either a shared dataset or embed one in your report. Again, we’ll embed the information in the report. So provide a name for the dataset—I used AnnualSales—and then select the option Use a dataset embedded in my report. When you click this option, you’re presented with a several additional options, as shown in Figure 11.

Configuring a dataset for your report

Figure 11: Configuring a dataset for your report

First, you’ll need to select the data source on which the dataset is based. From the Datasource dropped-down list, select the AdventureWorks data source (or whatever you named your data source). Then, in the Query text box, enter the following query:

SELECT
  
BusinessEntityID,
  
FirstName,
  
LastName,
  
JobTitle,
  
City,
  
StateProvinceName,
  
CountryRegionName,
  
TerritoryName,
  
TerritoryGroup,
  
SalesQuota,
  
SalesYTD,
  
SalesLastYear
FROM
  
Sales.vSalesPerson
WHERE
  
TerritoryGroup IS NOT NULL;

As you can see, we’re selecting several columns from the Sales.vSalesPerson view. Each column returned from the query can be used as a field in your report. Click OK to close the DatasetProperties dialog box.

Your dataset should now be listed on the Datasets node in the ReportData window. And beneath the dataset, you should see a list of the fields returned by your dataset. For example, you should see the BusinessEntityID, FirstName, LastName, JobTitle, and all the other columns returned by your result set. You can now use these fields to build your report.

Adding a Table to Your Report

Once you’ve added your data source and dataset, you can add a data region or data visualization. A data region is a report object that displays your source data in a tabular format (rows and columns). Report Builder supports the following data region objects:

  • Table: A tabular object that contains a fixed number of columns. But the rows are dynamic, which means they can expand to accommodate the data you’re trying to display. It also means you don’t need to know how many rows of data will be returned by the data source when you add your table to the report, although you do have to specify the columns.
  • Matrix: A tabular object similar to a table, except that your columns can be static or dynamic, which means the report can grow both vertically and horizontally. A matrix is a lot like a crosstab or pivot table.
  • List: A tabular object that presents data in a freeform fashion. Lists are handy for creating forms such as invoices.

As we work through this series, we’ll dig deeper into each of these data region types. But for now, let’s look at the data visualizations. A data visualization is an object that displays the source data graphically in order to provide a conceptual overview of the underlying information. Report Builder supports the following data visualizations:

  • Chart: A graphical presentation of the data in the form of such objects as bar, pie, and line charts.
  • Gauge: A key performance indicator (KPI) that presents a range of data, with an indicator that points to a specific value within that range.
  • Map: Data presented against a geographical background. The data can be based on SQL Server spatial data, an Economic and Social Research Institute (ESRI) shapefile, or Microsoft Bing map tiles.
  • Data bar: A simple chart used in conjunction with other data and charts to present complex information in a small space. A data bar typically represents only a single data point.
  • Sparkline: A simple chart similar to a data bar, except that it typically presents a series of information.
  • Indicator: A small gauge that displays the state of a single data value.

As with the various types of data regions, we’ll go into each of the data visualizations more deeply as we progress through this series. For now, let’s focus on how to add a table to our report. To do so, go to the Insert tab, shown in Figure 12. As you’ll discover, the ribbon includes the data regions and data visualizations—along with other elements—that you can add to your report.

The Insert tab of the Report Builder interface

Figure 12: The Insert tab of the Report Builder interface

If you want, you can modify your design surface to make it bigger. You can also reduce the size of the RowGroups and ColumnGroups windows. For example, as you can see in Figure 13, I made the design surface bigger and moved the text box within the footer. (The footer is the region beneath the dotted line near the bottom of the design surface.)

Modifying the design surface in Report Builder

Figure 13: Modifying the design surface in Report Builder

The best way to learn how to move these elements around is to experiment with them. Normally it involves dragging a corner or side from one point to the other. If you’ve ever worked with a draw program, you’ll find the principles to be essentially the same.

Now let’s add out table. Click the down arrow beneath the Table icon on the ribbon, and then click InsertTable. Next, move your cursor to the design surface. The cursor becomes a plus sign with a tiny table icon. Position the cursor where you want the top-left corner of your table to sit, click the left mouse button, and then drag the cursor to the point where you want the bottom-right corner to sit. The red arrow in Figure 14 shows the direction to move the cursor.

Adding a table to your report

Figure 14: Adding a table to your report

When you let go your cursor, the table object is added to your report. It should look similar to the one shown in Figure 14 (without the red arrow, of course). The next step is to add the fields you want to include in your report. For the report I’m demonstrating here, we’ll add the following fields (in the specified order): FirstName, LastName, TerritoryGroup, SalesQuota, and SalesYTD.

To add a field, drag it from the list of fields in the ReportData window to the appropriate column in the table object. For example, drag the FirstName field to the first column and the LastName field to the second column. For the fourth column, drag the field to the right side of the table. When a heavy blue line appears, drop the field on that line. The column will be added to the table. You might have to play around with this a bit, but over all you should find the process very straightforward. Once you’ve added all five columns, your table should look similar to the one shown in Figure 15.

Adding columns to your table

Figure 15: Adding columns to your table

That’s all there is to adding a table to a report. You can now view the report so you can see how the table will look after the report has been deployed report. To view the report, click the View button at the left end of the ribbon. This will take you to the Run tab, as shown in Figure 16.

Viewing the table you’ve added to your report

Figure 16: Viewing the table you’ve added to your report

As you can see, the table is now populated with the columns and rows of data from your data source, with the column headings displayed in the first row. Notice that Report Builder automatically changes compound column names to separate words. By previewing the report in this way, you know how it will be rendered once it is actually deployed. The data might change, but the format itself will remain.

Moving Ahead with Report Builder

Of course, the way the table is currently displayed in the report is fairly inadequate. Although you now know how to add a data source, dataset, and table, that’s not enough to make a report something that people will want to look at. You must attend to the elements that control how the table and the rest of the report look so you’re presenting data in a readable and accessible way. In the next article, I’ll show you how to format your report to address these issue. Be sure to save the report you created here, because we’ll be building on that as we learn more about the various ways you can make your report a lot more appealing.

Robert Sheldon

Author profile:

After being dropped 35 feet from a helicopter and spending the next year recovering, Robert Sheldon left the Colorado Rockies and emergency rescue work to pursue safer and less painful interests—thus his entry into the world of technology. He is now a technical consultant and the author of numerous books, articles, and training material related to Microsoft Windows, various relational database management systems, and business intelligence design and implementation. He has also written news stories, feature articles, restaurant reviews, legal summaries, and the novel 'Dancing the River Lightly'. You can find more information at http://www.rhsheldon.com.

Search for other articles by Robert Sheldon

Rate this article:   Avg rating: from a total of 88 votes.


Poor

OK

Good

Great

Must read
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.


Subject: Report Builder underrated over oversold?
Posted by: randyvol (view profile)
Posted on: Tuesday, September 04, 2012 at 2:54 PM
Message: My comment is not on the merits of Report Builder, but rather the frequently offered opinion that 'anyone can use it'. I cite the Simple Talk description of this article, RB provides 'an intuitive way for anybody to create reports from data'.

My problem with the above is the word, 'anybody'.
Managers here read nonsense like this and wonder why they don't have RB on their desks. Then I have to waste a lot of time rolling it out to them, showing it to them and about the time I'm done explaining data sources to them, they lose interest and tell me that the tool is 'useless'.

RB isn't useless, but it isn't for anybody either.

What the article points out is that the steps are far from intuitive for 'anybody' unless the sampling of anybodies that people have in mind are SSRS BIDS users.

My 'anybodies' are end users.
The simple truth is that they don't understand data structures, models, tables, etc. They shouldn't need to. That's what I'm employed to do - make sense of the data for them and produce the reports they need. Their jobs consist of taking orders, making purchases, shipping out packages.

Why should they all need to learn how to do what I'm paid to do? The idea that someday, somehow, a tool will manifest itself to the end user, one that requires no knowledge at all of the underlying data in order to create 'great reports' is going to require a great deal more thought and effort than has been manifested thus far in RB.

Microsoft has a great product in SQL Server. Why they continue to try and convince people that 'anybody' could make use of it is beyond me.

Subject: follow up question
Posted by: Mike Smith (not signed in)
Posted on: Friday, September 07, 2012 at 8:10 AM
Message: With table report, can we provide users ability to filter on individual fields at run time? Much similar to excel tabular reports?
Thanks

Subject: Terrific
Posted by: Phewie (view profile)
Posted on: Thursday, December 27, 2012 at 7:38 AM
Message: A great article as ever, Robert. Thank you for taking the time to put this (and the many other tutorials you have authored) together. It really is appreciated!

Just a small request - would it be possible to to put a link to the following article at the bottom of the preceding one in future as it is not always straight forward to find the next one in order.

Thanks again.

Subject: Thank you
Posted by: Learner59 (view profile)
Posted on: Sunday, October 13, 2013 at 8:50 AM
Message: Hi,
My first step whenever I have to get up to speed with any new technology is to ask the question, Has Robert Sheldon done an article on it? If the answer is yes, my stress levels disappear...unfortunately I had forgotton to apply this step when I was tasked with investigating using Reporting Services for creating reports...
I bought books, went through Microsoft's site, and my stress levels went through the roof as I became overwhelemd with information,,,then I happened upon this article, and I followed it through step by step and my stress levels have disappeared, the right amount of information, in the right order and seems to be perfect for my brain, and many,many others also it seems,...what you do is some sort of magic..Thank you..hopefully I will not forget the "first step" in future

Subject: Report Builder 3.0
Posted by: JohnH (view profile)
Posted on: Wednesday, December 04, 2013 at 10:18 AM
Message: This article was good.
I was wondering though, how Report Builder 3.0 (RB3) handles report models as datasources. The original version 1.0 could use report models (also version 2.0 could do that too). Is there a "practical" use of RB3 and report models for the "End User" (who does not use BIDS and does not know SQL programming), especially for some Ad Hoc reporting approach?

Thanks
John

 

Phil Factor
Searching for Strings in SQL Server Databases

Sometimes, you just want to do a search in a SQL Server database as if you were using a search engine like Google.... Read more...

 View the blog

Top Rated

SQL Server XML Questions You Were Too Shy To Ask
 Sometimes, XML seems a bewildering convention that offers solutions to problems that the average... Read more...

Continuous Delivery and the Database
 Continuous Delivery is fairly generally understood to be an effective way of tackling the problems of... Read more...

The SQL Server Sqlio Utility
 If, before deployment, you need to push the limits of your disk subsystem in order to determine whether... Read more...

The PoSh DBA - Reading and Filtering Errors
 DBAs regularly need to keep an eye on the error logs of all their SQL Servers, and the event logs of... Read more...

MySQL Compare: The Manual That Time Forgot, Part 1
 Although SQL Compare, for SQL Server, is one of Red Gate's best-known products, there are also 'sister'... Read more...

Most Viewed

Beginning SQL Server 2005 Reporting Services Part 1
 Steve Joubert begins an in-depth tour of SQL Server 2005 Reporting Services with a step-by-step guide... Read more...

Ten Common Database Design Mistakes
 If database design is done right, then the development, deployment and subsequent performance in... Read more...

SQL Server Index Basics
 Given the fundamental importance of indexes in databases, it always comes as a surprise how often the... Read more...

Reading and Writing Files in SQL Server using T-SQL
 SQL Server provides several "standard" techniques by which to read and write to files but, just... Read more...

Concatenating Row Values in Transact-SQL
 It is an interesting problem in Transact SQL, for which there are a number of solutions and... Read more...

Why Join

Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.