Connection sub

Hvorfor lavet det i en sub ? Hvis det bare er for at have en include fil, kan du ligeså godt lave to filer dbopen.asp og db.close også have:

<%
Set Conn = ..
Conn.Open ..
%>

og i dbclose.asp
<%
Conn.close
Set Conn = nothing
%>

Så kan du bare inklude filerne i toppen og bunden af de sider hvor du skal bruge databasen.

Her er et eksempel på en funktion der returnere et RecordSet

Function MakeRecordset(strSQL)

Dim strConnect
strConnect = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
            "Data Source=c:\test.mdb;" & _
            "Persist Security Info=False"

Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open StrConnect

Dim RS
Set RS = objConn.Execute(strSQL)
       
Set MakeRecordset = RS

Set RS = Nothing
End Function

Og en sub der eksekvere en SQL streng

Sub ExecuteSQL(strSQL)

Dim strConnect
strConnect = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
            "Data Source=c:\test.mdb;" & _
            "Persist Security Info=False"

Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Mode = 3

objConn.Open StrConnect

objConn.Execute(strSQL)         
End Sub

Tja, det kan du selvfølgelig have ret i - det forekom mig bare mest fikst at inkludere een gang - og så have mulighed for at kalde sub'en flere gange.

Men principielt: Burde det virke?

Tja det burde faktisk virke med en Sub, variabler i en sub er nemlig ikke private.

Jeg er både enig og uenig med netsrac. Jeg er enig i det første forslag med include filer i toppen/bunden, sådan håndterer jeg også mine database forbindelser.

Men jeg er uenig i at variablerne ikke er private (lokale). Se eks. dette udsnit af VBScript dokumentationen:

A variable's scope is determined by where you declare it. When you declare a variable within a procedure, only code within that procedure can access or change the value of that variable. It has local scope and is called a procedure-level variable. If you declare a variable outside a procedure, you make it recognizable to all the procedures in your script. This is a script-level variable, and it has script-level scope.

P.S. Eneste ulempe ved den include metode netsrac foreslår er, at hvis du eks. anvender Interdev, kan du ikke anvende IntelliSense på dine database variabler når du koder (da de er erklæret i en anden fil).

tmceu >> men er der ikke en måde at få sub'en variabel-scope udvidet lidt - synes at have gjort noget i den stil engang...

Jo, du kan erklære variablerne uden for din sub og så initialisere dem inde i sub'en.

tmceu >> Ja det var lige en forglemmelse fra min side, hvis variablen er erklæret først, vil den kunne bruges i Sub. Så du kan erklære din variabler udenfor sub´en også vil det virke. Men ta dog og brug 2 filer istedet.

Hvis man skulle være en lille performance-rytter, ville det så i øvrigt ikke være bedst at vente så længe som muligt med at åbne sin conn? Og altså ikke inkludere filen øverst på siden, men derimod køre fx en sub lige før man skal bruge sit rs?

Oh happy days - en dim inden jeg kaldte sub'en gjorde underværker :)

netsrac >> du lyder overbevist ang. de to filer - er der andre fordele jeg ikke lige har tænkt over?

pollas >> Jeg har altid selv brugt de 2 filer, men der er vel ikke nogen fordel udover at du slipper for at tænke på om du har lukket database forbindelsen igen, fordi det jo sker i filen i bunden.

netsrac >> jeg har en close-sub også :)

pollas >> du har ganske ret. Det jeg præcist gør er, at jeg har en include fil i toppen, hvor connection, connectionstring og recordset er erklæret.

Når jeg så skal bruge det, laver jeg en open på hhv. connection og recordset.

Min closedb.asp includes i bunden, og for at gøre den generisk laver jeg et check på state og lukker hvis de er åbne.

Mange tak for svarene - jeg er blevet en del klogere :)

tmceu: Hvis du vil have lidt point, så lav et svar.

pollas >> Selvfølgelig har du en close sub også, men derfor er det stadig dig der skal huske at kalde den :)

Nu kan jeg hverken købe mælk eller betale huslejen med point, men siden du nu spørger...