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.

Something I see online all the time, is people trying to find a standalone download for SQL Server Management Studio. Until recently, it seems, Microsoft certainly didn’t make it easy to just install the client tools without having to install the entire SQL Server database engine as well. The are plenty of reasons why you might want to install just the client tools and not the database engine on your computer, after all, in this world of self-service business intelligence, it’s no longer just developers and DBAs who are playing with data directly.

Last year I had the fantastic opportunity to attend SQL Saturday #105 over in Dublin on the company dime. A fantastic, free training event, SQL Saturday brings together a number of industry leaders and enthusiasts to deliver talks on a number of topics related to Microsoft SQL Server. Well, my colleagues and I are thoroughly looking forward to next Saturday, 8th June 2013, when SQL Saturday makes its long awaited Scottish debut!

The other week, Microsoft announced GeoFlow for Excel 2013 at the SQL PASS Business Analytics conference in Chicago. While it’s not exactly new, it is at least, a pretty impressive looking addition to the data visualisation toolkit.

However, while GeoFlow finally brings 3D geographical visualisation to Microsoft’s self-service BI utility belt (in your face, Batman), it’s hard to make a case for it for any purpose except wowing executives and potential clients.

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. Yep, the December 2012 SSDT download was missing a key component: the project and item templates for developing MS BI projects in Visual Studio. Thankfully, the newest release (5th March, 2013) has finally added all of the MS BI templates to SSDT, so you can now develop SSIS packages, SSAS cubes and SSRS reports in the Visual Studio 2012 environment.

I recently posted some thoughts regarding Microsoft’s Windows-compatible Hadoop implementation, HDInsight. I was investigating it for a project that I figured would benefit from a distributed processing approach, although ultimately decided to pursue other alternatives. It led our team to make some quite interesting discoveries about Hadoop, and some scenarios of when current distributed processing solutions are and aren’t appropriate.

Hadoop. Everyone and their dog is talking about it. That and “Big Data”. There was an excellent post on Brent Ozar’s DBA Reactions Tumblr blog recently that encapsulated it perfectly, titled “When the executives ask if we’re Hadooping”. It’s a valid point though, Hadoop is mentioned in just about every article these days, along with the phrase “Big Data” (which I personally don’t like at all). The consensus, at least on the surface, seems to be that Hadoop will solve everyone’s problems, process anything, oh and bring world peace while it’s doing that. My sarcastic tone belies a genuine interest in playing about with it though. With so many people talking about Hadoop (in its many implementations), I was very keen to get an opportunity to try it for myself.

I recently posted about a quandary in which I found myself that led to me building my own extended ForEach File Enumerator in SSIS. All things considered, it was a reasonably straightforward experience, with most of my issues stemming from a relative unfamiliarity with Windows Forms development (I was always an ASP.NET man). The whole process can actually be split into four very simple steps to make things easier:

1. Create your Enumeration function.
2. Design your UI for SQL Server Data Tools (SSDT).
3. Validation and assignment of input from the UI.
4. Deploy your new component.

As long as your new custom component isn ’t too complicated, these steps can be completed very quickly, meaning you can be up and running in only a little longer than it would take to write everything in a Script Task, and think of the re-usability!