The other week I wrote a post discussing how PowerView was the future of SQL Server Reporting Services, and the killer features that made it a compelling choice. Despite the numerous positive advances that PowerView brings to Microsoft/SQL-based reporting, there are of course a number of counter arguments. I deliberately left these out in order to look at some of these reasons in a later post.

As such, here are five reasons why PowerView, despite all its pizzazz, is simply not capable (in its current form) of replacing the venerable SSRS.

Since its introduction with SQL Server 2012, PowerView has started to become the familiar face of Microsoft’s self service business intelligence offering. Its inclusion in Excel 2013 has only reinforced its position as the premier tool for quick, interactive visualisation of data, in conjunction of course with the magnificent PowerPivot. But ask any “traditional” BI developer/architect about Reporting Services (SSRS), and it’s likely that they will staunchly defend it, decrying PowerView as a gimmick.

So here are 6 reasons why PowerView is NOT a gimmick, and may in fact be the future of SQL Server Reporting Services.

As if renaming the accurately titled Business Intelligence Development Studio (BIDS) to the rather ambiguous SQL Server Data Tools (SSDT) wasn’t bad enough, in December, Microsoft’s latest SSDT release only brought half the expected capabilities to Visual Studio 2012.

With the year drawing to a close, I thought it would be the perfect time to recap the major developments in Microsoft Business Intelligence throughout 2012. Unsurprisingly, the launch of SQL Server 2012 proved to be the focal point of this year’s releases, although we had a few extra surprises along the way:

Some pretty interesting information leaked out of last week’s SharePoint Conference 2012 regarding Microsoft’s upcoming Mobile BI (Business Intelligence) solution. There’s been surprisingly little reaction to the unveiling of the solution, apparently codenamed “Project Helix”, perhaps due to the fact that it was unveiled at a SharePoint event and not a SQL Server one. However, courtesy of one attendee tweeting some screenshots to SSAS guru Chris Webb, this little nugget of information landed in my inbox this morning and immediately piqued my interest. Unfortunately there’s very little information available on “Project Helix” at the moment, but from the 2 screenshots provided by attendee Just Blindbaek, there are a few things that are immediately apparent, and a couple more that can be reasonably inferred:

I was recently involved with the migration of a Native mode SQL Server Reporting Services (SSRS) database from a non-domain server to a domain-based server. The migration itself was fairly straightforward (as it usually is) thanks to the inherent portability of the Report Server database and required configurations, such as encryption keys and .NET config files. However, after getting everything up and running on the new server, and successfully testing the reports manually, I discovered that the report Subscriptions were failing.

I was asked recently how one could use SQL Server Reporting Services (SSRS) Report Builder construct a report using a SQL Server Analysis Services (SSAS) cube as it’s data source.  The good news is that is just as simple as connecting to a SQL Server database, there’s really very little difference, at least if you using the GUI route.

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: