LessThanDot

Less Than Dot is a community of passionate IT professionals and enthusiasts dedicated to sharing technical knowledge, experience, and assistance. Inside you will find reference materials, interesting technical discussions, and expert tips and commentary. Once you register for an account you will have immediate access to the forums and all past articles and commentaries.

LTD Social Sitings

Note: Watch for social icons on posts by your favorite authors to follow their postings on these and other social sites.

Oh wait sorry, I meant SSDT. Or was it SSDTBI? To avoid confusion about the developer tool to create BI solutions, Microsoft has changed its name a few times. You know, to make it less confusing. Here’s a nice overview:

BIDS or Business Intelligence Development Studio. The most non-confusing name of the bunch. This piece of software was delivered to you when you installed SQL Server 2005, SQL Server 2008 or SQL Server 2008 R2.

SSDT or SQL Server Data Tools. Introduced with SQL Server 2012. However, you have a tool with the same name for creating database projects, which you had to download and install separately (don’t get me started on which names this tool had before. Mildly schizophrenic to say the least.) This development environment uses the Visual Studio 2010 shell and you use it to build BI solutions solely for SQL Server 2012. So two tools with the same name. One for database projects, one for BI projects. One to download, one that came with the SQL Server install media. Enter confusion. Read more about it on the blog of Jamie Thomson (blog | twitter): More SSDT naming confusion. Also read his blog posts about the database project part of SSDT, they are mighty interesting.

SSDTBI or SQL Server Data Tools – Business Intelligence. In an effort to swiftly put a stop to all this confusion, SSDTBI was released with Visual Studio 2012. It’s basically still BIDS – or SSDT from the SQL Server installation media – but now with BI appended to make its purpose more clear. This environment uses the Visual Studio 2012 shell obviously, but is still used to create BI solutions for SQL Server 2012. Great deal of fun when you have two developers on the same project: one with SSDT (Visual Studio 2010) and one with SSDTBI (Visual Studio 2012).

Each tool exists in two flavors: either you already have Visual Studio and the BI templates are installed into your existing installation, or you don’t have Visual Studio and SQL Server install a shell for you, only capable of creating BI solutions. Less confusing now? OK, let’s move on to the real point of this blog post: which development environment do we use in SQL Server 2014 CTP1? (Which is just released in case you missed it)

When we start up the installation of SQL Server 2014 (try downloading the VHD with Windows Server 2012 R2 to get you quickly up to speed. I absolutely recommend it), we do not see any BI development tool mentioned in the feature list.

But when we take a look at the prerequisites that are going to be installed, we see the Visual Studio 2010 Shell listed.

However, this is most likely the shell for SQL Server Management Studio and not for any kind of BI tool. The start menu confirms our suspicion after the installation:

No BIDS, SSDT or SSDTBI to be seen. But how do we develop our BI solutions in SQL Server 2014 CTP1? Don’t they want us to test SSIS, SSAS or SSRS? Is it only about Hekaton and the updateable columnstore index in this release? Luckily no. When we dig a bit in the MSDN documentation, we find the following quote in the What’s New in Analysis Services and Business Intelligence page:

SQL Server Data Tools for Business Intelligence (SSDT BI), previously known as Business Intelligence Development Studio (BIDS), is used to create Analysis Services models, Reporting Services reports, and Integration Services packages. In this pre-release version of SQL Server 2014, SQL Server Setup no longer installs SSDT BI. The Visual Studio 2012 version of SSDT BI is now available as a web download from the Microsoft Download center.

The point here is, aside from the fact that they forgot to mention SSDTBI was previously known as SSDT before it was previously known as BIDS (inception!), is that you have to download the tool yourself, just as you did for SQL Server 2012 if you wanted to play with the Visual Studio 2012 version. And you can find it here. It’s only a mere 783MB.

My guess is that a later version of SQL Server 2014 will install some version of the BI development environment. I don’t know how it will be called –most likely still SSDTBI – or if it will be Visual Studio 2012 or Visual Studio 2013. It does mean however that SQL Server 2014 CTP1 has no new BI features for the moment, as you are using the exact same development environment as in SQL Server 2012. Maybe new features are added in a later release of SQL Server 2014, who knows?

One small piece of advice to finish of this blog post: when installing SSDTBI, choose Perform a new installation of SQL Server 2012, not the other one (and ignore the fact you are actually developing for SQL Server 2014).

All the features will be selected for you.

And after the installation, you can finally make some BI solutions on SQL Server 2014!

Related Posts

SQL Server Days 2014 is over, but it has been one great event. A very…

About the Author

Koen Verbeeck is a Microsoft Business Intelligence consultant at element61, helping clients to get insight in their data. Koen has a comprehensive knowledge of the SQL Server BI stack, with a particular love for Integration Services. He's also a speaker at various conferences.

@enders= right now the project version is still 11. The SSDTBI version you download has no clue it is connecting to SQL 2014. It is not included in the SQL Server 2014 install, so it is probably not the version they will release with SQL 2014.

Another way to see this is when you start a new SSAS Tabular project, the only compatability levesl are SQL 2012 and SQL 2012 SP1. 2014 is not included in the list.

@phani= Visual Studio has always been a 32-bit application and it will be for the foreseeable future, at least as far as I know.

When you debug an SSIS package, SSDTBI will simulate a 64-bit environment, so 64-bit providers will be used. If you explicitly want to run a package in 32-bit mode, you have to set the Run64BitRuntime project property to false.

Hi,
I have created a package with one execute sql task to return the recordset(object variable) and used in scrip task in one container(sequence) and when tried to use the same recordset in another sequence container with the same package, only the column value is filled by data adapter(the row metadata values are not filled). I checked by using the dataflow task with recordset destination the result are same.
Could someone help me in this.
Thanks,
Riju