Response.Redirect after Response.Flush

Is there a way I can call Response.Redirect after I've done a
Response.Flush?
I send some html to load an animated gif that plays whilst my page loads,
it has some extensive database calls to process. However, when I try to
redirect to my error handling page, if there is an error, I get a 'Cannot
redirect after HTTP headers have been sent' error.
I've got round the problem by using a javascript function in the body
onload event that checks a hidden field whose value is set when an error
occurs, but this does not seem very elegant.
Any ideas?

Due to the stateless nature of the web, you can't actually make your server redirect a page on the client's machine.

Your workaround seems good enough. Any workaround though will seem crude.

Another way could be to allow the database calls to run Asynchronously and redirect to the second page anyways.

Quote:

---

Originally Posted by mendhak

Due to the stateless nature of the web, you can't actually make your server redirect a page on the client's machine.

---

I thought that was what Response.Redirect did.

[Edited](Checking something)

That's what I thought, but I just hoped there was some way of doing it server side because that's where the processing is taking place, so it seems logical to redirect from the actual code that recognises an error.
Thanks anyway.

Can you set Response.Buffer = true? THis is something I remember once from ASP 3.0. Set it right at the beginning of your code, then try what you were trying.

Quote:

---

Originally Posted by mendhak

Can you set Response.Buffer = true? THis is something I remember once from ASP 3.0. Set it right at the beginning of your code, then try what you were trying.

---

You have to set Response.Buffer = true, its the default actually, to call Response.Flush.
If Response.Buffer == false then Flush returns an error 'cos you can't flush something that's not there.

Seems you need a Meta-Refresh in the Http Headers sent to the client... set the refresh for 5 seconds.

When the page is requested, if the asynchronous db calls are done processing, then Redirect the client using Response.Redirect, else you re-serve the animated gif part.

Code:

---

Response.Write("<script language=javascript>window.navigate 'ErrorPage.aspx');</script>");
Response.Flush();

---

This does it with the server sending the client script that will execute straightaway.
Sort of server-side I suppose.

Quote:

---

Originally Posted by GlenW

I thought that was what Response.Redirect did.

---

Not once content has actually been sent down to the browser. (Response.Flush) Hence the error received. I've actually done processing things like that where I'll send down some content (animated GIF) and when the process completes, I send down some javascript that will hide the animated GIF and let the user know the process is complete.

Conceptually, not the most elegant solution, but I've got it working pretty tight.

Well, you could use an XmlHttp request on a javascript timer that will ask the server at certain intervals when the process has completed. But, if you have it tight, what's the point in changing it right?

Quote:

---

Originally Posted by nemaroller

Well, you could use an XmlHttp request on a javascript timer that will ask the server at certain intervals when the process has completed. But, if you have it tight, what's the point in changing it right?

---

That would work, but it would also force the user to need MSXML on their machine. I know it's pretty typical on Microsoft OSes these days, but I don't like having that dependency.

Another thing I've done (just recently in fact), create my page which has a button which kicks off the process and shows the status with an image (all client side). The button creates an IFRAME offscreen with javascript and tells it to navigate to another page which will actually start the process (server-side). When the process completes, the output of the page that started the process is nothing but a simple javascript call back to the original page. When the first page gets this call, it updates the image to let the user know the process is complete.

If a windows platform has IE5 or higher, they have MSXML, regardless of windows version. So your loss of audience would be the person that hasn't turned on their machine in 4 years.

Gecko-based browsers all have a compatible XMLHTTP object for various platforms (including the Windows platforms), even Apple's Safari has one.

The only stifling possibility is if a user has raised the default security settings in their browser - which normally deactivates many javascript functions as well, which is a dependency you require with the frame method - rendering just about every modern website useless.