
Populating the Select the Data Source screen in the Report Wizard.
The user is given a choice of pressing the Query Builder button or entering their query in the Query string textbox.
The report type we choose is heavily dependent on the query and the type of information we wish to convey in the report.
Report Wizard's Design the Table screen will save much time and effort while creating new tabular and matrix reports.
The Choose the Deployment Location screen of Report Wizard only appears the first time a report is created in a new SSRS project. The deployment settings can be changed by selecting the Project properties in Visual Studio.
Report Wizard will not automatically format the column width to fit the header or the data.
SSRS provides a mechanism to change the data from the sort order provided by the report query.
Within the report, fields can be calculated using the data returned from the query using SSRS built-in fields, Expressions or a combination of all three. Expressions will allow for greater flexibility in the display of data and formatting.
The formatting of cells in SSRS is similar to formatting cells in Excel. Most of the terminology is the same.
Your organization's report server should be controlled by your database administrator and quite possibly by your network administrator.
Just because the report displays nicely on the screen does not mean the report is formatted properly on paper.
Report Wizard does not automatically add a header and footer to the report. We will have to add them manually.
There are numerous built-in fields that come with SSRS. We can add these to the header or footer so that it helps the viewer to navigate the report.
Adding query-defined fields to a report can be tricky, especially if more than one row is returned.
An organization's logo in the header of the report makes a report look official.
Printed reports still remain a security issue when confidential information is contained within these reports. For printed reports, metadata can be used to identify who accessed the data, when the data on the report was last updated, and when they accessed the data.
It is important to write queries that take advantage of the database server's processing power, especially for drilldown reports.
With a well-written query, Report Wizard can efficiently create a drilldown report that will minimize the development effort.
The symbols to the left of the tablix related to the row groups below the report in the Design mode.
By default, the groups are collapsed.
The grand total of rows and columns can be added to drilldown reports.
The different parameter types affect the behavior of the report and the way in which the user interacts with the report.
Setting available parameter values and default values reduces the likelihood of a user creating a report with unintended data. As report developers, building this robustness in the report is beneficial to the user and us.
Parameters can allow the user to change the data displayed in the report without changing the report query. Defining a parameter alone will not impact what data is displayed on the report. Filters can be created that utilize the defined parameters.
If we export the report to a PDF or print the report, the parameter value is not displayed. We need to display the parameter value so that the user will know what parameter value was used to generate the report.
Drillthrough reporting requires a parent report and a child report. The child report contains additional details about an item found in the parent report.
The child report needs to display only the data associated with the item in the parent report. Report parameters can be used in the report query's WHERE clause. In SQL Server Reporting Services, a report parameter is a separate entity from a query parameter.
The text box of the item of interest in the parent report must be enabled to allow drillthrough actions to occur. The child report for drillthrough purposes must already exist.
Both the parent and the child reports in drillthrough reporting must be deployed together for the proper operation of the reports.
Pie chart queries need to return labels, counts, and percentages. The percentages in the pie chart queries need to add up to 100 percent. Bar chart queries need to return a label and a numeric value.
Pie charts are an excellent way to demonstrate how data is distributed by percentage across different categories.
A bar chart is an excellent way to show two-dimensional data when you have a few data points. The SSRS Bar Chart shares many properties and attributes with the Column Chart.
There are a myriad of ways to configure report legends, titles, labels and other properties for chart objects.
SSRS report definitions are reusable objects which may be embedded into other reports as subreports.
Gauges, sparklines, and indicators are report objects in SSRS which provide an impressive way to display summarized information for presentations, documents, and web pages. Each object requires specific data elements for proper operation and to give the user the scope of the data.
Gauges are an excellent way to show progress towards a numeric goal.
Sparklines can help add a historical perspective to numbers displayed in a table.
SSRS indicators are an excellent way to show progress towards a categorical goal or the current status of a process.
Dashboards allow for online reporting of high-level information to allow management to quickly find where the business is performing well and where attention is needed..
Creating Reports with SQL Server 2012 Reporting Services will show you how to develop practical reports that utilize tables and matrices, along with bold objects such as pie charts and gauges that quickly gain the attention of the viewer and deliver your message. With this course, you can acquire the essential skills you need to make an impression on your customers, your audience, or your boss.
Dr. Dallas Snider is an Assistant Professor in the Computer Science Department at the University of West Florida (UWF). He received his Ph.D. in Integrated Computing and M.S. in Instrumental Sciences from the University of Arkansas at Little Rock. He received his B.A. in Physics from Hendrix College in Conway, Arkansas. Before joining UWF, he worked as a Data Warehouse Developer for Northrop Grumman Information Systems, and prior to that as a Database Application Developer for Acxiom and Euronet. Dr. Snider's research and teaching interests include data mining, data warehousing, software development, and security.