By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,364 Members | 1,391 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,364 IT Pros & Developers. It's quick & easy.

Is setting to Nothing really necessary if procedure is about to end?

P: n/a
MLH
I was wondering if setting object vars to Nothing near
the end of a sub procedure was beneficial at all - since
they (the OV's) are about to go out-a-scope anyway?

For example,
Sub MySub()
.... blah blah blah...
....
Set MyDB = Nothing
Set rstType17CorrespRecs = Nothing
Set qdfRRs = Nothing
Set rstRRs = Nothing

CheckITS10DayStandby_Exit:
Exit Sub

Will setting an OV to Nothing free memory that a procedure
ending won't free?
May 20 '06 #1
Share this Question
Share on Google+
10 Replies


P: n/a
> I was wondering if setting object vars to Nothing near the end of a
sub procedure was beneficial at all - since they (the OV's) are about
to go out-a-scope anyway?


This problem has begun a philosophical question during years :-)

Personally I'm used to esplicitly set to Nothing every variable that has
explicitly set to something before, and never got problem.
Other people say it's a waste of time, 'cause the garbage collector does
works well by itself.

It's up to you.

--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution
May 20 '06 #2

P: n/a
If software always worked perfectly, it would be a waste of time. In
practice, the universe does not work like that.

In Access 97, there were 2 bugs that meant you could not close the database.
When you tried, it would minimize to the task bar, but not close. You had to
use Ctrl+Alt+Del to shut it down. Ultimately, the 2 bugs were tracked down
to:
a) referring to a boolean control (check box, toggle button, option button)
without explicitly specifying its Value property, and
b) relying on Access to close recordsets and set the object variable to
nothing when it went out of scope.

In a large application, it was very hard to track down where you did these
things, so following these experiences, many of us decided it was worthwhile
doing our own garbage collection at the end of each routine.

Those bugs were fixed, but you will find some posts from users of Access
2000 and later who have seen Access unclosable. AFAICT, these are unrelated
bugs, possibly to do with classes that were not destroyed, or other hard to
track issues.

So basically, you decide whether to waste your time as you go, setting all
your objects to nothing, or whether you prefer to trust the software to do
it and then have a hellava time trying to it track down when the software
fails. I prefer the first of those two choices.

Nevertheless, at this very moment, I am trying to track down one of those
bugs in a utility I am developing. It opens another database, and lots of
recordsets into its own tables and the other database, and it is constantly
passing recordsets between procedures. If it all runs to completion, it
cleans up after itself and all is fine. However, if you set a breakpoint and
reset the code before it completes (Reset on the Run menu of the VBA
window), it does not get a chance to clean itself up, and any attempt to run
the routine again generates a concurrency error. It is a stark reminder that
even the most cautious practices can still leave you stuck if you expect the
software to do your cleaning up for you.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"MLH" <CR**@NorthState.net> wrote in message
news:6n********************************@4ax.com...
I was wondering if setting object vars to Nothing near
the end of a sub procedure was beneficial at all - since
they (the OV's) are about to go out-a-scope anyway?

For example,
Sub MySub()
... blah blah blah...
...
Set MyDB = Nothing
Set rstType17CorrespRecs = Nothing
Set qdfRRs = Nothing
Set rstRRs = Nothing

CheckITS10DayStandby_Exit:
Exit Sub

Will setting an OV to Nothing free memory that a procedure
ending won't free?

May 20 '06 #3

P: n/a
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:44***********************@per-qv1-newsreader-01.iinet.net.au:
In Access 97, there were 2 bugs that meant you could not close the
database. When you tried, it would minimize to the task bar, but
not close. You had to use Ctrl+Alt+Del to shut it down.
Ultimately, the 2 bugs were tracked down to:
a) referring to a boolean control (check box, toggle button,
option button) without explicitly specifying its Value property


Actually, that is one of the workarounds, not the source of the
problem.

The source of the problem was an implicitly created by reference
call that couldn't be destroyed. If you surrounded the Boolean
control call with parens to force evaluation, it would solve the
problem, too, because it was causing the value to be used rather
than a reference to the control.

This is actally another instance of the same problem, of references
not being released when code goes out of scope, and is a direct
result of VBA's reliance on reference counting for cleanup of
variables -- implicit references don't always get properly managed
in the code that keeps track of them.

