---

Hej igen,


Jeg har efterhånden set mange forskellige kode stiler, og derved mange måder
at løse et givet problem på. MEN: Der er noget der forvirre mig.

Hvornår skal jeg Obj.Close og Set Obj = Nothing

Har jeg ret hvis jeg siger at jeg skal
Obj.Close når jeg har skrevet Obj = CreateObject(...)?
Og at jeg efter Obj.Close skal Set Obj = Nothing ?

Og når jeg har brugt Set Obj = WhatEver skal jeg Set Obj = Nothing, og
ingen Obj.Close ?

---
Forvirringen opstod da jeg, her i NG, så
Set Rs = Conn.Execute("....")
...
...
...
Rs.Close
Set Rs = Nothing


Thomas

---

"Thomas L. Nielsen" wrote:
>
> Jeg har efterhånden set mange forskellige kode stiler, og derved
> mange måder at løse et givet problem på. MEN: Der er noget der
> forvirre mig.
>
> Hvornår skal jeg Obj.Close og Set Obj = Nothing

Close er jo ikke en generel methode, der findes på alle objekter, derfor
kan man ikke sige at du generelt skal benytte denne methode. Dit
eksempel er med ado's recordset-objekt. Her findes Close methoden og
skal benyttes til, at lukke recordset'et (dvs. sandsynligvis, at smide
interne buffere væk og anden oprydning). Close methoden skal på på
ado-objekterne (recordset, connection), når du er færdig med at benytte
en "åbent" recordset/connection. Du kan få en åben connection ved at
kalde Open og et åbent recordset ved f.eks. at kalde Open eller Execute
på connection objektet.

Set Obj = Nothing er anderledes, da denne er gennerel for vb-script. Du
sætter vaiablen til ingenting for at vb-scirpt kan se at du ikke bruger
objektet mere. Jeg vil tro, at vb-script benytter ref-count til at holde
styr på hukommelsen. Dvs. der til hvert objekt findes en tal, der
angiver hvormange variable, der har referencer til et givent objekt. Når
dette tal bliver 0 kan objektet ryddes op. Når du sætter en variabel til
ingenting sørger du for at vb-script husker at tælle tælleren ned. Så
det skal du gøre hver gang du har tildelt et objekt til en variabel.

--
Anders

---

Ok. Det vil så i teorien sige at i længden vil dette fylde min server
hukommelse pga. memory leaks ?
<%
Dim ....
Set Conn = Server.Createobject("ADODB.Connection")
Conn.Open "DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" &
Server.Mappath("mydb.mdb")& ";"
strSQL = "SELECT * FROM MyTable"
Set Rs = Conn.Execute(strSQL)
Do While NOT Rs.EOF
Response.Write("Var: " & Rs("VAR"))
Rs.MoveNext
Loop
Set Rs = Nothing 'Lukkes ikke helt ??
Conn.Close
Set Conn = Nothing
%>

Og tak for svaret, igenigen :)

Thomas

---

"Thomas L. Nielsen" wrote:
>
> Ok. Det vil så i teorien sige at i længden vil dette fylde min
> server hukommelse pga. memory leaks ?
> [Kode, hvor Rs tildeles et åbent recordset, som ikke lukkes]
> Set Rs = Nothing 'Lukkes ikke helt ??
> Conn.Close
> Set Conn = Nothing

Nu sagde jeg jo godt nok, at memory leaks hang sammen med et manglene
"Set rs=nothing" (og her er det rs.close, der mangler), mon jo, det
kunne man godt forestille sig. Men jeg tror nu ikke du direkte får
memory leaks (hvor hukommelse går tabt "for evigt"). Jeg tror blot at
vb-script fortolkeren er længere tid om at frigive hukommelsen.
I dette tilfælde hvor du ikke lukker recordset'et, tror jeg også der er
risiko for, at du belaster databasen. Når du på denne måde ikke siger
ordenligt "farvel" til den, så ved den ikke, at du er færdig med den og
holder måske nogle cursors åbne. Det kan du være, at når du lukker Conn,
som er den forbindelse, som recordset'et er åbnet igennem, så lukker den
også recordsette for dig.

OBS! Dette indlæg indeholder spekulationer, som måske har eller ikke har
rod i virkeligheden. Jeg har ikke lavet nogle tests eller undersøgelser
af komponeternes indre.
--
Anders

---

