To me it seems as if the Business Intelligence solution stack is only three quarters finished.

We have all these powerful tools that allow us to extrapolate data from various systems and processes throughout the organisation (for example SSIS). We also have a means to centralise the data in a standardised and optimised structure to fuel analysis (for example Analysis Services), but we are missing the simple/easy to use interface in order to expose the data to end users that require it. Reporting Services is certainly not up to job in my opinion. It is just not flexible enough in terms of features and more importantly it is not accessible to a typical business user.

At present a skilled analyst is necessary in order to provide a business user with access to the specific metrics/analysis that they require.

If this knowledge gap can indeed be bridged in the future, then the power to extrapolate business insight will finally be placed in the hands of the users that actually need it.

How to configure SQL Server Reporting Services 2005 to permit users to assign the delivery email address for their own subscriptions.

Why does SQL Server work this way?

When you subscribe to a report, the e-mail delivery settings you work with vary depending on whether your Role includes the “Manage individual subscriptions” task or the “Manage all subscriptions” task. See E-Mail Delivery in Reporting Services for further information.

By default, a Reporting Services user cannot modify the email delivery target for their own subscriptions. Now providing a user the ability to Manage All Subscriptions on a given Report Server is not really a practical solution.

How can I make it work my way?

As an alternative what you can do is modify the security settings of the Report Server to allow a user to specify the delivery email address for their own subscriptions.

This requires a configuration change to the Report Server Configuration File

Modify the value for the “SendEmailToUserAlias” XML Attribtue to be “false” in order to permit any email address to be specified.

See Configuring a Report Server for Email Delivery for detailed instructions.

Additional Considerations

If you are going to permit your Report Server users to be able to specifiy the delivery address for their subscriptions then it is wise in my opinon to also limit the Domains to which you permit delivery to, for example only trusted domains internal to the organisation. This can also be configured within the very same Report Server configuration file.

There you have it. Simple when you know how.

What’s the problem?

When you create a dataset from a SSAS data source, by default the date values returned from a given Dimension are treated as strings. Now in order to use the Calendar control that is built into SSRS, the report parameters need to be defined as Datetime data types.

So naturally you go ahead and change the parameter data type and execute the report however, doing so raises an error of the form below.

An error occured during local processing.
An error has occured during report processing.
Query execution failed for data set ‘TestCalendarDataSet’.
Query(47,14) the restrictions imposed by the CONSTRAINED flag in the
STRTOSET function were violated.

Why does this happen?

This occurs because the data returned by the Calendar control (a datetime value) is not appropriate, as the MDX query is expecting a Dimension Memeber value.

For example, the MDX code with the datetime parameter is of the form:

STRTOMEMBER(@Date, CONSTRAINED)

And substituting an actual datetime parameter results in:

STRTOMEMBER(“2009-01-01″, CONSTRAINED)

Clearly  “2009-01-01” is not a valid MDX Member Value.  A valid value needs to be of the form:

STRTOMEMBER([Date].[Date].&["2009-01-01T00:00:00"], CONSTRAINED)

How can I fix it?

In order to make using a datetime parameter with a SSAS data source work, you need to manually convert the parameter value, which is a string, to an MDX Member value.

Here’s how:

1. Go to “Data” tab in Report Designer.
2. Choose the dataset that populates the report, and click the “…” button beside it.
3. Now, the “Dataset” dialog window shows, and clicking the  “Parameters” tab in the dialog shows the list of parameters you may choose.
4. Assume the calendar control parameter is @Date, in the  “Parameters” tab, you will have “Date” in the “Name” column, and “=Parameters!FromDateDate.Value” in the “Value” column.
5. Now, change the value column to: =”[Date].[Date].&[” + Format(CDate(Parameters!Date.Value), “s”) + “]”
6. Click “Ok” and close all windows.
7. Click “Preview” to test the result.

Summary

In order to use the Calendar control for a SSRS report that encompasses a SSAS data source, the string value of the datetime parameter must be converted to an MDX Memeber Value before being passed to the data source.

I hope this tip helps you with your report designing endeavours.  I really enjoy reading all your comments and hearing about your experiences with SQL Server technology,  so keep your feedback coming.

Virtualisation

As you may already know, I am big fan of the work of Brent Ozar, a talented SQL Server professional and online author of excellent quality SQL Server content. I particularly enjoy his podcast series and think the clear, direct style of his presentations are brilliant. You can learn a great deal in a relatively short space of time and as I commute daily into the city of London, I find Brent’s podcasts a great way to maximize this otherwise lost time.

This week I watched the first in a series of podcasts about the use of Virtualisation technology and SQL Server. Virtualisation is a really hot topic right now, what with the current economic climate forcing businesses to really drive down costs and look for ways to streamline their IT platforms. If you have not worked with virtualisation technology before this podcast series provides a solid overview.

You can download the first podcast in the series here: Virtualization Basics

Reporting Services Style Sheets

As a Business Intelligence professional, you are responsible for a very large volume of SQL Server Reporting Services reports. You will no doubt understand that modifying the aesthetics can be a real chore and is probably not the best use of your time. If you have ever needed to update the look & feel or cooperate branding for each and every one of your reports, then you will know exactly what I am talking about.

So if you want to save yourself a significant amount of time then I thoroughly recommend that you look into the use of Style Sheets to manage the presentation of your reports. This is a great way to centrally manage the look and feel of all of your reports and the best part is that it is easy to implement. That’s right, you can update or modify the style of all of your SQL Reporting Services Reports, by making a single code change.

Find out how here: Centralising Reporting Services Stylesheets

“the difference of two datetime columns caused overflow at runtime”

This is because the DATEDIFF function returns an int value and once you have a connection that is more than 24 days or so old it will overflow the data type.

In order to work around this issue simply substitute the code from the stored procedure MS_PerfDashboard.usp_Main_GetSessionInfo (most likely located in the MSDB database) below:

sum(
	convert(bigint,
		datediff(ms, login_time, getdate())))
		- sum(convert(bigint, s.total_elapsed_time)
	)
	as idle_connection_time,

And replace it with:

SUM
(
	CONVERT
	(
		bigint,
		CAST
		(
			DATEDIFF ( minute, login_time, getdate())
			AS BIGINT
		)
		* 60000
		+ DATEDIFF
		(
			millisecond,
			DATEADD
			(
				minute,
				DATEDIFF(minute,login_time,getdate()),
				login_time
			),
			getdate()
		)
	)
)
- sum(convert(bigint, s.total_elapsed_time))
as idle_connection_time,