Closing Recordsets

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!

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.

> 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

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]" <ten.xoc@dnartreb.noraa> wrote in message
news:Onad34cvEHA.1204@TK2MSFTNGP10.phx.gbl... 
>
> 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
>
>

Aaron [SQL Server MVP] wrote: 
>
> 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.