The 2012 version of SQL Server has brought with it a number of new features, not least the new, Visual Studio 2010 shell-based Management Studio. However, the changes are more than just aesthetic, as I found out when I came to try and upgrade some SQL Server Integration Studio (SSIS) packages from SQL server 2008 to 2012. Most packages upgraded fine, but there were some issues when I tried to upgrade any packages that used Script Tasks containing references to external DLLs.

I’ve been looking at migrating some SQL Server Integration Services (SSIS) packages lately, and as part of the move, am parameterising a lot of settings to improve the ease of future configuration changes.  One of these changes involved a package that reads from an XML source and uses an XML Schema Definition (XSD) file to validate the source file.  However, with the XML source being in the data flow, you’re not allowed to set an expression on this property to assign a value at runtime.  Or at least not directly.  So, if you want to assign the XSD location from a variable or project parameter, just follow these simple steps.

Just a quick one for a Wednesday afternoon.  I was recently asked if it was possible to enable remote errors in SQL Server Reporting Services (SSRS), so that people (and applications) could return full error details from RDL execution, without having to consult the local log files.  It’s an incredibly easy task to enable this.  Here’s how:

So, you’ve finally got around to setting up that SQL Server 2012 environment and you’re playing about with PowerPivot and SQL Server Analysis Services.  You’ve set up your sharepoint site and you’ve created and uploaded a new spreadsheet using PowerPivot that contains all that tasty cube data.  However, in your haste, you haven’t set up SQL Server Reporting Services Report Builder on the Sharepoint site, so when you open Report Builder on a separate server (or from a local install), and want to connect into your new quasi-cube (via your PowerPivot Excel file), how do you do it?  The Report Builder side of things is not too dissimilar to using a traditional SSAS cube as a Data Source.

The answer, is deceptively simple if you know where to look.

As I mentioned in my last post, I was recently over in Dublin attending SQL Saturday 105, a SQL Server conference and networking event hosted by PASS.  For anyone considering attending a future SQL Saturday event, I can definitely recommend it for developers, Database Administrators (DBA) and Business Intelligence (BI) developers of any level, from enthusiastic amateurs all the way to expert consultants.  Given the fortunate timing on Saturday’s event, it also doubled as the European technical launch for SQL Server 2012 (codenamed Denali during development).

Featuring a total of six sessions covering 3 tracks (Developer, DBA and BI), the event was packed, as over 200 SQL Server professionals from all over Ireland (as well as our intrepid 3 from Edinburgh) flocked to learn about some of the new features of SQL Server 2012 or just to pick up some tips and tricks from some of the industry’s best.

As it stands, I’m currently getting organised to head to SQL Saturday #105 which takes place tomorrow (March 24th) in Dublin. This is the closest SQL Saturday event to Edinburgh so far, so I jumped at the chance to go. SQL Saturday is a regular event, created by the Professional Association for SQL Server (PASS) to provide SQL Server professionals and enthusiasts with opportunities to network with colleagues and experience some top quality training, while also being able to grow their own membership.

I recently encountered a scenario where I wanted to display my report content in the form of a multi-column list. In essence, I was looking to create the SQL Server Reporting Services (SSRS) equivalent of an ASP.NET Repeater, to render my report content both horizontally and vertically (in this case a dynamically repeated SubReport) a number of times dictated by my source dataset. I spent a little bit of time investigating some more complicated possibilities such as building a matrix of row and column groupings when the solution finally hit me. It is simply brilliant in its simplicity. Here’s how to do it.

Far too long ago, I posted part 1 of an article solving the import of large data files with varying columns using SQL Server integration Services (SSIS).  This is the belated follow up.  In part 1, I explained some example file structures and how we approach the problem of inserting these files, which all have a varying number of columns with different data types.   The solution combines a mixture of SSIS script tasks, external C# code in a referenced DLL and a flexible SQL Server DB schema.  This post will walkthrough my overall SSIS Control Flow, as well as detail how we translate a code based, dynamic object model into something well-defined which we can insert into a SQL Server DB.