Ready to watch this entire course?
Become a member and get unlimited access to the entire skills library of over 4,900 courses, including more Developer and personalized recommendations.Start Your Free Trial Now
- View Offline
Note: These tutorials are applicable to both the 2008 and 2012 versions of SQL Server.
- Understanding the elements of a report
- Grouping table regions
- Joining data from multiple tables
- Displaying data in a matrix
- Customizing report parameters
- Filtering and sorting data
- Creating charts
- Adding sparklines and data bars
- Creating at-a-glance reports with indicators
- Using Maps in Reporting Services
- Configuring report security
- Printing and exporting reports
Skill Level Advanced
In all the reports I've created so far I've been creating and embedding a separate data source inside each report describing individually how each report will find and connect to its source of data. But as it's common to create a lot of reports that will connect to the same source--say the same database--we also have the idea of creating a shared data source, defining it once, and saving it and reusing it across multiple reports. You might wonder why I don't talk about these earlier. Well, it's because while shared data sources are great, they do add a little complexity that we just don't need right up front.
And the more familiar you are with creating a few of these embedded data sources, the easier it is to make shared ones. So I'm looking at a typical embedded data source here, like I've been doing all along. We're connecting to SQL Server, and I used the helper window in the Build button to create the connection string here. And here's the thing: any data source we define, whether it's shared or embedded, it's used multiple times in the lifetime of our report. Because when we are defining the report we are using this information to connect to the database, to ask it what its tables are, so we can build queries and preview data.
Well, it's going to ask us who we are, and if we can't provide the right credentials, it will refuse us access. So in the data source there is a Credentials section. Now all along I've just been letting it do the default option, which is use the current Windows user, Windows authentication, meaning who I am signed on to the network. Using Report Builder, that's who we're going to use to connect to the database. Now that assumes that the database knows who I am as a signed-on user on the network. But some databases need a different set of credentials to how I'm logged on to the Windows network.
We can provide these too. You can create a data source that includes a particular user name and password. You can prompt for credentials every time. You would enter in some prompt text like provide a username and password. If you're connecting to a really low-security database it might not even need any credentials. And the reason why we have to provide these is not only we're using this when we're building this report, but also when somebody runs this report, it's going to use this data source that connect to the database.
So selecting the option to use the current Windows user doesn't always mean use me as the author of the report; it means whoever is either trying to design the report or trying to run the report. And if you find, for example, that you can define a report successfully, but other people can't view it, it's often because you have access to the database, but they do not. Now, when you're having that problem, sometimes it's tempting to manually write in your own username and password here, embedding that information into the report. But be careful with that one, because it's much better to figure out whether the person who's viewing the report should have access to that database and if they shouldn't, then they shouldn't be using your credentials to bypass that.
Now, this is much more about your internal organizational structure and your database setup then it is about Reporting Services, but here is where we can provide pretty much any option you might want. Now creating a shared data source will also bring all of these choices right up front. I'm going to jump over into Report Manager, because you can't create a shared data source in Report Builder. You have to create it from Report Manager itself, and there are no helper windows to help us do it. Here is how to do it. I'm looking at the homepage of my Reporting Services Report Manager.
Now when I'm creating a shared data source I do like to have them contained in their own folder the same way we have report parts, so first I'm going to create a new folder here. Let's call it Shared Data Sources and go into that folder, and there is an option right here on the toolbar called New Data Source, and it gives us a web page to create this. I'm going to call this AdventureWorksLT. And notice that while some of this looks similar to what we see in Report Builder, we don't have a Build button. We don't have a helper window. We have to manually provide the connection string. Well if I just happen to have Report Builder open with an embedded data source, what I can do is actually just grab that guy out of here and paste it right back over into that website.
If you're familiar with creating connection strings, you're fine just typing them in. Although word of warning: if you aren't using a database that needs the server name backslash instance name, oftentimes Report Builder will construct that with two backslashes, though the shared Data Source window tends to get a little annoyed about that, so I'm going to subtract one of those. This simply means I'm connecting to dbserver\sql2012, which is the name of my SQL Server and the name of the machine that it's on, and initial catalog describes the actual database on that SQL Server that I'm connecting to.
Then we have the same Credentials option. Do I provide a new set of credentials every time by the user running the report, meaning we're prompting for information, the username and password. Am I going to explicitly hardcode credentials stored in the report server for this shared data source so that everyone who uses it uses the same credentials? If it's very low-security, I could say credentials are not required. Well I'm going to go with the Windows integrated security again. We have the Test Connection button. Let's give it a go. When I click that, it often changes the page up a bit.
I've got connection created successfully. I'm going to click OK. I now have a shared data source defined in my Report Manager on the Report Server. Now let's see how to use it. I'm going to jump back over to Report Builder, cancel out of this, and just create a new report. And for the first time I'm actually going to use the report wizard. I will select the Table or Matrix Wizard. Click that option. The first thing it's going to ask me for is a dataset. I'll tell it I'm going to create a dataset, but the first thing it's going to ask me for is a data source. Now if I already used a shared data source before, I'll actually find my most recent ones showing up here.
I haven't yet, so I need to go and browse for that one I just created. Click the Browse button. We should go out to the root of our report server. There is my Shared Data Sources folder that I had, and there is my AdventureWorksLT shared Data Source. Click Open. I can test that connection. We're fine. Click Next. It jumps into the Query Designer for me to define the dataset. I'll just quickly create something here. Just to prove that this one works, we'll go for Product Name, ProductID, and ListPrice. And we now have the table on the page and we're using that data source both when we're designing this and when we're running the report.
The important thing here not being so much this table, this could be showing anything. It's the idea of the shared data source. It has a slightly different icon if I expand the Report Data section, in that it has this little alias icon out there. Now from this point on, once you've used the share data source once, it actually gets even quicker. If I were to create another new report--I'm just going to abandon changes to the last one. We'd choose Table or Matrix Wizard. I'll create a dataset, and I already have that last data source connection that I defined, so very quick to start stepping through this.
I don't need to go through this. I'm just going to cancel out of it, as all I was doing was demonstrating this. Now, as long as they have been set up correctly, shared data sources are the quickest and easiest way to connect, and using them is considered a best practice. One reason for this is if your connection details do change--say the server name changes because you go from a development server to a production server--then you could change it once in the shared data source and that's much preferable than having to go into every single report with an embedded data source. Now one thing worth pointing out is if you're already using a lot of embedded data sources you don't have to remove them and re-create everything.
I could go to one of my reports that I have that's using a previously embedded data source, such as my Grouping and Joining example, open that up in Report Builder where right now I'm using an embedded data source pointing to AdventureWorksLight. What I could do is just change that over to use a shared connection and select my AdventureWorksLight version there. And now I'm using that shared data source, but I don't have to change anything else about this report.