Time out period not elapsed, but still timing out (see code)?

Question

OK I keep getting this error after about 3-4 minutes of churning:

 Timeout expired.  The timeout period elapsed prior to completion of the operation or the s         


        

Answer 1

This is an example of an extremely bad re-use of code. Instead of reusing the stored proc which makes you loop through all input variables you want, write a new set-based proc that selects the information based on joins. It will be much faster (assuming you have properly indexed of course). In accessing databases, you do not want to do something through a loop or a cursor if a set-based alternative is possible.

Answer 2

It looks like the timeout is happening when you're running the sql stored procedure (Your exception is of type SqlException). You would need to increase the Timeout of your Sql Stored Procedure execution, but I don't think you can do that with the SqlHelper class.

You'll need to go with the SqlCommand class, and set the timeout there.

Answer 3

There are five different timeouts you have to know about when talking to a database from an asp.net page:

1. The database connection timeout Set on your SQLConnection object, possibly via the connection string.
2. The database command timeout Set on your SQLCommand object.
3. The ASP.Net Script Timeout Set on your page via Server.ScriptTimeout.
4. Other IIS timeouts Imposed on your page by IIS. See this link: http://msdn.microsoft.com/en-us/library/ms525386.aspx?ppud=4
5. The internet browser timeout The browser/client will only wait so long. You don't control this so there's no point worrying about it, but you should still know it exists.

Make sure you check the first 4 I listed.

Normally I'd also say something to the effect that 3+ minutes is way to long to wait for a page to load. You might have enough data to justify the query time, but if so that's too much data for a user to really evaluate in one page. Consider breaking it up. But in this case it sounds like you're building a 'report' that needs to be run infrequently. While I still question the merits of such reports (it's just too much data to go through by hand — dump it into a fact table or somewhere similar for additional data mining instead), I understand that businesses often want them anyway.

Also, looking at your code I can see where you might be able to write that all as one big query instead of a bunch of little ones. That would be a lot more efficient for the database at the expense of some additionally complexity in assembling your results, but the result will run much faster. But for something that doesn't run often, when you already have the stored procedures built to do it this way, you may not be able to justify re-writing things.

So I'll give you a pass on the long-running page... this time.