Search results matching tag 'SQL Server Data Tools'

Creating your own SQL snippets in SSDT

jamiet — Mon, 22 Apr 2013 21:33:35 GMT

SQL Server Data Tools (SSDT) has a neat feature where you can add snippets into your scripts via the right-click context menu:

I’m finding it very useful indeed. The same feature exists in SQL Server Management Studio (SSMS) as well by the way:

One thing I really wanted to be able to do was create my own snippets for SSDT and I ventured to the SSDT forum to ask if it was possible. Turns out the answer is “yes” and Gert Drapers replied to my thread by providing an excellent run through of how to do it. What Gert’s post didn’t quite clarify is that if you follow his instructions then you have to manually edit the .snippet file that you created so that the language is set to SQL_SSDT:

(well, I had to do that anyway)

Once you do that you’ll be able to import the snippet into Visual Studio (Gert’s post shows you how) and thereafter your snippets will show up in the snippets menu:

Very handy indeed.

@Jamiet

Detecting Database Drift using SSDT

jamiet — Thu, 04 Apr 2013 09:31:00 GMT

One of the nice things about doing user group presentations is that when you’re putting the presentation together you invariably learn about features that were previously unbeknown to you; so it proved as I stumbled upon SSDT’s database drift detection features while researching material for my forthcoming pre-conference seminar SSDT from the ground up.

What is database drift?

You have probably experienced database drift, you just didn’t happen to refer to it as that. More likely you might have spluttered the following, perhaps sprinkled with a few expletives:

“Who put these tables in my database?”
“Who changed this view definition?”
“Why is this guy in db_owner?”
“Where has my stored procedure gone?”

In other words database drift can loosely be described as

stuff that appears, gets removed, or gets modified in your production databases that perhaps shouldn’t be

Detecting database drift using SSDT

If you’re using SSDT to manage your database schema then you probably consider the source code in your SSDT projects to be “the truth” and hence anything that appears in your databases that is not in your source code would be considered database drift.

In order to detect database drift using SSDT you must ensure that your database is registered as a Data-Tier Application. This can be done when you publish your database project (i.e. dacpac) by selecting “Register as a Data-tier Application”:

Thereafter you can check for database drift on subsequent publishes by selecting “Block publish when database has drifted from registered version”:

If you check that box and database drift has occurred then the publish operation will fail and you see an appropriate message in the Data Tools Operations pane, “Publish stopped. The target database has drifted from the registered version.”:

Clicking the View Report hyperlink displays the Drift Report which is represented in an XML file:

<?xml version="1.0" encoding="utf-8"?>
<DriftReport xmlns="http://schemas.microsoft.com/sqlserver/dac/DriftReport/2012/02">
  <Additions>
    <Object Name="[View_1]" Parent="[dbo]" Type="SqlView" />
    <ExtendedProperty HostName="[View_1]" HostParent="[dbo]" HostType="SqlView" Count="2" />
  </Additions>
  <Removals />
  <Modifications />
</DriftReport>

In this case a view called [dbo].[View_1] has been added to the target database. That view did not exist in the dacpac that was most recently deployed against the database thus the publish operation fails. Keeping one’s deployed databases as “clean” as possible is something that I am all in favour of so personally I think this is a pretty cool feature.

Generating a drift report from the command-line

The drift report can be generated by the command-line tool sqlpackage.exe. To do so you need to define:

the action to be DriftReport
a target server & database
an output file

>SqlPackage.exe /A:DriftReport /tsn:"(localdb)\Projects" /tdn:"Database1" /op:DriftReport.xml

As far as I know there is no support for generating a drift report from SQL Server Management Studio (SSMS). I’m hoping that changes so that this feature gets more visibility.

If you have any comments stick them in the comments section below!

@Jamiet

SSDT naming confusion cleared up. Somewhat.

jamiet — Wed, 03 Apr 2013 07:49:30 GMT

In March 2012 I published SSDT - What's in a name? where I lamented the mistakes that Microsoft made in the naming of SQL Server Data Tools.

…official documentation stating that SSDT includes all the stuff for building SSIS/SSAS/SSRS solutions (this is confirmed in the installer, remember) yet someone from Microsoft tells him "SSDT doesn't include any BIDs components".

