What three features of SQL Server 2005's new management tools are you most proud of?
I'm proud of many of the features and requests we've incorporated from customers. Our customers feel that we made significant advances with SQL Server 7.0 and 2000, and I'm confident that they'll be just as pleased with the new level of management tools in SQL Server 2005. If I have to get specific, I think I'm most proud of the new dialogs in SQL Server Management Studio, SQLCMD, and SQLiMail. I'm convinced that DBAs will love these tools. However, if you catch me on a different day, when I'm spending time with different aspects of the tools, I could easily give you three different favorites.
Is SQL Server Management Studio really Visual Studio (VS) in sheep's clothing? Will DBAs need to learn VS to be proficient with SQL Server administration, and will they need to license VS?
SQL Server Management Studio uses some pieces of VS, but it isn't VS. And DBAs won't need to install, learn, or license VS to be able to administer SQL Server.
What role does WMI play in the SQL Server 2005 tools world, and how does SQL Server Management Objects (SMO) map to WMI?
We added a WMI provider on top of SQL-DMO in SQL Server 2000. For SQL Server 2005, customers said they preferred the strongly typed, rich object model in SQL-DMO, so we're moving to a series of new management object models in managed code. These models, called Management Objects, come in three specializations: SQL Server Management Objects (SMO), Replication Management Objects (RMO), and Analysis Management Objects (AMO).
We've also added a new WMI provider for configuration. Customers who want to change service-account passwords, client-configuration properties, or other disconnected configuration information can do so through WMI. However, we've also wrapped this functionality in SMO to accommodate customers who want to use only one object model.
Why are you providing a single environment—SQL Server Management Studio—for all query types such as T-SQL and MDX?
We're providing a unified environment for T-SQL and MDX for a couple of reasons. The first is that we want to provide a consistent authoring experience. The second is that a lot of customers work in both languages. For example, if you want to build a data warehouse, you'll end up writing T-SQL scripts and MDX and maybe XML/A. We want to provide a single experience for that customer.
Does SQL Server 2005 provide better tools for debugging and managing source code?
Yes, the next release of SQL Server features a new debugger resulting from our collaboration with the Visual Studio team. And the authoring experience has source-control integration.