DAO Connectivity

[DavidBoyle via AccessMonster.com]

Allen Browne kindly helped me with a post made earlier with a great answer -
I've been an Access Developer for 13 years and still find new stuff to learn.
As I got such a good result here I am coming back for more.

All of us who have spent any time writing ADO or DAO code know that it is
good practice to limit the scope of data access object variables as much as
possible and to clean them up tidily at the end of functions in which they
were declared. I'm working for a client who appears to have issues caused by
sloppily written code which works fine on fast machines with a high bandwidth
connection to a development server but when rolled out to more remote
locations with flakier network links seems more unforgiving of the issue.

I've spent a week re-coding an application and building inerror handling,
generally rationalising and improving things, reducing reliance on linked SQL
tables etc.

Can anybody recommend any knowledge articles that explain why closing object
references is important. I can do so myslef but feel that an external source
may carry more weight. Anyone know of an article I can cite?

 

[Douglas J. Steele]

While dated, take a look at http://support.microsoft.com/kb/164455

 

[Guest]

The number one reason to close object instances is so that
your code will work correctly in ASP classic.

As you look at the MS code examples, you will see that there
is a common coding standard, and that the common coding
standard works for all VBA containers. A particularly important
VBA code container was ASP classic. It was common to use
ASP classic to access database objects.

ASP classic code did not go 'out of scope', so objects were
never automatically closed and released. If you do not explicitly
close and release objects that you open in VBA in ASP classic,
you will run out of memory, and your web server will slow, stop,
and crash.


It is possible to get a similar sort of problem in any large,
long-running piece of code written as a single sub-routine.

So it is possible to get a similar sort of problem with any
large, long-running piece of code written as a single routine
in GWBASIC and ported to MS BASIC and then to VB.

Or in an large, long-running piece of code written as a single
routine by a programmer who has started in BASIC and moved
to MS BASIC and then to VB.


It is also possible to get obscure conflicts when you mix
global or module-level objects with local transactions. It is
even possible to get obscure conflicts when you mix global
or module-level objects with the implicit transactions of
table-view tables and queries. This is rare, and never happens
if you don't use global or module-level objects.

Of course, some people do use global data objects, but it is
best to minimise their number.

Apart from that, nothing.

So the rules are:
1) Always explicitly close objects when using ASP classic
2) Try to explicitly close objects that aren't going to immediately
fall out of scope, that is global and module-level objects, and
any temporary objects in large, long-running pieces of code written
as single routine.


(david)