VBA Garbage Collection.
@macropod
First of all, thanks for the links and just to be clear, I'm not trying to flame anyone here and I won't be making comments like "you didn't look very hard" coz I don't know that for a fact. And for the record, I did a lot of reading before posting. I'm interested in the topic specifically because of the volume and diversity of opinion that I saw.

In your first link, they are talking about Access and most of the objects are DAO objects. The example code uses the pattern you advocate but there is no instruction or recommendation for using this pattern. They say that you can free up memory by setting objects to nothing but they do not say that failing to do so, just before a local object goes out if scope, will cause a problem. It was produced by Microsoft but then this guy is also from Microsoft and he's is saying explicitly that it's not necessary and he's no slouch...

http://blogs.msdn.com/b/ericlippert/...28/122259.aspx

Here's another guy with a solid background who also has a definitive opinion on the issue...
http://ramblings.mcpher.com/Home/exc.../scope/garbage

If you google VBA garbage collection you will get a lot if hits and I read quite a few if them before my first post on the topic. I found this to be a good representation of the spread of opinion...

https://groups.google.com/forum/m/?h...vb/3pw-TGc9PSo

The common theme of the two camps is:
On the affirmative: I believe I should do it, so I do it, just in case.
On the negative: it's not necessary and here is a clear explanation as to why...

Your second link is basically supporting what I'm saying: that setting objects to nothing doesn't always do what you expect and that you have to be careful how you construct them and how you tear them down if they have complicated structures. Furthermore, he explicitly says that just setting objects to nothing at the end if a sub is a bad idea. So it's counter to your argument.

In your third link there is a list if memory leak sources...

Page Setup in Win95 & Win98 & Win ME (GDI problem) - see MSKB Q192869 - NOT fixed by setting objects to Nothing

Printing using HP Printers - see MSKB Q165985 and Q218864 - NOT fixed by setting objects to Nothing

Querying an open Excel worksheet using ADO - see MSKB Q319998 - NOT fixed by setting objects to Nothing
"The memory used by the ADO queries cannot be reclaimed by closing and releasing the ADO objects. The only way to release the memory is to quit Excel."

Replacing external link formulae - NOT fixed by setting objects to Nothing

Some external data retrieval actions, particularly repeatedly reading text files. Excel seems to store only unique strings rather than multiple occurrences of the same string, but does not seem to remove a unique string when it is no longer in use. - NOT fixed by setting objects to Nothing

Controls embedded on worksheets - see MSKB Q238570 - applies to excel97 - NOT fixed by setting objects to Nothing

User Defined Functions, particularly when they take input parameters from another sheet and return a string. there are some fixes for these problems in Excel 97 SR2 and Excel 2000 SP2 - see MSKB Q265023 - NOT fixed by setting objects to Nothing

Not destroying objects in VBA by setting the object variables to nothing in the correct sequence so that you avoid "orphaned" objects. In theory this is not neccessary, but sometimes problems occur when this is not done. Destroy in inside-out container sequence, for example Range then Worksheet then Workbook.
This is similar to your second link and points out the need for proper tear-down of non-trivial custom objects. - NOT fixed by simply setting objects to Nothing prior to them going out of scope and not applicable to local scoped objects.

So... I'm just sayin'