I have been close to this for a long time (all the way through the CTPs) so I can kind of understand where the confusion stems from. To my understanding SSDT was originally the name of the database dev stuff but eventually that got expanded to include all of the dev tools - I guess not everyone in Microsoft got the memo.

Since then I’ve seen lots of questions pertaining to SSIS/SSAS/SSRS being posted on the SSDT forum on MSDN which, frankly, is the wrong place for them.

With the release of the SSIS/SSAS/SSRS project templates for Visual Studio 2012 Microsoft have attempted to clear up the confusion. Matt Masson from the SSIS product team attempts to explain in his usual jovial way:

note that the component was renamed – we added “Business Intelligence” to the end to distinguish it from the SQL Server Data Tools (Juneau). We now refer to it as SSDTBI, rather than “SSDT, no, not that one, the other one – you know, the one that comes with the SQL installation media, not the one you download”.
http://www.mattmasson.com/2013/04/installing-ssis-for-visual-studio-2012/

So to clarify, its now:

SSDT – for building databases
SSDTBI – for building SSIS/SSAS/SSRS solutions

Got it? Good!

That may all seem slightly confusing but its a darn sight clearer than it was SQL Server 2012 was released over a year ago. And if nothing else you have to be amused with Microsoft’s penchant for ever-lengthening acronyms, I can’t recall ever seeing a six-letter-acronym before, can you?

@Jamiet

Considerations when starting a new SSDT database project

jamiet — Thu, 21 Mar 2013 10:58:03 GMT

As you may have realised from much of my blogging over the past year or so I’m an advocate of using SSDT database projects for building database solutions on SQL Server. I have been using SSDT database projects a lot in that time and have come up with a checklist of things to consider when starting a new SSDT database project and I’ll be detailing that checklist below. I strongly advise you to consider making decisions about these items before you even write a scrap of code as invariably it will be more difficult to change later, especially if you have already deployed your database.

In no particular order here is my checklist:

Folder Structure

By default SSDT will not provide a folder structure for new projects in which to store all your script files so you might want to consider setting one up yourself. I recommend not trying to create a large hierarchy of folders to start with as this will evolve as you go about building your database. Here’s a simple starter for ten:

Filegroups

If you don’t understand the importance of filegroups then read Thomas Larock’s recent blog post DATABASE FILEGROUPS: JUST LIKE SEATBELTS BUT WITH LESS CHAFING. Quite often your organisation will stipulate policies for what filegroups you should be using and I highly recommend that you set up filegroups in your database projects to match those policies sooner rather than later. If your organisation does not have any such policies then perhaps think about defining them yourself, Thomas lists a few considerations that may influence your decisions:

separation of system data from user data
larger indexes may benefit from their own filegroup
archival of data can benefit from using dedicated filegroups as this will reduce backup maintenance tasks

If you follow my suggested folder structure above then put your filegroups into the “Storage” folder:

Above all, specify your default filegroup especially as many DBAs won’t be happy about you putting objects into the PRIMARY filegroup (which is the default). This is done by right-clicking on the project and selecting “Properties..” When there hit “Database Settings…” and set your default filegroup on the “Operational” tab:

If you intend to use the filestream feature of SQL Server then you can set the default filestream filegroup here too.

Collation

If you take only one piece of advice from this blog post make it this: set your collation before you write a single line of code (just trust me on this, OK). You’ll find this in Project Properties->Project Settings->Database Settings->Common

Again, find out if your organisation has any guidance on database collation.

Specify Target platform

SSDT allows you to deploy a project to SQL Server 2005, 2008, 2012 or Azure so it stands to reason that you should specify which you are intending to deploy to. You’ll find this in Project Properties->Project Settings:

Default Schema

If you follow the premise that “anything that SQL Server picks as the default is probably wrong” then you should probably think about changing the default schema which, by default, will be [dbo]. SSDT will create all new objects in the default schema (unless otherwise specified).

Generally I’m of the opinion that not accepting SQL Server’s defaults is a good idea if only because it forces you to think about these things and be aware of them; in the case of schemas it forces you to think about security and who should have GRANT or DENY permissions and on what.

