Developer .NET Perspectives
At this year's Professional Developers Conference (PDC), Microsoft shared many details about the future of its development products. One of those products is Yukon, the next release of Microsoft SQL Server. Like Whidbey (the next version of Visual Studio .NET), Yukon is a major release. It contains not only bug fixes and enhancements to existing capabilities but also major changes, such as the replacement of SQL Server Enterprise Manager with SQL Server Workbench, integration with the Windows .NET Framework, and enhancements in ADO.NET.
Enterprise Manager and SQL Server Workbench
One major change in Yukon is the elimination of Enterprise Manager, a tool for managing SQL Server instances. Microsoft will be rolling Enterprise Manager's capabilities into SQL Server Workbench, a common development environment for managing SQL Server databases. Developers will be able to use SQL Server Workbench or Visual Studio .NET to manage SQL Server instances. (Many developers don't realize that the majority of Enterprise Manager's capabilities are reproducible in Visual Studio .NET's Server Explorer. You can expect SQL Server Workbench to operate on a model that's similar to the one in Visual Studio .NET.)
In addition to SQL Server Workbench overcoming a few of Enterprise Manager's shortcomings (e.g., not letting you easily develop projects around a database), SQL Server Workbench will include new tools for managing XML and generating custom XQuery logic. SQL Server Workbench will also feature many new capabilities associated with Yukon's many changes. For example, SQL Server Workbench will integrate true user data types (UDTs) into the database. Implemented through XML, a UDT will no longer function as just an alias for one of SQL Server's built-in data types but instead will let you define a column that provides a unique storage structure. This ability to implement custom columns is at the heart of the native XML data-type column, which will be available in Yukon. Rather than creating two columns to represent a point, you'll define two integers and their relationship as part of an XML structure, then be able to apply this structure as a single indexable column within a table.
Integration with the Framework
Microsoft plans to host .NET technology within Yukon by having the Common Language Runtime (CLR) operate within an active SQL Server process. This nontrivial change puts several constraints on what embedded .NET code can do, in particular from the standpoint of security or in the event of a fatal error. Microsoft will need to change the .NET technology to support Yukon's .NET capabilities, so you can be assured that Microsoft will release these two products in conjunction with each other.
Fortunately, you don't need to be concerned with the internal .NET implementation details to leverage Yukon's .NET integration. All you need to know is when and how to take advantage of Yukon's .NET capabilities.
When should you use .NET capabilities within a database? If you're developing a function that will compute values, use .NET logic. If you're developing a function that will handle a subset of database queries and return a result set, keep your logic in T-SQL.
How do you use the .NET capabilities? From Visual Studio .NET, you'll be able to create Visual Basic .NET and Visual C# .NET database projects, which will define the equivalent of user-defined functions (UDFs) in SQL Server. This approach has two advantages. First, most application developers are more familiar with using these standard development languages than they are with using T-SQL. Second, procedural languages are much faster at processing calculations than T-SQL.
Enhancements in ADO.NET
Microsoft will be making several important enhancements to ADO.NET. A couple of these enhancements are worth mentioning because although they fall under the ADO.NET heading, they're tied to some extent to Yukon. The first of these enhancements is far better support for multiple simultaneous queries. SQL Server 2000 and earlier versions provide a "virtual" shared connection; however, the actual implementation requires separate connections for each recordset. With Yukon, this situation will change. ADO.NET will support true connection sharing for recordsets that you create using the same connection object.
You might have noticed my use of the term "recordset" rather than "dataset." That's not an error. With Yukon, ADO.NET will support a connected model that lets you maintain a connection to ensure that users don't modify the data they're viewing. In addition, with Yukon, ADO.NET will support several other connected models, including support for client-side cursors.
For many developers, the upcoming changes in Yukon are almost as important as the upcoming changes in Whidbey. In my next column, I'll introduce you to the changes in Whidbey.