For many good reasons, DBAs and database developers use SQL Server Management Studio (SSMS), not SQL Server Data Tools (SSDT). It is a great relief for them, after several SQL Server releases-worth of general neglect, to see some renewed developmental vigor behind SSMS. Until the approach of SQL Server 2016, DBAs could have been forgiven for thinking that SSMS was on the ‘care pathway’, being ‘sun-setted’ with ‘nil by mouth’, and that their special requirements weren’t being considered.

Numerous improvements have now been forthcoming, from improved support for managing new SQL 2016 features such as stretch database and Always Encrypted, to live query statistics in execution plans so we can see the live progress of a query, to general prettifications such as the availability of new themes.

Perhaps more significantly, the whole code base has been overhauled. It now uses the Visual Studio 2015 shell. No longer is .NET framework a prerequisite for installation, so we can install SSMS easily on a SQL Server-free client. The goal is to have all SQL client tools ‘decoupled’, with zero shared components between the SQL Server engine and clients such as SSMS, SMO, and SQL-PS. It means that here will be no more SSMS updates in SQL Server SPs or CUs and that SSMS will be developed as a standalone tool and subject to frequent improvements and fast release cycles. You can even visit the engineering team’s SSMS Trello board to request improvements, and see their current priorities!

It’s all good news, right? Almost. These changes should mean that, longer term, it will be easier for the team to make sure that SSMS keeps up with new features across all the divergent implementations of SQL Server. However, decoupling can mean both being ahead of, and behind, the release of the RDBMS, and a major new version of the engine, Azure SQL Data Warehouse (ASDW), is about to be released without support for SSMS.

You can connect to ASDW through SSMS, but DBAs who tried found that it wasn’t pretty; they were confronted with NO COUNT errors, and tables that didn’t display properly. The responses on the various forums generally express surprise that someone would try to use SSMS, and that it’s much easier to use SSDT. So, while support is supposedly coming ‘as soon as possible’, the DBAs who comprise a major part of the initial users of ASDW will be forced to temporarily go the SSDT route. It is fair to say that ASDW has considerable differences to both the Azure and on premise SQL Servers, but the release of ASDW isn’t an entirely unexpected event.

How many DBAs or database developers among you have already switched to SSDT, regardless of the relatively bright future of SSMS? Surely, there are also good reasons why many would never want to abandon SSMS for SSDT?