After my last book, Essential ADO.NET, was handed in to the publisher ten days before .NET 1.0 shipped, I swore I'd never write another. To keep up with a technology while it was developing and the product features were being refined on an almost daily basis was too big an energy sink. Then, less than a year later, I caught wind of a new version of SQL Server, code-named Yukon. As with each version of SQL Server before it,since Microsoft's original 4.21 offering, there were lots of features for DBAs--high-availability features, tuning features, scalability features, andso on. A new, fast-growing field called business intelligence was being developed,and SQL Server was on the cusp of this. The features in this business intelligence area of Yukon were truly astounding. But the biggest changes that caught my eye were those in the developer area. I was hooked.

Transact-SQL has served us developers well all these years and continues to work quite well, thank you. This book lists the enhancements to this procedural dialect of SQL, and that chapter ended up to be much longer (because of the number of enhancements) than I originally thought. In the last few years, I'd been spending a lot of time in the XML space and done a lot of thinking about the differences and similarities between the XML and relational models. I liked the formal W3C standardization process for XML, slow as it seems at times. I started to investigate the ANSI SQL standards in earnest, though I'd read them before, and realized that SQL has a rich and deep foundation, starting with SQL-86 and up to the last mainstream standard, SQL-92, and past that to SQL:1999. But in 2002 there were specifications in progress to define how XML would be integrated into a relational database. There was a synergy with the XML work I'd been doing lately. I heard there would be XML functionality in Yukon, including an XML data type, XML schema validation, and an implementation of the emerging standard query language for XML, XQuery.

In addition, beginning with the object-oriented graphical user interface on the NeXT computer, I'd spent a lot of the last ten years using object-oriented techniques. And Yukon promised to integrate the .NET runtime into the database engine itself. Not that SQL Server internals were to be written in .NET, but that .NET would be directly accessible as a language for stored procedures and user-defined functions. I could use object-oriented programming techniques with my database programming as well. This might be a big assist to the procedural programming in T-SQL I was already doing, in those cases where I needed it. I'd read about using object-oriented languages in the ANSI SQL specifications. Finally, there was the rumor that .NET classes might be available in SQL Server as types that the server knew about. I'd read the ANSI spec for that too. I just had to see this product.

So we had been working on writing this book since late 2002 when I met with Eric Brown in Redmond, Washington, and we got the OK and the software. Since 2002 we'd badgered the SQL Server and Webdata teams with copious questions about not only how the software worked but why it was designed that way. They were very understanding about our persistence,but sometimes I felt that I was being a bit of a pest. When we started to teach the class in earnest, we tried to pay them back with information about how software vendors and others thought the features would be useful. At that time, Niels and I were writing, and Dan was reviewing and making suggestions; however, Dan got hooked too. We almost published in the beta 1 time frame, but held back. There were too many major enhancements to the way things actually worked, and we'd written about how things worked too early. Readers would think things worked the old way instead of the improved way. And there were more enhancements coming in beta 2. We held off writing and went for another revision. We were permitted, however, to write and teach a class to early adopters, based on the current state of our work and of the product. I think we've taught about 400 to 500 students as of this writing. The product evolved. More revisions. I'd told Mary that I was "almost done" so many times that she shook her head and laughed when I mentioned I might really be done again five minutes ago. It's certainly possible that some of the features or the implementation of them could change between now and when SQL Server 2005 ships. We'll try to keep you up to date with all the changes, update the book's code examples, and post some additional samples on the book's Web site. Look for pointers to the code and updates at the following locations:

• http://staff.develop.com/bobb
• http://www.danal.com
• http://staff.develop.com/nielsb

Yukon has all the stuff that I'd read about and more. At a SQL*PASS conference, I ran into Roger Wolter, a friend from the SQL Server team. We'd originally met when I was speaking at a Web Services conference on SQLXML Web Services in SQL Server 2000 Web Release 3. Little did I know that Roger, the "owner" of this feature, was in the audience. He said he liked the talk; I was relieved. When we met again at SQL*PASS, I asked Roger about Web Services in Yukon, and he told me about his latest project, called SQL Server Service Broker. It sounded to me like an implementation of a Web Service-like concept built over the robustness of a queuing system, built on top of the robustness of a database. Otherwise, his recollection of the meeting is about the same as mine. I was further intrigued.

So far I've mentioned Service Broker, Transact-SQL enhancements, security, .NET-based procedures, functions and user-defined types, built-in XML data type and queries, and Web Services. What else could there possibly be for developers? Most developers spend the greatest percentage of their time not in SQL Server Management Studio, but in Visual Studio 2005, writing the client front end. Many developers know the database engine and how to get the most out of it as well as race car drivers know how to get that last bit of speed out of their cars. Developers and application designers,as well as DBAs, must know how the new features work. In the case of snapshot isolation (versioning) or the XML data type, it could drastically affect how they design and write the application. With Service Broker, it opens a whole new raft of scalability choices that simply weren't there before. The last part of this book talks about client and application server features enabled either inside or outside SQL Server itself. The enabling technologies outside the database are ADO.NET's SqlClient and the client-side XML stack featuring its own XQuery engine. Client-side XQuery works against XML documents on the file system, against SQLServer, or both at the same time.

Finally, there are those developers who would rather not know that the database exists at all. They deal in objects and would just like to call "Load" and "Save" on their object model and have it taken care of. They're more interested in their business or application domain than in how to create a distributed partitioned view to spread the Customer table over multiple SQL Server instances. They see only Customer instances and collections. For these folks, ObjectSpaces and Microsoft Business Framework are what float their boat in this release. In addition to being able to persist their instances, they want "Load" and "Save" to take nanoseconds. ObjectSpaces was designed with optimization in mind.

In conclusion, I think there's quite a bit in Yukon for just about every developer, DBA, application designer, business analyst, and data miner. I've read in some trade publications that the new features just aren't that interesting; they're more like a recitation of glitzy acronyms than substance. This may be the initial perception, but let's rewind to mid-1981. I'm working for an insurance company in Seattle, and we're planning to convert our indexed file data, which we'd just converted from ISAM (indexed sequential access method) to VSAM (virtual storage access method), to a better, more robust database engine. The one we had in mind was IMS (IBM's Information Management System product). The salesperson, however, wants us to look at some new-fangled database they call SQL/DS (which eventually became DB2). After designing some tables and playing around with some queries, we asked some tough questions like "Why does it matter that a database engine is built on a mathematical theory?" and "Why would you want to learn a foreign query language called SQL rather than using nice, fast assembly language or COBOL programs?" and "Why did you just decompose our 2 nice, understandable records into 30 little tables just to join them back together again?" and "Why does it go so slow?" It was the beginning of the relational era. Relational engines weren't all that optimized yet, and smart programmers with fast disks could beat the engine every time. In 1981 we sent the product back, and I didn't learn SQL until 1987. By then I was a bit behind on the learning curve, but relational engines were a heck of a lot faster, and programmers wrote a little SQL and much less procedural code. And they got much more work done. So I smile when I see folks shake their head about the XML data models or the XQuery Formal Semantics. I saw the same raised eyebrows when mixing object-oriented concepts and data first came on the scene. Maybe the head-shakers are right, but I'm not waiting until 2010 to learn XQuery. It doesn't matter whether you choose to wait, however, or use relational exclusively. Yukon and .NET 2.0 have the enabling engines for all these data storage and query technologies--and more.