"Anders Holbøll" <dev-null-20010820@serveren.dk> skrev i en meddelelse
news:3B89444C.7B7E765C@serveren.dk...
> "Thomas L. Nielsen" wrote:
> >
> > Ok. Det vil så i teorien sige at i længden vil dette fylde min
> > server hukommelse pga. memory leaks ?
> > [Kode, hvor Rs tildeles et åbent recordset, som ikke lukkes]
> > Set Rs = Nothing 'Lukkes ikke helt ??
> > Conn.Close
> > Set Conn = Nothing
>
> Nu sagde jeg jo godt nok, at memory leaks hang sammen med et manglene
> "Set rs=nothing" (og her er det rs.close, der mangler), mon jo, det
> kunne man godt forestille sig. Men jeg tror nu ikke du direkte får
> memory leaks (hvor hukommelse går tabt "for evigt"). Jeg tror blot at
> vb-script fortolkeren er længere tid om at frigive hukommelsen.
Ja alt hukommelsen der er bundet til en session bliver vel frigivet ved
session timeout, eller ? rs er vel bundet til den session der har erklæret
den, ik.


--
Mvh
Anders Lund
webmaster@123grin.dk
---------------------------------------------------
Webmaster for GEnet.dk, Jyllands bedste netparty

---

Anders Lund wrote:
> Anders Holbøll wrote:
> > Nu sagde jeg jo godt nok, at memory leaks hang sammen med et
> > manglene "Set rs=nothing" (og her er det rs.close, der mangler),
> > mon jo, det kunne man godt forestille sig. Men jeg tror nu ikke
> > du direkte får memory leaks (hvor hukommelse går tabt "for
> > evigt"). Jeg tror blot at vb-script fortolkeren er længere tid
> > om at frigive hukommelsen.
>
> Ja alt hukommelsen der er bundet til en session bliver vel
> frigivet ved session timeout, eller ? rs er vel bundet til
> den session der har erklæret den, ik.

Jeg kan ikke se hvorfor det skulle have noget med session at gøre. De
ville jo så antyde at der bliver startet en scriptfortolker op hvor hver
session og det er ikke mit indtryk.

(Det skulle lige være hvis du lagde recordset eller connection ind i et
session-objekt, men det er jo ikke det vi snakker om her. Der er vel
heller ikke nogen som lægger den slags objekter i sessions, vel? Det er
en meget dårlig ide.)
--
Anders

---

"Anders Holbøll" <dev-null-20010820@serveren.dk> skrev i en meddelelse
news:3B89444C.7B7E765C@serveren.dk...
> "Thomas L. Nielsen" wrote:
> >
> > Ok. Det vil så i teorien sige at i længden vil dette fylde min
> > server hukommelse pga. memory leaks ?
> > [Kode, hvor Rs tildeles et åbent recordset, som ikke lukkes]
> > Set Rs = Nothing 'Lukkes ikke helt ??
> > Conn.Close
> > Set Conn = Nothing
>
> Nu sagde jeg jo godt nok, at memory leaks hang sammen med et manglene
> "Set rs=nothing" (og her er det rs.close, der mangler), mon jo, det
> kunne man godt forestille sig. Men jeg tror nu ikke du direkte får
> memory leaks (hvor hukommelse går tabt "for evigt"). Jeg tror blot at
> vb-script fortolkeren er længere tid om at frigive hukommelsen.

Yep, garbage collectoren sørger for at rydde objekterne op for dig, det
giver lidt bedre performance hvis du husker at frigive dine objekter
eksplicit med
Set objEkt = Nothing
Men det er ikke noget der spiller den store rolle for de fleste, det
vigtigst ved at sætte et objekt = Nothing er at man kan se i koden at nu er
man færdig med at bruge det objekt, det gør koden mere let-læselig når man
skal rette i den igen om 6 mnd.
En ældre version af MDAC (Microsoft Data Access Components) dvs. ADO havde
fejl i Garbage Collecteren. Fejlen gjorde at du fik fejl på din side hvis du
glemet at frigive dine ADO objekter med Set = Nothing, den fejl er dog
rettet for længst (jeg mener det var ADO 2.1 der havde problemet).

> I dette tilfælde hvor du ikke lukker recordset'et, tror jeg også der er
> risiko for, at du belaster databasen. Når du på denne måde ikke siger
> ordenligt "farvel" til den, så ved den ikke, at du er færdig med den og
> holder måske nogle cursors åbne. Det kan du være, at når du lukker Conn,
> som er den forbindelse, som recordset'et er åbnet igennem, så lukker den
> også recordsette for dig.

Ja, det er til gengæld noget der kan gøre en lidt større forskel for
performance, det er med at få lukket sine database forbindelser så hurtigt
som muligt. Den bedste strategi er at benytte clientside cursors, dvs.
forbindelsen til databasen lukkes med det samme. Da det ikke altid er
hensigtsmæssigt at benytte client side cursors er det i disse tilfælde
vigtigt at kalde .Close lige så snart du er færdig med at bruge dit
recordset.
Et af rådende i konklusionen på nedenstående suveræne artikel er: "Use
stateless database operations and always use disconnected recordsets."
<http://msdn.microsoft.com/library/en-us/dnnile/html/docu2kbench.asp>

MVH
Allan Ebdrup