Much Ado About (Set =) Nothing

[Tris]

Using Access 2003/DAO
When I first learnt to do VBA in Access from books and onscreen help, there
was no reference to 'clean up', only to the need to close recordsets etc at
the end of subs or functions. Now, when I use this forum or other online
sources I am seeing things like 'Set db = nothing' or 'Set rst = nothing' in
adition to the '.close' statements. How important is it to do this - what
difference does make?
I am now following this practice in new projects - but should I spend the
hours/days required to add this to all my earlier projects which are still in
use.

 

[Donald A. Herman]

I would look at it as "insurance".

--
Donald A. Herman
Software - Scheduler Pro, Disk Cataloger, Math Wizard
http://don_herman.tripod.com
Office Extras
http://don_herman.tripod.com/msoextras

 

[Dirk Goldgar]

Using Access 2003/DAO
When I first learnt to do VBA in Access from books and onscreen help,
there was no reference to 'clean up', only to the need to close
recordsets etc at the end of subs or functions. Now, when I use this
forum or other online sources I am seeing things like 'Set db =
nothing' or 'Set rst = nothing' in adition to the '.close'
statements. How important is it to do this - what difference does
make?
I am now following this practice in new projects - but should I spend
the hours/days required to add this to all my earlier projects which
are still in use.

I would say not. In principle, explicitly destroying locally declared
objects should never be necessary in VB, as the language is supposed to
guarantee their destruction when they go out of scope. There are two
reasons for the common housekeeping practice you describe -- and which I
follow, BTW. First, making a habit of it keeps you from accidentally
being bitten when working with *global* objects. Second, there has in
the past been at least one bug in Access, where an object reference (I
think it was a Recordset object) would be created and not destroyed,
leaving a dangling object reference that could keep the database from
closing fully.

I'm fairly sure that bug has since been fixed, but the experience left a
lot of us in the habit of explicitly destroying objects. My feeling is,
it's a habit that does no harm (except inflating the source code by a
couple of lines) and protects against the possibility of such bugs,
while also forestalling possibly oversights when working with global
objects. So I espouse it while writing new code, but I don't see any
reason for you to go back and revise the existing code in working
applications.

 

[Tris]

Thank you Dirk, what you say is reasuring.