One of the bigger features of SQL Server 2005 is it's integration with the .NET platform. Now there is the ability to write your stored procs with a language like C#.
Now I'm just wondering how much of a good idea this is. Every scenario I try to go through still leads me to the same conclusion. This is, it may be handy for those really complex procedures that require some kind of funky processing or business logic or need to access the internet or a COM object or something. But for the most part, a loop is a loop, and an insert statement is still done in SQL, so I'm guessing that 90% of the stored procs required for a program are going to be in straight SQL.
When I originally heard about it, I imagined there was some 'magical' object relation with the data, but it turns out its just a bit of .NET code running on the SQL Server. Sounds much like Oracle's ability to run stored procs written in Java. Maybe the real scare factor here is it promotes the idea of generating sql from within C# code. To me, unless it's done right, there's no better way to clutter the source code and make the application hard to debug and maintain then having it "dynamically" generate its own sql code.
I can see the positives, but the potential negatives are riding right up there as well.