Recordset objects are automatically closed and set nothing
when they go out of scope.
You should always close and set to nothing recordset objects
when you are using ASP Classic, because those objects only
go out of scope when you close your Internet Web Server by
stopping the IIS service.
If you look at generic MS examples of using DAO and ADO
recordsets, you will see that they do this, so that the code is
suitable for use in generic situations, like when using ASP Classic.
So the first answer to your question is Yes, a recordset is
like a recordset clone, they are automatically closed and
released where required, you don't have to do anything.
The next answer is that Recordset Clones are a bit tricky, because
they are not independent recordset. Do you really want the
form to be disconnected because it's recordset has been closed?
Access tries to catch that kind of error, but it doesn't always
succeed. For example, you can close the CurrentDatabase
object. Access catches that and re-opens a CurrentDatabase
object, but it's not actually the same object, and it invalidates
anything that was connected to the old object. You need to be
careful about not closing anything that anyone else is using, and
a recordset clone shares a recordset, so it is not safe to close.
If you want your code to be portable to ASP Classic, you need
to remember to close recordsets. But recordset clones are not
portable to ASP Classic.
In general, if you have global recordset, you need to remember not
to use global recordsets. That is not a choice in ASP Classic, but
it is a choice in Access. If for greater speed, you choose to use a
global recordset, you need to remember that computers are very
fast now. If you choose to global recordsets for speed anyway, the
most important thing is to remember not to close them, because
your code will assume that the recordset is open. Of course if you
remember to never specifically close your local recordsets, you
won't be tempted to accidentally close your global recordsets.
If you look around the WWW, you will find sample code generated by
an MDE decompiler. When you look at the code, you will see the
close/release code that is explicitly included by the compiler in VBA
procedures that use recordsets.
Of course, if you are a C programmer, you will not feel comfortable
with having a compiler that does memory management for you, and
will want to explicitly close every object that you open. The same if
you are an ASP Classic programmer, used to system-global objects.
Or an old-style BASIC programmer, who never got used to the idea
of subroutines, and expects every program to be just one long list of
lines.
Just to be consistent, I went through our code years ago and removed
all the superfluous close/release code, adding error logging, and
removing global objects. The main point is that it removed unnecessary
lines, making the meaningful code clearer, but the added advantage
is that the only special close/release code is that which is in there for
a reason.
(david)
