 A comparison of dynamic pivoting and Excel export features of different SQL Server technologies. [© Joris Korbeeck]. |
Companies are converting to a data warehouse for their
business intelligence (BI) solutions, like the medium-sized enterprise where I am part of a two-man data management team. Weighing the
pros and
cons of technology
x with respect to technology
y makes an important—but often underestimated*—part of the
design and development process. In the (
Microsoft)
SQL Server section of my weblog
Negentiennulvier.nl I write about my experiences with this matter; I invite you to join the
discussion.
Last week I had to automate the monthly delivery of an information request and stumbled upon a common phenomenon:
pivoting to create a less normalised representation of the data. Although common, and a standard feature of the
Transact-SQL (T-SQL),
Integration Services (SSIS) and
Reporting Services (SSRS) technologies, pivoting a dataset with ‘
dynamic’ columns could be challenging. That is when the number of pivoted columns is unknown at design-time. Apart from scheduled (e-mail) delivery I have made an overview of two major requisites, dynamic pivoting and export to
Microsoft Excel file format capabilities (in the
diagram above).
András Belokosztolszki describes in detail how this can be down using
dynamic SQL; I recommend reading his post
2, but it comes down to:
DECLARE @cols nvarchar(2000)
SELECT @cols =
STUFF((
SELECT DISTINCT '], [' + ColName
FROM Table1
ORDER BY '], [' + ColName
FOR XML PATH('')
), 1, 3, '') + ']'
Unfortunately
Excel export via
distributed queries (not enabled by default
3) has the same problem regarding to variable column headings, and therefore regarded as too rigid. SSIS simple does
not support dynamic columns in Data Flows and its Pivot transformation, because output column metadata has to be entered—thus known—during design-time; needless to say its file export feature is excellent. SSRS’ Matrix component to aggregate data in a grid that has variable columns and/or rows
does the job, together with its advanced
Excel rendering extension this seems the right approach.
One has to note however that this layout renderer causes merged cells when encountering slightly different column widths (e.g. when converting grids, fields en labels to
Excel cells). On
MSDN Blogs Chris Baldwin hints to use points instead of centimeters to prevent internal rounding inaccuracies and workaround this inconvenience to end-users.
1 Nevertheless I found out that this should be done by editing the
XML source code. Only when you enter the point measures directly,
Visual Studio—often called
BIDS—sticks to those values (instead of converting it to centimeters or inches).
1 Baldwin, C., “Merge Ahead”,
MSDN Blogs,
link, 7 July 2006.
* Probably subject of a future post.
2 Belokosztolszki, A., “Pivots with Dynamic Columns in SQL Server 2005”,
Simple-Talk,
link, 14 September 2007.
3 “ad hoc distributed queries Option”,
MSDN Library,
link, 12 January 2010.