Specify the default schema in Project properties->Project Settings:

Review other database settings

I’ve mentioned the most important database settings that you should look to change however you should also glance over the rest of the defaults that SSDT chooses for you to verify that they are valid for your project. Again, these are in Project Properties->Project Settings->Database Settings. a few I’d call out as being especially worthy of your attention are:

Auto update stats (on by default)
Recovery model (FULL by default)
Transaction Isolation (RCSI off by default)
Service broker (disabled by default)

Code Analysis

SSDT always checks the syntax of your database code, that’s one of the main justifications for using SSDT database projects. However what it does not do (not by default anyway) is check whether the code you write might be considered good code. That’s what Code Analysis is for, your code gets checked to see if it adheres to well-understood good practices for SQL Server database development. For example, Code Analysis will check for use of “SELECT*” which is generally regarded as a bad thing.

Code analysis is turned off by default. I recommend that you head into Project Properties->Code Analysis and turn it on. Moreover I recommend that you check all the boxes under “Treat Warning as Error” – this forces developers to address issues that get raised by Code Analysis.

Big Labels

Add a banner to your Pre-Deployment script as I describe in Big label generator. This may seem rather unnecessary but it takes about 30 seconds and believe me, at some point you’ll be glad you did!

The demo project that I took some of the above screenshots from is downloadable from http://sdrv.ms/ZW0gNt and might provide a useful template for your own SSDT database projects.

If you have any more suggestions for my checklist please add them to the comments below!

@Jamiet

Connected development in SSDT versus SSMS

jamiet — Tue, 19 Mar 2013 16:28:00 GMT

When you install the database projects template of SSDT you get SQL Server Object Explorer (SSOX) installed as well. SSOX is a pane within Visual Studio and is the main enabler of the Connected Development experience that the SSDT team have attempted to provide.

SSOX provides some really cool capabilities that are not in SQL Server Management Studio (I hope to blog about them in the near future). In theory these capabilities make it possible for a database developer to spend all their time in SSDT (i.e. Visual Studio) thus making SSMS a pureplay DBA tool (this does of course depend on your definition of both a database developer and a DBA, but I’m not getting into that debate here).

With that in mind I have spent a few days trying to work without SSMS, preferring to live wholly inside Visual Studio instead. By and large I was able to do everything I needed to do from within Visual Studio however there were a few nuances about the experience that kept pushing me back to SSMS, I detail those nuances below.

Server groups

SSOX combines the functions of SSMS’s Object Explorer and Registered Servers pane. I don’t mind either way of working but it does mean that there is no ability to group servers in SSOX like you can in the Registered Servers pane

F6

In SSMS I regularly use the F6 keyboard shortcut to jump between the query, results & messages panes of a query window. No such keyboard shortcut exists in SSDT and they’ve already canned my request on Connect to get this fixed (even though it laughably has status “closed as fixed”).

UPDATE: See the comments below where Brett Gerhardi informed me of a different keyboard shortcut that does the same thing as F6. Actually its not quite the same, if you have multiple resultsets in your results pane then the behaviour is slightly different to F6 in SSMS - but that's not an issue you'll hot frequently.

Change Connection

The context menu in SSMS provides the ability to change a connection as well as connect and disconnect:

SSDT doesn’t have change connection and believe me, you don’t know how much you use a feature until its not there:

There’s also no hotkey to jump to “Connection” on the context menu like there is in SSMS (“C”) and I find that annoying too.

Those were the main annoyances that forced me back to SSMS. The lack of F6 was a major bugbear for me as I am a big keyboard shortcut junkie. If such things don’t bother you then you may be able to live in Visual Studio quite happily. If you have any similar experiences to share I’d be keen to read them.

@Jamiet

Deployment of client-specific database code using SSDT

jamiet — Sun, 10 Mar 2013 13:24:00 GMT

Yesterday I attended SQL Saturday 194 in Exeter for which many people deserve credit but especially the organisers Jonathan Allen & Annette Allen and the sponsors Fusion-IO, Confio Software, Nexus, Big Bang Data Company, Purple Frog Systems, Redgate, idera, Pluralsight, Jurys Inn Exeter & Wrox.

