Server.Transfer() Vs. Server.Execute()
Original at : Difference between Server.Transfer and Server.Execute
Both Server.Transfer and Server.Execute were introduced in Classic ASP 3.0 (and still work in ASP.NET).
When Server.Execute is used, a URL is passed to it as a parameter and the control moves to this new page. Execution of code happens on the new page. Once code execution gets over, the control returns to the initial page, just after where it was called. However, in the case of Server.Transfer, it works very much the same, the difference being the execution stops at the new page itself (means the control isn't returned to the calling page).
In both the cases, the URL in the browser remains the first page URL (doesn't refresh to the new page URL) as the browser isn't requested to do so.
I know this is old but it came up as the 1st or 2nd hit when I searched on google. I did some testing and wanted to post the results.
I created a website with 2 pages. Page Load on the 1st page contained the code..
try {
//Response.Redirect("~/WebForm2.aspx");
//Server.Transfer("~/WebForm2.aspx");
//Server.Execute("~/WebForm2.aspx");
//Server.TransferRequest("~/WebForm2.aspx");
string strTry = "Try";
} catch (Exception ) {
string strCatch = "Catch";
} finally {
string strFinally = "Finally";
}
The sequence of what it did for each is what was really interesting...
Command Sequence Redirect Call, Catch (ThreadAbortException), Finally, Load Page 2 Transfer Call, Load Page 2, Catch (ThreadAbortException), Finally Execute Call, Load Page 2, Try (continues), Finally TransferRequest Call, Try (continues), Finally, Load Page 2
.. So it may help to know what order you like things to occur in.
Personally I like the idea of the current code finishing, BEFORE the next page's code starts. So either Redirect or TransferRequest, although with the latter, you may have to add a "return" just below your call if you really intended for it not to execute the rest of the try block.