I have some reports that may take a long time (we're talking approximately 64k report pages long). And I'm not talking 64k pages of raw data from a stored procedure that returns millions of records. I have a couple of subreports that get repeated hundred of times. So on the report, I call a stored procedure that returns to me a thousand records, and for each record, I have a couple of subreports, which in turn, call their own stored procedures. So it's not that I have a ton of data (well, actually I do), but it's really the formatting of the report, that I put in page breaks at the end of each sub report, which causes the report to grow large...
So I have 2 questions:
1. I am running the reports from IIS, where the user requests the report via my ASP.NET web app. So when a user requests a report, I run the report in a separate thread and if that thread takes longer than XX seconds to report back to me, I notify the user that the report is running and that I'll email the user when it's done. So the IIS thread is running the report and it runs and runs. Approximately 2.5 hours later, the thread dies. Is there some IIS setting that I need to configure to let it run for like 12 hours instead I'm going to post this on the ASP.NET forum as well for help.
2. I read somewhere that reports are generated in memory. So when I am running a report and rendering this 64k page report to either PDF or Excel, the memory it takes is very large and is prone to a memory crash. Can someone give me more info about this Is running a 64k page PDF from SQL 2K RS a bad idea If it is, can you give me some reasons not to do it Is running a report that is in excess of 1k pages a horrible idea I'll need to make my case...
Thanks in advance

Running Long Reports
just another SSISy
Well, I wouldn't say it's "bad", but it is "unexpected" -- who is going to read those 64k pages
I imagine that what you are really doing is data transformation or archiving, not reporting, in which case I would say that PDF is an "unexpected" choice. Excel is less unexpected, but again, our intent was to output human-readable Excel files, not 64k page archives.
You might look into RS 2005 running on an X64 server -- you can pile on a prodigious amount of RAM and output some truly large reports.