One of the stated goals of Microsoft is that they make the plumbing easier for programmers. Rather than forcing us to build the intricate foundations, they provide tools like ADO.NET to make connecting to a database and manipulating/retrieving data a piece of cake.

Sometimes, however, you can encounter a problem that's beyond your ability to control because MS is being helpful.

I've got a very simple application. It's making a ADO.NET call to the database to execute a stored procedure. Occasionally, this times out. Now, you can tell me that the database was busy or there were blocking transactions or any number of other things, but I'll tell you the weren't happening. In fact, you could turn Profiler on and see the call being made from ADO.NET, see it taking an ungodly amount of disk reads and 30+ seconds.  Consistently for a set of parameters.

Now, while the web page is spinning and waiting for a timeout, run the exact set of code in Query Analyzer. Runs in milliseconds, the way it should .

Create a new procedure that is exactly the same in every detail EXCEPT that it has a different name and the web page calls it without a  hitch, running in that same sub-second time frame.

What's the difference? I haven't a clue. It's not something in the database because the SQL runs fine in Query Analyzer. It's not necessarily ADO.NET, because I can cut and paste the code into a new app and it runs without a problem. But for some reason the combination of SQL Server 2005, ADO.NET and that particular SQL call can and will timeout.