Something exiting I discovered when using Sql Server Reporting Services 2008 is the placeholder.

What's a placeholder you might think ?

Well, imagine that you are adding a textbox to a report footer and in that textbox you would like to show who executed the report at what time. You can do this by adding a textbox to your report and use an expression behind it to get the required data. The information about who executed the report and at what moment can be found in the Globals collection. Nothing new so far…

When you proudly show your report to the user who requested the report you explain him that at the bottom of the report he can also see who executed it and at what moment. The user is impressed by this and then asks, "Very nice, but could the username and executiontime be in another color then the rest of the txt in that sentence ?" Of course that's no problem you reply.

Now you have to redesign the report and instead of using 1 textbox with 1 expression, you know have to split it up into several textboxes. Why ? Because the data in the textbox has the same layout (font, color,…).

Using a placeholder is a better solution for this problem. A placeholder is like a textbox inside another textbox.

For example you can go into the original textbox and right click:

Then this popup will open:

And here you can enter the text that has to be displayed, even using an expression. And as you can see, there's a Font tab for this Placeholder, so you can assign it it's own Font properties.

For example:

Reporting Services stores execution data in several tables in the report server database. Because the internal table structure does not present report execution log data in a format that is accessible to users, a view was created: ExecutionLog. In Sql Server Reporting Services 2008 this view was extended to a new view: ExecutionLog2.

The report server execution log contains information about the reports that execute on the server or on multiple servers in a scale-out deployment. You can use the report execution log to find out how often a report is requested, what formats are used the most, and how many milliseconds of processing time is spent on each processing phase.

If you want to go a step further, you could extract the log data and store it in a separate local report execution log database that you create. This way you could extract data from the ExecutionLog view and store it into a separate database. Then you could create performance & execution related reports on that database.

And here's something great: Microsoft provides you with everything you need to create & implement such a solution, for free !

• All of the sample files used to query and view report execution log data are included in the Reporting Services report samples on the CodePlex site at http://www.CodePlex.com

To view the report server execution log, you can use the following:

• A sample script file called Createtables.sql that creates a new execution log database specifically for viewing log data.
• A sample SQL Server Integration Services package called RSExecutionLog_Update.dtsx that extracts data from the internal report server database and copies it to the sample execution log database that you create.
• A collection of sample reports that retrieves data from the execution log database and displays it in reports that you view on a report server.

Samples reports are also included that retrieve report execution data from the local report execution log database. The reports work with a local database that contains execution log data. Once you create the database, you can run the package to fill it with data, and then run the reports to view information about report activity.

The following files are used together to create the database and extract data:

• RSExecutionLog_Update.dtsx
• RSExecutionLog_Update.dtsConfig
• Createtables.sql

The following sample reports provide information about report server activity:

• Execution Status Codes.rdl
• Report Summary.rdl
• Execution Summary.rdl

Examples:

 

When creating Sql Server Reporting Services Reports you can sometimes end-up with data in US format instead of the local regional settings of the user.

For Example:

Here we have a report showing the Sales LCY and Profit LCY by Salesperson and Country in a matrix control. The data is coming from the Dynamics-NAV Sql database, but the formatting of the amounts is in US format, even when the report is running on a system that has Belgium regional settings.

How can we correct this?

Well there's a simple solution for this common problem. In the Report Designer in Visual Studio, the report has a LANGUAGE property:

By default this will contain English (United States), but by changing it to an expression you can make it dependant on the users Regional Settings:

Select <Expression>, then the Expression Editor opens. Then type in =User!Language

Run the report again to see the result:

Then Report will recognize user client's culture settings, e.g. Internet Explorer's languages settings.

Recently, when I was looking up some information regarding Sql Server Reporting Services, I came upon this Blog: http://www.biblogs.com

I found it to be a very interesting blog and thought it's so interesting to share it with the Plataan knowledge blog addicts.

The goal of the blog is to provide that central place people can come to easily find information in the business intelligence and data warehousing space.

In the past we only had these containers: List, Table, Matrix, Chart in Reporting Services. In Sql Server 2008 there's a new container, a Tablix: a Table and a Matrix in one.

On the left is a table with fixed columns and dynamic rows. On the right is a matrix with dynamic columns and rows. But what do you do if you want to mix dynamic and static columns like this? With tablix, it's easy.

Example:

Tablix gives you all the features of both a table and a matrix. You can mix and match behavior of fixed or dynamic as needed. In addition, you can group data more flexibly. Groups can be nested and recursive just as in SSRS 2005, but you can also place groups adjacent to each other.

To summarize:

Matrix is dead, long live Tablix!

Microsoft released SP3 for NAV 4.00. For Business Analytics this means a few things. First and most important we now are able to support SQL Server 2005 with the Configurator. This means that you now can create cubes from NAV 4.00 SP3 on SQL Server 2005 Analysis Services. This also means that the version of Business Analytics Advanced can't connect the cubes that can be created with the new version of the Configurator. But there are plenty of other ways to consume the cubes that can be created with the new Configurator. Excel, Reporting Services, Report Builder, Proclarity and Business Scorecard Manager are all good examples of clients that can connect and consume the cubes on SQL 2005.