Set rsFoo = objConn.Execute("SELECT * FROM foo")
If rsFoo.EOF Then
...
Else
Response.Clear
Response.Redirect "start.asp"
End If
[b]rsLogin.Close : Set rsLogin = Nothing
objConn.Close : Set objConn = Nothing[/b]
Eller måste jag ha en stängning efter varje villkor?
Set rsFoo = objConn.Execute("SELECT * FROM foo")
If rsFoo.EOF Then
[b]rsLogin.Close : Set rsLogin = Nothing
objConn.Close : Set objConn = Nothing[/b]
Else
[b]rsLogin.Close : Set rsLogin = Nothing
objConn.Close : Set objConn = Nothing[/b]
Response.Clear
Response.Redirect "start.asp"
End If
Jag vet som sagt inte, men jag skulle nog vara beredd på att satsa ett inlägg eller två på att response.buffer spelar roll där, även om det verkar suspekt.
Jag har nämligen för mig att jag testat något liknande.
Response.Buffer = true gör ju att allt som ska skickas till läsaren buffras, och skickas i ett paket när sidan är färdigprocessad. Jag har svårt att tänka mig att den skulle innebära att script som inte ska köras verkligen körs.
DevGuru skrev:
The Redirect method stops processing the current script and attempts to connect the client to a different URL.
Jag vet inte jag, men jag brukar lita på DevGuru. Jag söker mer info. :)
Man kan ju alltid prova, om man har tid och ork, genom att slänga in någon annan kod efter en redirect, exempelvis kod som skriver till en tabell i en databas.
Om man har många samtida anslutningar på en sajt så kanske det är bäst att göra som du gör i det andra alternativet - sidan som exekveras kör några rader kod mindre. Annars tycker jag att du ska stänga anslutningen innan du skickar vidare användaren till start.asp.
Kort skrivet: det andra alternativet är att föredra.
Om du jagar prestanda och vill optimera så ska du heller inte plocka ut allt från databasen med *, utan välj de fält du har nytta av.
/r att döma av @nders senaste inlägg så ska man väl vara på den säkra sidan också om man inte vet - kör det andra alternativet till dess att du får bättre kod presenterad för dig.
You could also use Response.Buffer to prevent the Web server from returning the HTTP header before a script can modify the header. Certain properties and methods, such as Response.Expires and Response.Redirect, modify the HTTP header.
If the Buffer property in a script is set to TRUE without also calling the Flush method to immediately send buffered content to the browser, the server will maintain Keep-Alive requests made by the client. The benefit of writing scripts in this manner is that server performance is improved because the server does not have to create a new connection for each client request (assuming that the server, client, and any proxy servers all support Keep-Alive requests). However, a potential drawback to this approach is that buffering prevents the server's response from being sent to the user until the server has finished processing the entire script. For long or complicated scripts, users could experience long wait times before seeing the page.
Jag vet inte riktigt hur jag skall tolkat det där, det verkade lite luddigt. :l :)
Man skall tydligen använda server.transfer istället, om man vill göra på det sättet;
<HTML>
<BODY>
.
.
.
<%
If Request("CustomerStatus") = "" Then
Response.Clear
Server.Transfer("/CustomerInfo/Register.asp")
Else
Response.Write "Welcome back " & Request("FirstName") & "!"
.
.
.
End If
%>
</BODY>
</HTML>
Mmm. Server.Transfer är snabbare än Response.Redirect, men Response-metoden är mer använd än Server-metoden, troligtvis pga att det är så många som utvecklar på PWS och inte IIS.
Här kan jag smyga in lite info till: Server.Execute("sida.asp") är snabbare än <!--#include file="sida.asp"-->. Om man använder querystrings tillsammans med inkluderingar som exempelvis jag och Palleman har gjort, och kör med SSI, så inkluderas en massa filer om man kodat dumt.
