I don't think the CLR is particularly necessary for SQL Server, but it's nothing to be afraid of, either. Joe seems to think that programmers do whatever they want to fulfil the customer need (unless they're too busy playing with cool stuff).

If that's the way we run our development teams, then fine. Perhaps if you do that then you let your accounts staff use any old transaction type they like to get the books to balance, and sales staff can bribe on expenses, etc. But any sensible company is aware of standards and uses them. This is to make sure the code that goes live is going to work and be maintainable.

Sure, with the CLR you can use any language you like, and there are many. But any company that allows more than one or two is probably going to make a mess. My team uses VB, and we allow C# too from time to time for simple stuff as the VB guys can work with this. But everything is reviewed by senior developers and nothing which will not be maintainable is allowed through. It was the same with DTS, and is the same with more standard features like views, UDFs, trigger and stored procs. It's possible to write a terrible system with ANSI SQL (and I've seen a few).

Joe needs to remember that there are many ways to do most IT tasks. Some are better than others, but most designs are compromises. Being offered another tool is not an attack on software quality. Some things are hard to do in SQL. Sometimes this is because the developer is ignorant. Sometimes this is because the database design doesn't sit easily with the new feature or report we have been asked to produce, because when we did the design, we didn't know the customer would ask for such a thing. Therefore sometimes there are things that it is hard to do in a set-based way.

We all have to compromise between many things. Cost, design elegance, reliability, performance, maintainability, cool, etc. In a real world system, different compromises will be needed for different parts, and at different times. If I had a GBP for every time a theoretician had assumed that we know everything about an app before we design or write any of it, I'd have, well, enough for a few beers anyway. Hence, an extra way of doing things which adds so much is very welcome, but I will have to decide how it should be used and developers should expect not to be allowed to do just what they like. One day it may give me a way to do a project quickly which makes that project viable.

Bill.