I gave a talk entitled Declarative Database Development with SSDT; both during the session and then afterwards on Twitter Leo Pasta asked me

would you have any extra references on how to handle client-specific changes to the DB schema

I promised Leo an answer, hence this blog post.

If I understand Leo’s question correctly he has an application that is used by multiple clients, he has a separate instance of the application for every client, and the database requires client-specific customisations; luckily for Leo there is a new feature in SSDT that is perfect for this situation. First let’s set up our solution in SSDT:

We have three database projects:

_core - This contains all the objects that are common to all clients. For demonstration purposes it simply contains a table called [Sales]
clientFoo – All the objects that are required only by client “Foo”. In this case there is view which aggregates the data in [Sales] by Customer

clientBar – All the objects that are required only by client “Bar”. In this case there is view which aggregates the data in [Sales] by Location

In order that the reference to table [Sales] in the two views can be resolved both of the client-specific projects have a database reference to _core:

It is those database references that allows objects in clientFoo/clientBar to refer to objects in _core. Now here’s the important bit. When we set up those two database references we must specify that the objects in the referenced project are intended to be in the same database:

Having objects from one database split over multiple projects is called composite projects. The effect of this is that (by default) whenever clientFoo or clientBar are deployed the objects in _core will get deployed as well. We can see this in the output when we deploy clientFoo:

Notice how even though we chose not to deploy _core two objects have been created; table [Sales] (from the _core project) and view [vSalesPerCustomer]. This is the new feature in SSDT that I spoke of above – a deployment of a project will (by default) also deploy all the objects in referenced projects where objects in the referenced database are intended to be in the same database (incidentally this functionality replaces the “partial projects” feature from previous incarnations of SSDT).

Note that you can change this default behaviour in the advanced publish settings by unchecking the “Include composite objects” box:

Hence, with the “Include Composite Objects” setting turned on, we can deploy both projects clientFoo & clientBar and both will contain table [Sales] plus their own client-specific view:

which (I hope) is exactly what Leo was after!

That’s all there is to it. A very very nice new feature of SSDT!

@Jamiet

Which version of SSDT Database Projects do I have installed?

jamiet — Fri, 08 Feb 2013 21:15:52 GMT

SQL Server Data Tools (SSDT) is released on a very regular cadence (note that I’m talking about the database projects part of SSDT, this is nothing to do with SSIS/SSAS/SSRS). Since the first release in March 2012 there have been releases in September 2012, November 2012, & December 2012. I personally have found it difficult to keep track of not only which particular version I am using but also that which are my colleagues are using – quite simply I didn’t know how to discover the current version number. I assumed that the answer would lie within Visual Studio 2012 in the Help->About Microsoft Visual Studio menu option, when I checked there I saw this:

A version number – 11.1.21208.0. What does that mean though? To understand more we have to go to Add/Remove programs:

There are many different items listed there, let’s look at them in turn:

Microsoft SQL Server 2012 Data-Tier App Framework. This is fairly self-explanatory if you know what the Data-Tier App Framework (aka DACFx) is. If you don’t, see the notes at the end of this blog post*. The reason that you see two entries in the list above is due to my having the 32bit & 64bit versions installed – the fact that there is no differentiation between the two in the title is a bug.
Microsoft SQL Server 2012 Express LocalDB. LocalDB is the small server-less version of SQL Server that now gets deployed with SQL Server proper. LocalDB also gets installed with SSDT if you do not already have it, but you should consider it part of SQL Server itself.
Microsoft SQL Server Data Tools 2010. This was described to me as the “installation chainer” – it is the installation component that manages SSDT and its dependencies. I think of it as the SSDT shell within Visual Studio 2010.
Microsoft SQL Server Data Tools 2012. This was described to me as the “installation chainer” – it is the installation component that manages SSDT and its dependencies. I think of it as the SSDT shell within Visual Studio 2012. Note that the version number is the same as in the Help->About screenshot at the top of this article – that is because they are one and the same.
Microsoft SQL Server Data Tools – Database Projects – Web installer entry point. A stub project that gets installed when you install SQL Server. Its the SSDT database project entry point.
Microsoft SQL Server Data Tools – enu (10.3.21208.0) & Microsoft SQL Server Data Tools – enu (11.1.21208.0). These are the things we’re interested in. These *are* SSDT database projects, for Visual Studio 2010 & Visual Studio 2012 respectively. The version numbers are those for the December 2012 release; note that the build numbers are the same (X.X.21208.X), only the major and minor numbers are different.
Microsoft SQL Server Data Tools Build Utilities – enu (10.3.21208.0) & Microsoft SQL Server Data Tools Build Utilities – enu (11.1.21208.0). Everything you need to do a headless (i.e. without having Visual Studio installed) build/deploy of an SSDT database project.

