Hi, I have a web page that I plan on calling automatically around 2 AM that will perform some database housekeeping. Currently, the task runs fine on my local machine while connecting to my DASP SQL account. It takes 30+ minutes because of the remote database traffic, but the dev environment doesn't mind, and the browser window waits patiently the entire time. When deployed, I estimate it will take 3-4 minutes each night. When I move to DASP IIS, I get a 'thread abort' exception. Commonly this can come from a redir, but I'm not doing that. Instead, at about 90-120 seconds the exception shows up, and my code doesn't have a chance to catch it. Studying this, it appears this is a timer to ensure things don't run forever, which is good. I can change it with an <httpRuntime executionTimeout = '1000'/>, for example, in the web.config. For the timer to work, Debug must be set to false. When I set the timeout to 10 seconds, indeed the thread abort exception fires in 10-25 seconds (the timer has 15 second granularity). So my change is recognized. However, when I set it to 1000 seconds, I still am getting the thread abort exception around 90-120 seconds. Any ideas??
So if somebody wants to do a 2 AM maint on the database that is kicked off from an a scheduled http request, and if it takes more than 90-110 seconds they are out of luck? How are others doing this? The worst part is that it's not clear that the page can even detect this?
