Its true, the reasons the blog lists for using stored procedures are valid.

However, we still find them to be very useful at my company. When you have to verify security or determine what objects are in use or affected by a change procs give you a leg up.

first post from Chrome!

I guess after years and years of being behind and getting useless features they were due.

Consolas for the win!

Crashed within minutes of first use on both my XP and Vista machines :(

I'm not a MS hater by any means, but the beta is still very, very BETA. On both my XP and Vista machines it crashed within minutes of the first attempt to use it. Overall installation time for me was about 10 mins before I dropped back to IE7.

Consolas for life!

I agree that you should favor an ORM when possible and use procs when speedy or complexity become an issue. Stored procedures are a necessary evil. Using them for every single CRUD operation on the database is folly, especially since a good ORM will use parameterized SQL which prevents injection attacks and will be cached up by SQL Server, exactly the same way a proc would be.

Code re-use is also a myth. In large enterprise applications the chances that developer A will find a proc written by developer B that does exactly what he wants it to is slim, and thats if he even bothers searching at all.

I've been using SubSonic for my latest project and its been a tremendous advantage, especially the strongly typed SP collection is generates for when you do need to call a proc.

I've used NHibernate as well, but only in a very limited capacity. It seems like the best fit for an enterprise environment since you can call procs when you need to and you can map your database to business entities with no external dependances, vs. something like SubSonic where you end up with references to SubSonic.dll everywhere.