What's new in SQL Server Yukon

Yukon is Microsoft's codename for the next version of SQL Server, due to be released in 2004.
Tim Anderson talks to Euan Garden, Microsoft's Product Unit Manager for SQL Server Tools.

Very good article ! and I was pleased to read that T-SQL is not dead !

Tim: Is T-SQL still being developed?

Euan: Absolutely. We're actually putting more investment into T-SQL in this release than we did in SQL 2000 and in some ways more than we did in 7.0. The key thing is choice. T-SQL is absolutely the right language to use for certain circumstances. In dataset based operations and relational type operations it will always beat out VB.Net or a C#, because they're having ultimately to call T-SQL to do a SELECT, UPDATE or INSERT, but through a programming API. Ultimately it all ends up in some form of T-SQL. T-SQL is still absolutely the best language, and we're adding structured exception handling in this release. In a lot of places in SQL 2000 you have to use magic stored procedures to do things. We're adding these to the T-SQL grammar, so it's just part of the SQL language now to do some of these things.

There are cases however where T-SQL is not as strong. A good example is integer or floating point type numeric calculations. One of those is crypto. Let's say you get data in from your customer with their credit card number, and you want to encrypt that before you store it in the database. Doing that in T-SQL is impossible. Today you would have to write an XP (Extended Stored Procedure) in C++. That's a challenging prospect. Also, the XP architecture in SQL Server is not as secure or robust as we'd like it to be. Now I can write that in VB.Net in 10 or 15 lines, using the Framework classes which are very powerful in this space. I can write a trigger to do it, or write a stored procedure. Or, if I wanted to, I could write an encrypted credit card data type and add it to my system. Then whenever you did an insert it would take in clear text and it would store in the database an encrypted version. The CLR programming environment allows us to do stored procedures, functions, triggers, user defined data types, and user defined aggregates. It's not just stored procedures.

Tim: So I could create a User-defined function in a CLR language and call it from T-SQL?

Euan: Absolutely. Even a CLR object has a little T-SQL stub around it, that presents the metadata correctly to the rest of the environment. For example I can CREATE PROC AS EXTERNAL as opposed to CREATE PROC AS with T-SQL in it. And in the EXTERNAL command we point at a class and a method name inside an assembly. There's a T-SQL stored procedure header, it uses T-SQL types, we've got nullable types, and we use all of that inside the stored procedure.

One of the demos with the Whidbey version of Visual Studio shows how you can set a breakpoint in T-SQL, plus a breakpoint in managed code. We have an example where we step from a trigger, which calls into a stored procedure which is in managed code, which calls into a function in T-SQL, which uses a data type which is written in managed code, and you can step through all of that in the debugger and it's totally seamless.