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 is not returned to the calling page).
In both the cases, the URL in the browser remains the first page url (does’nt refresh to the new page URL) as the browser is’nt requested to do so.
Response.Redirect vs Server.Transfer
Server.Transfer or Response.Redirect both are the method of choice for transferring the user from one place in the application to another
Server.Transfer is similar in that it sends the user to another page with a statement such as Server.Transfer(“WebForm2.aspx”). However, the statement has a number of distinct advantages and disadvantages.
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the “focus” on the Web server and transfers the request. This means you don’t get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the “transfer” process can work on only those sites running on the server, you can’t use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
The other side debates that Server.Transfer is not user friendly because the page requested may not be the page that shows in the URL. Response.Redirect is more user-friendly, as the site visitor can bookmark the page that they are redirected to.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That’s not all: The Server.Transfer method also has a second parameter”preserveForm”. If you set this to True, using a statement such as Server.Transfer(“WebForm2.aspx”, True), the existing query string and any form variables will still be available to the page you are transferring to.
For example, if your WebForm1.aspx has a TextBox control called TextBox1 and you transferred to WebForm2.aspx with the preserveForm parameter set to True, you’d be able to retrieve the value of the original page TextBox control by referencing Request.Form(“TextBox1”).
1)Server.Transfer transfers page processing from one page directly to the next page without making a round-trip back to the client’s browser. This provides a faster response with a little less overhead on the server.
2) Server.Transfer does not update the clients url history list or current url.
1)Response.Redirect is used to redirect the user’s browser to another page or site. This performas a trip back to the client where the client’s browser is redirected to the new page.
2) The user’s browser history list is updated to reflect the new address.
Server.Transfer() is a member of HttpServerUtility Class that contains helper methods for processing web queries/requests. When we use Transfer() the current page will terminate and a new page will be processed instated of the old page. This processing takes place in the server and the browser will not be updated to show the new URL.
ViewState[“name”] = txtTest.Text;
Page obj= this.PreviousPage;
TextBox txtNewTest = (TextBox)obj.FindControl(“txtTest”);
string sDisplay = txtNewTest.Text.ToString();
Response.Redirect sends message to the browser saying it to move to some different page.
While server.transfer does not send any message to the browser but rather redirects the user
directly from the server itself. So in server.transfer there is no round trip while response.
redirect has a round trip and hence puts a load on server.