First Look: Denali's New SQL Server Developer Tools - Part 1

The new SQL Server Developer Tools (previously codenamed Juneau)  is designed to close the gap between relational database development and BI development. From my point of view the new Developer Tools is overdue. It never did make sense to me why I needed to do T-SQL development using SSMS but when I wanted to use Reporting Services or Integration Services I needed to use BIDS – this was especially annoying because you knew that both SSMS and BIDS were both built on top of the Visual Studio shell. A recent project that I’ve been working on really pointed out this problem. While working on an ASP.NET application I needed to have Visual Studio 2010 open for working on the web application, SSMS open for developing the T-SQL stored procedures and database schema, and BIDS open for developing the Reporting Services reports used by the application. Then I spent a good deal of time tabbing between the different environments. You might point out that I could have done my T-SQL development in Visual Studio but I’ve never liked Visual Studio for T-SQL development. There are little problems like the data types not being displayed in the explorer dialog but the main issue is a lack of visibility into the SQL Server instance.

SQL Server 2012's (formerly code-named Denali) new SQL Server Development Tools is supposed to solve a good chuck of these problems by combing the relational and T-SQL development capabilities from SSMS with the BI development features in BIDS.  Don’t worry both SSMS and BIDS are still present in Denali – at least as far as CTP3 goes. However, BIDS may be dropped from the final release.

My experiences with SQL Server Developer Tools were a bit disappointing. The SQL Server Developer Tools are not part of the CTP3 package itself. Instead, you have to download and install them using the slow and failure prone Web Platform Installer.  The Web Platform Installer, which failed three times during the excruciatingly slow download and installation process, is a great example of how change doesn’t always equate to progress. Downloading and installing an EXE or MSI file would have been 10x times faster and I would have only had to do it once. 

You have the choice of installing SSDT into Visual Studio 2010 with SP1 or as a standalone tool. I opted to install it standalone. If you install it into Visual Studio, it acts like LightSwitch and it adds the BI project types in the Visual Studio shell. Standalone you still can not use it to develop SQLCLR projects. You still need Visual Studio for that.

After finally getting the SSDT installed I didn’t find it under the SQL Server Denali CTP3 Start menu options like you might expect for a SQL Server tool. Instead, it was confusingly installed un the Microsoft Visual Studio 2010 menu option. You can see the new SQL Server Developer Tools IDE shown in the following figure.

From a relational T-SQL point-of-view I found SSDT a bit better than Visual Studio. The Server Explorer is more capable – but not as capable as the one in SSMS.  You can see multiple databases and the Server Explorer allows you to work with server level objects like logins  But you still can’t do everything. For instance, the first thing I wanted to do was attach some databases and I needed SSMS for that. From a BI standpoint I found it almost identical to BIDS with the Schema Comparison option thrown in. 

Next time I’ll tell you about my experiences attempting to use SSDT to replace my tried and true SSMS, VS2010, BIDS combo for application development (see, "The Case to Upgrade to SQL Server Denali").