rs.close and rs=nothing

[Microbe]

In a discussion recently the topic of trashing objects when you are finished with them came up.

This person was pretty adamant that after finishing with a recordset or setting any object that it should all clean up with

objectvar.close()
set (objectvar) = nothing

His argument was that if do something like this:

set rs= Server.CreateObject("ADODB.Recordset&quot
rs.ActiveConnection = MM_SQLSERVER_STRING
rs.Source = "SELECT * FROM reallybigdatabase"
rs.Open

and (say) 100 people do the same thing and all the objects are left hanging then the server performace will be degraded.

Makes sense and I am getting into the habit of closing and nuking the object, but I notice that Dreamweaver UltraDev doesn't do "set rs=nothing" after it creates the "rs.close()" code.

Not that they are perfect, but I would have thought it was something theyw ould do if it was important.

Any thoughts??????


Steve Davis
hey.you@hahaha.com.au

http://www.hahaha.com.au

 

[JohnYingling]

I heard that setting to Nothing started because on an old bug in DAO (not ADO) that caused a memory leak when a certain object was not set to Nothing explicitly. Theoretically, VB cleans up all objects when they go out of scope but it doesn't hurt to set to Nothing.

http://WWW.VBCompare.Com

 

[link9]

Setting it =nothing deallocates the memory that was/is associated with the object. So, even though the objects are stateless (they are supposed to be cleaned up after the page is finished loading), it's a good idea to set=nothing as soon as you are done using them on each page. On a high-traffic site, this will increase the performance of your applications as your number of users increases.

.close() does not deallocate the memory.

hope that clears it up a bit.
Paul Prewett

 

[JohnYingling]

Close at least frees any memory used by the Recordset.

http://WWW.VBCompare.Com

 

[Geee]

This argument has been going on for ages, but I would like to point out some problems I had.

After writing an Intranet application with a SQL backend, I decided to convert the app for use on the web. As my ISP didn't have SQL I decided to use Access as my backend for the internet version. I created the tables and the DSN, and the page worked OK sometimes, but sometimes produced errors. After much umm-ing and aah-ing I finally set all my objects to nothing after I was finished with them. Strangely this made the app work correctly 100% of the time. Since then I have always set my objects to nothing.

Gee -GTM Solutions, Home of USITE-
-=

http://www.gtmsolutions.com=-

 

[link9]

That's a truism of Access for sure. I have had the same problems in the past. For some reason, not setting a con and rs object = nothing leaves an Access database in a strange state for some unknown amount of time... sometimes.

That's what's so aggravating. Sometimes it doesn't, and sometimes it does.

Although this doesn't seem to be an issue with SQL Server (or other enterprise DBMS systems), it leaves me with the question about what extra load you are putting on the database engine to take care of cleaning up your trash for you. Because if ADO doesn't automatically take care of everything (and obviously, it doesn't), then the db is having to take care of it. So, if you are trying to build an application that will scale well (a good thing), then it's just always best to set=nothing. There are no logical arguments to the contrary.

And .close() does not free the memory used by a recordset... not all of it. The actual data may very well be gone, but the memory allocated for the object itself is still sitting there until you explicitly free it. And objects have alot more memory allocated to them than do normal variables to facilitate their library of functions. This is the main argument against using session scope objects -- and if you're leaving them lying around your pages, then you are doing the same thing (albeit on a smaller scale) as giving them session scope. (OK, I might be pushing it on that last one, but you get the idea)