THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Jamie Thomson

This is the blog of Jamie Thomson, a data mangler in London working for Dunnhumby

More SSDT naming confusion

I have blogged previously at SSDT – What’s in a name? about the naming confusion that Microsoft have created by their inconsistent use of the term “SQL Server Data Tools” (SSDT) in SQL Server 2012. Is it a Visual Studio shell incorporating project templates for building databases, SSIS packages, SSAS cubes & SSRS reports? Or is it simply the project template for databases? Pick any two people on the SQL Server team and they’ll probably give you two different (and probably ambiguous) answers.

The situation infuriates the hell out of me but probably not as much as it does this guy who posted to the SSDT forum:

I installed SSDT 2012 (December version) on an existing Visual Studio 2012 Premium install but I can't find the BI templates!!!?

When informed that the BI project templates (i.e. SSIS, SSAS, SSRS) only come with a SQL Server installation and that actually they’re (still) not available for VS2012 he had this to say:

I wish this was better documented so that I could have saved a few hours.

That’s a guy who has wasted hours of his life simply because Microsoft can’t name their products properly and sensibly. Is it really that difficult?

Rant over. Sorry, but it needed to be said.


UPDATE. A day after publishing this blog post and I stumble across someone asking a question about SSIS on the SSDT forum. The SSDT forum is for questions about SSDT database projects but of course, this person has read all the documentation from Microsoft saying that SSIS is part of SSDT and hence posts his SSIS questions on the SSDT forum. This is bad. Bad bad bad.

Published Wednesday, January 16, 2013 11:05 PM by jamiet

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Scott Newman said:

Add me to that list of users who wasted hours trying to get this figured.


January 16, 2013 6:29 PM

Mike Henderson said:

Why bother publishing something called Microsoft SQL Server Data Tools and not include support for SSIS, SSAS, SSRS? If each new version of VS may or may not have support for current versions of SSIS et al., maybe they should roll the tooling into Management Studio.

Because I develop for SQL 2005 through 2012, plus web development, I end up with three versions of VS on my machine.

Now my rant is done.

January 17, 2013 7:08 AM

Waltman said:

hours and hours of trying to get access to my BI projects has been flushed down the drain thanks to MS ineptitude at internal communications and planning, only to have to reinstall Visual Studio 2010 and some data project patch (who knows what actually ended up working).  

January 17, 2013 9:44 AM

M Noreen said:

Add me to that list too.  We spent more than hours figuring that out. And, it's just a confusing mess to have so much "litter" coming from Microsoft... do you think the Microsoft teams even talk to each other? We use VS2012, and SQL 2012, but end up with a VS2010 "shell" for authoring SSIS packages and SSRS reports.  But you can download a 2012 SSDT, but that has nothing to do with SSIS and SSRS.  

I've got too many DLL/assembly references to contend with. It seems to much time is spent trying to figure out how to get everything installed and playing nicely with each other and then "configured"... rather than actually USING the tools to get work done.

January 17, 2013 11:03 AM

daniel said:

to the men above - if you'd spent reading the documentation for SSDT you would know that fact already.

January 17, 2013 3:11 PM

Ian Yates said:

I agree that the naming is just plain crazy.  I suppose the mitigating factor (from my point of view) is that the only way you ever got the SSAS/RS/IS designers was via the SQL Server installer - that hasn't changed.  The BI Development Studio name was a lot better than SSDT for those products, but at least the delivery mechanism is still the same.

If you're using these tools for the first time I can definitely see the additional confusion this would raise.

The shipping cycle of SQL 2012 was out of step with VS2012 so the reliance on the old VS2010 shell (which you really don't need to explicitly call for, same as you didn't launch an icon called VS2008 for BI Dev Studio) is understandable.  MS have the same issue with support for SharePoint and related technologies - SP2010 wasn't .NET 4 friendly as I recall since it was largely baked by the time .NET 4 was ready for release.  This resulted in similar confusion for those developers and IT Pros who weren't keeping tabs on the two products prior to release...

As someone who's just getting started with ASP.NET WebAPI with OData, MVC, etc, etc the naming conventions and tooling there is equally as confusing.  What's worse, the existing community all know the "rules" and what products are deprecated, whether or not the fall update is worth installing or if you should get things from NuGet (and prerelease, nightly or just what's normally available).  But if you're new to the scene there's a lot of old information, some only from early 2012, that's just wrong now.

</rant>  :)

January 17, 2013 7:42 PM

Daniel said:

The irritating thing for me that MS said that the BI templates for VS2012 are in progress (in August 2012);now we are 6 months later and still no word when they will release.

January 21, 2013 3:40 AM

James D said:

I've spent the past few weeks first on MSDeploy then now SSDT, with a fair bit of MSBuild. This was alongside getting to grips with TeamCity. What a contrast. While the microsoft tools are powerful and robust, the documentation and the recording the bits that don't work properly, or how some of the finer detail of how the bits that do work, actually work, is absolutely lousy, I've lost hour upon hour trying to work out some arcane aspects of these tools (I always seem to not do any MSBuild for long enough to forget how that utterly bewildering tool can give you a severe stress headache). Forget Bing btw, Google is king, but even then it means skim reading and revisiting blog post after forum post after article trying to pick up the odd clue as to how this all hangs together. Example: the Pre and Post deployment script mechanisms, handling permissions across different environments (you can't, well not without some serious scripting), and so on and so forth. I know it's all free (well as free as the paying for the actual platforms to run our apps on), but after over 10 years of being bitten by microsoft's approach to product architecture and behaviours (where you spend days trying to get something to work, then more days helping an MS engineer reproduce a problem, for them to quietly admit it's a bug they already knew about and don't use that feature- this has happened to me), you'd think i'd learn but i'm trapped in this hell - as for product naming, I really gave up caring and accept the confusion that reigns when there's some kind of realignment and renaming (SPS to WSS/MOSS to whatever it was for 2010 and God knows what for 2013). Good post, keep them up- at least there's bloggers like you who post so many gems, I wish I could but by the time i've solved an issue worth blogging about all I want to do is forget about the trauma and move on to the next adventure.

January 22, 2013 3:40 PM

anon said:

first-hand knowledge of the situation:  this is a cluster-#^*! created by a bunch of know-nothing marketing people who wanted a concise umbrella-name for all of SQL's tools.  Nevermind that they the individual product teams weren't coordinating their deliverables, releases, capabilities or installers.

January 24, 2013 11:56 AM

James Serra said:

The most popular blog post on my site is about this very issue: "Visual Studio 2012 does not support BI" (  And remember how history repeated itself as we had the very same issue with Visual Studio not supporting BI for a long time.

January 26, 2013 12:09 PM

Leave a Comment


This Blog


Privacy Statement