So at the end of all that we have determined the following version numbers for SSDT database projects are:

Release	Visual Studio 2010 version number	Visual Studio 2012 version number
September 2012	10.3.20905.0	11.1.20905.0
November 2012	10.3.21101.1	11.1.21101.1
December 2012	10.3.21208.0	11.1.21208.0

I do not know the version numbers for the March 2012, September 2012 & November 2012 releases (if anyone out there does know please let me know in the comments) however I shall update this blog post for future releases. September 2012 and November 2012 releases now added!

I have requested that any blog post to announce future releases should contain the version numbers. Let’s hope that happens.

@Jamiet

* DACFx is described here as:

The Microsoft® SQL Server® 2012 Data-Tier Application Framework (DACFx) is a component which provides application lifecycle services for database development and management for Microsoft® SQL Server® and Windows Azure SQL Databases.
DacFX supports various database deployment and management scenarios for SQL Server and Windows Azure SQL Databases including extracting/exporting a live database to a DAC package, deploying a DAC package to a new or existing database, and migrating from on-premise SQL Server to Windows Azure. This functionality is exposed via the DACFx managed API. DACFx can target SQL Server 2005 SP4, 2008 SP1, 2008R2, 2012, and Windows Azure SQL Databases. DACFx also provides the command-line utility SqlPackage.exe for creating and deploying .dacpac and .bacpac packages. DACFx supports scenarios provided by SQL Server client tooling including SQL Server Data Tools and SQL Server Management Studio 2012.

Video accompanying my SSDT article is now available

jamiet — Mon, 28 Jan 2013 23:52:07 GMT

A couple of weeks ago in Get to Know SQL Server 2012's SQL Server Data Tools [article published] I stated that an article that I wrote about SSDT had been published and was available for reading online at http://www.devproconnections.com/. The article has since been updated to include a 10-minute video that I recorded demonstrating some of the basic concepts of SSDT so if you want to hear me drone on about SSDT in my dulcet Yorkshire brogue (!!!), click through, settle back and enjoy!

@Jamiet

Continuous deployment of SSDT database projects to Windows Azure using Team Foundation Service

jamiet — Sun, 27 Jan 2013 20:07:00 GMT

Continuous deployment is described by Wikipedia as:

Most CI systems allow the running of scripts after a build finishes. In most situations, it is possible to write a script to deploy the application to a live test server that everyone can look at. A further advance in this way of thinking is Continuous Deployment, which calls for the software to be deployed directly into production
http://en.wikipedia.org/wiki/Continuous_Integration

I think of Continuous Deployment as a natural extension of Continuous Integration where not only do we build the source code, we deploy it as well. As I continue to put together my SSDT Database Projects from the ground-up seminar it occurred to me that demonstrating Continuous Deployment for SSDT database projects would be very useful. It then occurred to me that the recently released Team Foundation Service (TFS) includes a facility to build source code so I wondered, could one perhaps use TFS to build an SSDT database project and deploy it to a Windows Azure SQL Database (aka SQL Azure)? It turns out that the answer is “yes” and this blog provides a step-by-step guide to doing just that.

Its worth noting that Team Foundation Service is free for up to five users. SSDT is also free. Windows Azure SQL Databases, however, are not free so you may have to pay a small amount to get one or alternatively adapt the steps herein to use Team Foundation Server to deploy to an on-premises SQL Server instance. Note that a MSDN subscription does include some small usage of Windows Azure SQL Database and that allowance will be more than enough to go through the steps herein.

We can break our process down into the following high-level steps:

