Closing Recordsets

[James]

Quick question about closing recordsets and connection objects. We're in
the process of rewriting a TON of bad code. None of it is even remotely
tabbed properly, it's impossible to read half the time and it never closes
connection objects or recordsets. Unfortunately, I've been assigned the
task of closing them. I assume I'm just doing:

recordset.close
Set recordset = Nothing

conn.close
Set conn = Nothing

....whenever it's no longer needed. I guess that my question is, how do I
need to handle redirects within a page. Should I close/set to nothing
before a redirect, or by the page losing "focus", will these objects be
released anyway?

Are there any general rules of thumb that might save me some time going
through the 1,000,000+ lines of code?

Thanks!

[Bob Barrows [MVP]]

James wrote:

Quick question about closing recordsets and connection objects.
We're in the process of rewriting a TON of bad code. None of it is
even remotely tabbed properly, it's impossible to read half the time
and it never closes connection objects or recordsets. Unfortunately,
I've been assigned the task of closing them. I assume I'm just doing:

recordset.close
Set recordset = Nothing

conn.close
Set conn = Nothing

...whenever it's no longer needed. I guess that my question is, how
do I need to handle redirects within a page. Should I close/set to
nothing before a redirect,
Yes. Any code that appears after a redirect will not be executed.
or by the page losing "focus", will these
objects be released anyway?
Maybe. It's the times that they don't close automatically that cause the
memory leaks

Are there any general rules of thumb that might save me some time
going through the 1,000,000+ lines of code?

Close and destroy child objects (recordsets, command objects) before closing
and destroying parent objects (connections). Note: command objects can't be
closed, only destroyed.

Or, the "Things I learned in kindergarten" version:
if you open it, close it
if you create it, destroy it

Sorry, there's nothing i've said here that will save you any time.

Bob Barrows
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[Aaron [SQL Server MVP]]

> Sorry, there's nothing i've said here that will save you any time.

Not necessarily true. Going through the code now and cleaning it up, while
boring and monotonous, will save time and gray hair later when trying to
find the source of a memory leak...

A

[James]

Fair enough. We've had an issue where maybe once few days, the site is
horribly slow and basically needs to be rebooted. I have the distinct
feeling that this might solve that problem, as we've been unable to track it
down anywhere else.

"Aaron [SQL Server MVP]" <te*****@dnartreb.noraa> wrote in message
news:On**************@TK2MSFTNGP10.phx.gbl...

Sorry, there's nothing i've said here that will save you any time.
Not necessarily true. Going through the code now and cleaning it up,

while boring and monotonous, will save time and gray hair later when trying to
find the source of a memory leak...

A

[Bob Barrows [MVP]]

Aaron [SQL Server MVP] wrote:

Sorry, there's nothing i've said here that will save you any time.

Not necessarily true. Going through the code now and cleaning it up,
while boring and monotonous, will save time and gray hair later when
trying to find the source of a memory leak...

A

:-)
I meant clean-up time. Nothing I said provided any shortcuts to make this
task easier.

Bob
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.