In my June 28 commentary, I asked you to tell me about the most significant things you learned about SQL Server at the Microsoft TechEd 2001 conference. I also promised to share my thoughts. Interestingly, most people who responded focused on a SQL Server feature that probably won't be available in a commercial release for at least 18 months.

During the show's opening keynote, Microsoft Senior Vice President Paul Flessner, who's in charge of the .NET Enterprise Server Division, captivated SQL Server professionals with a demo of Yukon. The demo highlighted Yukon's ability to run stored procedures written in native Microsoft .NET languages such as C#. For those of you too busy to keep up with releases that are more than a year away, Yukon is the code name for the next major release of SQL Server, tentatively planned for release in late 2002 or early 2003.

One of Yukon's most significant enhancements will be its ability to run stored procedures written in any .NET language. Although this capability will extend SQL Server's programmability, I have mixed feelings about it. On the positive side, .NET stored procedures will open up a new realm of application architecture and deployment options. On the negative side, .NET stored procedures will make it much easier for developers to build and roll out poorly architected database solutions. The problem isn't the powerful new technology but what we'll do with it. I'm worried about putting a power saw in the hands of someone who has a hard time operating scissors.

If you're a regular reader of this column, you know I often discuss training—or the lack thereof—in the SQL Server community. My comments aren't meant to slam database professionals who are simply overwhelmed and can't possibly know everything. I'm the first to admit that my own database skills are deep in certain areas and more shallow than I'd like in many other areas. Unfortunately, today's technology makes it easy to build poorly architected solutions. Why? Like it or not, no one can be an "expert" in everything involved in building complex, end-to-end applications. And letting developers create .NET-based stored procedures takes this problem to a new and unprecedented level of danger.

The fact that most nondatabase-savvy developers don't know T-SQL has created a barrier that prevents many of them from working with the database server. .NET-based procedures remove this barrier, allowing almost anyone to create inefficient code that will run inside SQL Server. Developers have always been able to create bloated, inefficient data-access code. But nearly all that code runs on a separate physical server because most people are sane enough to install application code and SQL Server on separate boxes. Letting developers write inefficient data-access code that runs inside the database engine will further compound the scalability and performance problems built in to many of today's systems. Making matters worse, the typical DBA will be clueless when it comes to debugging or troubleshooting .NET procedure code in SQL Server.

I know I've painted a picture of doom and gloom, but here's the bright side. First, .NET-based stored procedures will let us use SQL Server in new and interesting ways; after all, no one claims that T-SQL is a robust, common programming language. Second, the knowledge gap between .NET-only architects and SQL Server-only architects will create a lucrative niche market for the savvy database professionals who spend the next 18 months upgrading their skills for all things .NET.

Are you a DBA? Don't know Visual Basic (VB)? Been thinking you need to brush up on your development skills? I can't overstate the importance of learning .NET or at least its data-access portions. Sooner than you think, you'll be hard-pressed to see where .NET ends and the database begins. And if you're not careful, your T-SQL-only skills will land you in the same camp as the COBOL-only dinosaurs of yesterday.