Create a Windows Azure SQL Database
Sign up for Team Foundation Service (TFS)
Create an SSDT database project
Add the SSDT project to TFS Source Control
Setup your Publish Profile file
Create a Build Definition

Let’s dive into all of those steps.

Create a new Windows Azure SQL Database

Visit https://manage.windowsazure.com/ and sign up for a new Windows Azure SQL Database:

Your new database will be viewable in the portal immediately:

Windows Azure SQL Databases are, by default, closed to the outside world so you must edit the list of IP addresses that are allowed to access the server. Setting this up is outside the scope of this blog post however simply go to How to: Configure the Server-Level Firewall Settings (Windows Azure SQL Database) to learn how to do this (its very easy).

Sign up for Team Foundation Service

Visit https://tfs.visualstudio.com/ to sign up to use Team Foundation Service using your Microsoft Account (aka Windows Live ID). Once you have signed-up you will have a dedicated service URL (mine, for example, is https://jamiet.visualstudio.com/). Visit that URL and click “New Team Project”:

Fill in the pertinent details and hit “Create Project”:

Creating the Team Project will take a minute or so but will be ready for you when you need it shortly.

Create an SSDT database project

For this you’re going to need SSDT for Visual Studio 2010 or Visual Studio 2012. They are both free and can be downloaded from here; I am using SSDT for Visual Studio 2012.

You will need to create a new SQL Server Database Project:

Once the project is created it will appear in Solution Explorer and be empty at this point. We are going to be deploying to Windows Azure SQL Database therefore we must tell the project that that will be the case. To do that right-click on the project and select Properties:

In Project Settings select Windows Azure SQL Database as the Target platform:

You’ll need to add a database object to your project otherwise this is all rather pointless. Given that this is simply for demo purposes we shall simply create a table called [Table1].

OK, we now have a Windows Azure SQL Database, a TFS service (is that Team Foundation Service service???) and a SSDT database project with a simple table in it. Let’s now hook them all together.

Add the SSDT project to TFS Source Control

Interaction with TFS from within Visual Studio is done using the Team Explorer pane.

From Team Explorer you will need to connect to your new TFS. Click on the address bar in Team Explorer and point to “Connect to Team Projects…”

Choose your project and click Connect. Your server is simply the name of the server that was setup earlier; remember that mine was jamiet.visualstudio.com (note that it uses an https connection, not http):

You should now be connected to your Team Foundation Service. Add your source code to TFS Source Control from inside Solution Explorer:

And check in your SSDT database project (or “commit” if you prefer that terminology):

You will now be able to browse to your TFS home page (mine is https://jamiet.visualstudio.com), click on your project and browse through your checked in code:

Setup your Publish Profile file

You need to tell SSDT where to deploy the project to, that information is stored in a Publish Profile file. In Solution Explorer right-click and select “Publish…”

Enter the details of the Windows Azure SQL Database that you prepared earlier:

Once the Publish Profile file has been saved it will be saved in your project:

At the time of writing Windows Azure SQL Database only supports SQL authentication so we have to edit the Publish Profile file to include the password for the account that will be used for deployment. Right-click on the Publish Profile file, select “Open with…” and from the resultant dialog select “XML (Text) Editor:

Edit the Connection String to include your password:

NOW you can check in:

Create a Build Definition

A Build Definition defines how and when the source code in the project should get built. Create a new Build Definition by selecting “Builds” in the Team Explorer address bar and choosing New Build Definition:

Follow the steps shown in the screenshots below to setup your Build Definition:

(Credit for informing me about the MSBuild arguments goes entirely to Jakob Ehn and his blog post Deploying SSDT Projects with TFS Build)

And you’re done!

If you have set everything up correctly then any future check in should trigger a build and thus a Publish of the SSDT project to your Windows Azure SQL Database. Here is my first build report:

and back in SSDT I can use SQL Server Object Explorer to browse my newly deployed table:

That’s Continuous Deployment for SSDT projects to Windows Azure SQL Database using Team Foundation Service. Awesome!

@Jamiet

More SSDT naming confusion

jamiet — Wed, 16 Jan 2013 22:05:00 GMT

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.

@Jamiet

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.