In a two-part article over the next two months, I'm going to address an important issue for the SQL Server community: the future direction of coding for SQL Server, as directed by Microsoft. I'll start by telling you a bit about the current situation with writing code on and for SQL Server, and, in the next installment, talk more about the ramifications brought on by the current coding environment.

For many years, we've been able to write code on SQL Server using Transact-SQL. Transact-SQL is a bit of a hold-over from the days when Sybase and SQL Server shared a common code base. However, Microsoft has taken Transact-SQL in its own direction for many years now, providing new procedural features and abilities over standard ANSI SQL. If you were writing client code for SQL Server, then you could use any number of languages (VB, C/C++, C#, ASP.Net, etc.) or IDEs (Visual Studio, Delphi, PowerBuilder, et al). In SQL Server 2005, we were given the Common Language Runtime (CLR) to write stored procedures and user-defined functions in any .NET language, most commonly in C#. While the CLR provided performance advantages in certain specific scenarios, it was not widely adopted because most professional DBAs know Transact-SQL rather than.NET languages. Hence, DBAs often weren't willing to be held accountable for something on the server that was in a language they couldn't debug, troubleshoot, or maintain.

Now, there is a new wrinkle. There has been a lot of press about LINQ (Language Integrated Query---pronounced "link"), an element of Visual Studio, since it was released late last year. (You can find a lot of details about LINQ in such blogs as http://blog.aspiring-technology.com/ by Troy Magennis, and the ADO.NET team blog at http://blogs.msdn.com/adonet/ .) LINQ works on a number of various technologies, including objects, but, in this column, I'm talking about LINQ to SQL. LINQ to SQL (which I'll just refer to as LINQ from here on out) bridges the gap that exists today between the object-oriented programming model and the procedural, SQL-based data layer. LINQ provides a quick and easy way to navigate objects that typically have not been exposed to Visual Studio programmers.

Developers who connect their applications to the database using ADO.NET languages such as C# or VB.NET can allow LINQ to write most of their Transact-SQL code for them. This is a great boon to developers who feel out of their element when working with Transact-SQL. Consequently, Microsoft has worked hard to enable them to productively develop database applications without requiring a core competency in relational databases and, by extension, SQL.

Unfortunately, LINQ underperforms in many circumstances. In a nutshell, the Transact-SQL code it produced under the covers was anything but high-quality. However, the breathless marketing with which this and many other technologies are pushed upon the market had many people using LINQ inappropriately and, in some cases, necessitating a complete refactoring sans LINQ after the application tanked. (If you're a performance consultant, good times are ahead because you'll be getting lots of calls to rebuild all of these poorly performing LINQ applications.)

The good news is that the ADO.NET team seems to comprehend the failings of LINQ to SQL and, as reported at http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx , is shifting emphasis to the Entity Framework, thereby dead-ending LINQ to SQL. This brings me to a much larger and higher level question - why does Microsoft continue to launch major new development technologies in such a way that they practically are doomed to failure? I will address this question in the March installment of this column.