We have a painfully slow report.I added a Response.flush and it seems a great deal better. What are some of the caveats of using this method.
If Response.Buffer is not set to true, then you'll get a run-time error. Also, If the Flush method is called on an ASP page, the server does not honor Keep-Alive requests for that page.
You'll also want to look out if you're using a table-based design as it won't render in some browsers until the entire table is sent.. meaning if you have 10,000 rows, the user would still need to wait for all 10,000 rows to transfer before they'd actually see them.
Also, if anything you do needs to set Response.Headers, you can't do it after any part of the Response has been Flushed.
Response.flush could be useful to send to the browser the report's header.. then display a "loading message", then your report process and you flush the report, then execute a little piece of javascript to hide the "loading" message.
This way you will let your users know that something is hapenning so they won't press STOP BACK or just close the window as they may otherwise be tempted.
Also, I've played a lot with what browser render what table and IE seems to be the only one that doesn't render a table unless the tag is received. Which means that all rows could gradually appears in other browser but not in IE.
There are no problems with flushing the response like this. It is generally recommended for better performance to buffer the entire page and the flush it to the client but for long running scripts it is often better to display some data to the client so the user sees something is happening.
Do remember that flushing manually only have a proper effect when buffering the page from the start, otherwise IIS will flush automatically (stream the page to the client).
You should avoid flushing to often as IIS will then have to use resources on flushing the page often instead of processing the script. I.e.: flush every 50 rows instead of ever row.