Navigation:  Articles > May-2003 >

Looking at .NET with T-SQL

Previous pageReturn to chapter overviewNext page

Peter Vogel        

Mary Chipman, who’s probably forgotten more about SQL Server than I can ever hope to know, wanted to make sure that we send the right message about the future of T-SQL. As Russell Sinclair observed in his article on SQL Server triggers in the January 2003 issue, the next release of SQL Server (and don’t expect it before mid-2004) will no longer limit developers to T-SQL for stored procedures: Any .NET language will work.


As Mary has pointed out, that doesn’t mean that T-SQL is being relegated to the junk heap. In fact, the language is expected to see some significant enhancements. If you’re really concerned about performance, when you start writing stored procedures in a .NET language (likely Visual Basic .NET, if you’re an Access developer), you should probably write your pure data access code in T-SQL. You’ll use VB.NET for the procedural code that wraps around your data access statements.

For experienced Access developers, this is almost “business as usual.” Developers who have been concerned about getting the most out of Access have always combined SQL with VBA. One way to look at this change is that, with the next release of SQL Server, Access developers building Access Data Projects will gain access to an enhanced version of SQL in T-SQL. The little work that I’ve done in T-SQL hasn’t given me much appreciation for T-SQL as a procedural language. However, I’ve often found that the extensions to the SQL data access language that are part of T-SQL have made solving problems significantly easier.

In a recent interview with Eric Rudder (Senior Vice President of Developer and Platform Evangelism at Microsoft) in Visual Studio Magazine, Rudder spoke about .NET language support in SQL Server:

“ does mean that developers will be able to write stored procedures using their language of choice. What’s the advantage of that? Well, for one, it’s the language of your choice. It’s all about leverage. My VB is a little better than my T-SQL. And so, you’ll be able to leverage what you know. It’s just another tool for developers to take advantage of. If you like using T-SQL, you can continue to do so. It also means you’ll get a better development experience overall. You’ll get better debugging for your stored procedure. You’ll also be ableto take advantage of better source code control. VS.NET’s integration with SQL Server is going to pay off in several areas that will make development easier and more productive.”

Which brings me around to .NET. As you may be aware, I’ve written some courses for Learning Tree International, a global training company. One of those courses is on ASP.NET, and lately we’ve had quite a long discussion about what language to use in the course: VB.NET or C#. All the measures that we have access to suggest that the number of VB programmers is vastly greater than the number of C# programmers. While the number of C# programmers is increasing, it seems to us that most of the C# developers come from the ranks of migrating C, C+, and Java programmers. Overall, Visual Basic programmers seem to be finding VB.NET a good place to go. My feeling (and I’ve heard several other developers say the same thing) is that once you start working in .NET it’s hard to go back to the COM environment.

The question we’ve been discussing is whether we should support C# along with Visual Basic .NET in the course. Some people have suggested that, since Learning Tree offers a course on Web Services in Java and another one for .NET, we should have two courses on ASP.NET: one in C# and one in Visual Basic .NET. However, this misses the point. Java provides a completely different set of objects and way of doing things to programmers who might be moving from the world of Microsoft tools. All of the .NET languages provide access to the same development environment. For example, there were form controls that I use in Visual Basic that I would love to use in Access—but I couldn’t because those controls wouldn’t work on an Access form. In the .NET environment it will be a very unusual resource that won’t be available to you in whatever environment you’re working in.

And, to echo Eric Rudder, that’s one of the major benefits we’ll gain from .NET when .NET comes to Access: choice. That’s a curse and a blessing, of course. The good news is that the toolkit available to you will get much bigger. The bad news is that the toolkit available to you will get much bigger. If the idea of learning something new depresses you—well, we’ll be here to help.