In a recent thread three folks found or confirmed cases where failure to clean up properly caused problems for them, specifically for hanging or orphaned processes.
https://access-programmers.co.uk/forums/showthread.php?t=288462&page=3
Vague hand-waving does not constitute a basis for an argument. Only reproducible evidence counts for anything. (BTW In my experience, the word "properly" is largely used used in a vain attempt to lend credence to an unsubstantiated position.)
There are in fact separate issues here that are being blended together.
One is a complete
Furphy. That is the claim that failure to Set an object variable to Nothing will leave an instance of an automated application lingering after it goes out of scope. The example given is usually Excel driven from Access but it applies to all Office Applications.
Fact 1: The automated instance must have the Quit Method applied or it WILL persist after the object variable goes out of scope.
Fact 2. Regardless of whether the object variable is Set to Nothing or not, the instance of the automated application will NOT persist beyond its scope provided that it has been Quit.
Going out of scope means, for variable declared in a procedure, at the end of the procedure. For a variable declared at the top of a Class Module (including an Access Object Module), when the instance of the object is closed. For a variable declared at the top of a Standard Module, when the primary application had been Quit.
These results are consistent and reproducible by anyone who cares to perform the tests.
As I have said before, those who have experienced an automated application persisting and fixed the problem by copiously adding Close, Quit and Set to Nothing everywhere it might fit, have not discriminated the actual cause of the problem. Thus they have no grounds to be making a claim for the case that Set to Nothing is essential. It is the Quit they omitted that is the verifiable cause.
The related matter regards whether or not the absence of Set to Nothing will result in memory leakage, tying up RAM that will never be released, despite the automated application not being listed in Task Manager. This was the issue that ChrisO addressed.
Chris created object variables in millions of loops without including Set to Nothing and did not observe adverse effects. Hence his indignation was at those who insisted (without evidence) that it was a disastrous practice.
Chris was also correct that the claim had become a mantra repeated over and over by developers who had never tested anything, until it took on the status best considered a religious belief.
For the record (and I have said this before), I disagree with Chris about not closing recordsets. Nothing Earth-shatteringly bad happens but I believe the recordset is left lingering until the database engine times out.
Finally I would add that there is one very good reason for Set to Nothing. One day your boss might get someone to audit your code. They will likely be subscribers to the SetToNothing religion and will criticise your work if you omit it. The auditor will have higher status than you because your boss paid more for their advice.
Unfortunately, as in any religion, logical arguments are pointless.
Thanks for your swift reply.