Another example of where it's good to be explicit about this is in
any FOR/EACH loop that uses an object variable, such as:

For Each ctl In Me.Controls
...
Next
Set ctl = Nothing

For Each fld In rs.Fields
...
Next
Set fld = Nothing

And so forth.

I started doing this on MichKa's advice.

Lyle has frequently pointed out that the ADO libraries don't have
this problem with VBA, so you don't need to worry about cleaning up
your ADO object variables. However, were I to use ADO in VBA, I
would clean up, anyway, even though it's strictly speaking
unnecessary, simply because I think it's good practice to write code
that cleans up after itself even when the automated garbage
collection routines work reliably.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
May 21 '06 #4

P: n/a

MLH wrote:
I was wondering if setting object vars to Nothing near
the end of a sub procedure was beneficial at all - since
they (the OV's) are about to go out-a-scope anyway?

For example,
Sub MySub()
... blah blah blah...
...
Set MyDB = Nothing
Set rstType17CorrespRecs = Nothing
Set qdfRRs = Nothing
Set rstRRs = Nothing

CheckITS10DayStandby_Exit:
Exit Sub

Will setting an OV to Nothing free memory that a procedure
ending won't free?


Setting an objecting to Nothing is just a cleaner way to write code. As
colleagues mentioned, its upto you eventually when it comes at the end
of the procedure.

Chirag Shukla.

May 21 '06 #5

P: n/a
PBSoft,
COM uses reference counting to decide whether to destroy an object not
garbage collection; that is a feature of .NET languages.

OP,
IMO using scope to decrement the reference counter is poor programming, if
you create the object you should explicitly destroy it. There have been
numerous examples over the years of failure to do this causing problems.

--

Terry Kreft
"PBsoft" <in**@REMOVEpbsoft.it> wrote in message
news:87**************************@news.tin.it...
I was wondering if setting object vars to Nothing near the end of a
sub procedure was beneficial at all - since they (the OV's) are about
to go out-a-scope anyway?


This problem has begun a philosophical question during years :-)

Personally I'm used to esplicitly set to Nothing every variable that has
explicitly set to something before, and never got problem.
Other people say it's a waste of time, 'cause the garbage collector does
works well by itself.

It's up to you.

--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution

May 21 '06 #6

P: n/a
MLH
Thanks, Gabriele
May 23 '06 #7

P: n/a
If principle alone is enough to guide you then the answer is "Yes". By
explicitly setting to Nothing, you force the release of the memory used for
the object instance.

That alone is sufficient reason from one perspective.

Ideally, all objects instances would become released when they fall out of
scope (i.e., when you leave the subroutine or function in which the instance
variable is declared), but this is an imperfect world and it seems to me
that Access is vulnerable to what I think is called memory leak, in which
the bookkeeping is imperfectly done, so that memory is not necessarily freed
when you think it should be.

May 23 '06 #8

P: n/a
MLH
>In a large application, it was very hard to track down where you did these
things, so following these experiences, many of us decided it was worthwhile
doing our own garbage collection at the end of each routine.

Those bugs were fixed, but you will find some posts from users of Access
2000 and later who have seen Access unclosable. AFAICT, these are unrelated
bugs, possibly to do with classes that were not destroyed, or other hard to
track issues.

So basically, you decide whether to waste your time as you go, setting all
your objects to nothing, or whether you prefer to trust the software to do
it and then have a hellava time trying to it track down when the software
fails. I prefer the first of those two choices.


Very good advice, Allen, very good.
May 23 '06 #9

P: n/a
MLH
Good point, Rick. I'm inclined to agree.
I'll sweep my own laundry and wash my
own floors from now on.

One more silly point - regarding setting
any other variable types - is there any
equivalent sort of action required that
might plug leaks? I know the answer
is not setting them to Nothing - but I
do not know the answer. Say, for ex-
ample strMyStringVar and dblMyDbl?
Sorry if this is a ridiculous question.
May 24 '06 #10

P: n/a
> One more silly point - regarding setting
any other variable types - is there any
equivalent sort of action required that
might plug leaks? I know the answer
is not setting them to Nothing - but I
do not know the answer. Say, for ex-
ample strMyStringVar and dblMyDbl?
Sorry if this is a ridiculous question.


No. You have to give the right attention only to variables to which is assigned
a value via a "Set" instruction.

--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution
May 24 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.