What Happens if You Forget to Set db = nothing?
Tim Marshall
sort of requirement and others dictate that I need to begin my
procedure with something in the way of:
dim db as database
set db = Currentdb
What happens or could happen if I forget to indicate set db = Nothing at
the end of such procedures? Or errors terminate the procedure before
this line is reached?
I'm an A97 user, but I expect the topic is relevant top 2000 as well.
Thanks in advance for any help in understanding this.
--
Tim - http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^
Tim ffitch
It is good programming practise to destroy these objects in this manner when
the are no longer needed. Windows apps are supposed to be dynamic in
destroying these objects for you, however if you rely on this, a poorly
programmed app can soon eat away all your memory in so called "Memory
Leaks".
I you are concerned that if an error happens and this line of code is not
reached, construct an error handling routine that also includes this line of
code if the object is no longer needed after the error or it's an error that
cannot be recovered from.
Hope this helps
Kind regards
Tim ffitch
"Tim Marshall" <tmar...@morgan.ucs.mun.ca> wrote in message
news:39C0DEED...@morgan.ucs.mun.ca...
Tim Marshall
Michael (michka) Kaplan
current implementation of VB.Net (the language we will eventually get, in
the Office 11 timeframe, perhaps?) currently has no deterministic cleanup
and thus not setting to nothing means you have no guarantee on WHEN it would
happen.
--
MichKa
random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Tim ffitch" <"f...@kll-fm.co.uk"> wrote in message
news:8pqp33$hc4$1...@plutonium.btinternet.com...
Steve Jorgensen
class module, the Terminate event is always triggered when the number
of references reaches zero regardless of whether this happens by
explicitly setting references to Nothing or just letting them go out
of scope. Why could they not have done the same thing with DAO object
references? Why are non-Nothing references not cleaned up when they
go out of scope the same as if they were explicitly set to Nothing?
Of course, I am well aware that the issue is real because if I miss
setting a DAO reference to Nothing, performance gradually degrades,
and Access won't close just as it says in the KB (would have been nice
to have that in bold in the hlp files, MS!).
Michael (michka) Kaplan
Several of these bugs were ones that I was assigned to help the Jet and DAO
developers track down in Access 97/Jet 3.5 timeframe (they actually fixed
the bugs that were found!).
Remembering that DAO is simply a layer over Jet, there were times
(especially with transactions, but other times as well) that the object
would be freed, and DAO would try to close it down but it would fail to do
so in some case where Jet still "needed" it for rollback or cleanup purposes
of its own. Since the object was now out of scope, no one knew to ask it to
be freed... and so it would not be.
Other bugs involved reference count mismatches between DAO objects. Remember
that in C/C++, you do not have a language like VB/VBA that automatically
calls AddRef and Release on objects, it must be done explicitly. In some
cases you would not want to do this because of the circular reference
problem, but the work being done missed a code path and then you had an
unfreed object, so DAO was still open.
Most people would likely not have noticed if not for code in Access that
checks for open DAO objects and if there are any then it would not close.
Very unfortunate stuff, but sort of a natural side effect of sufficiently
complex code.
--
MichKa
random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Steve Jorgensen" <nos...@nospam.nospam> wrote in message
news:39c13af4...@news.teleport.com...
Steve Jorgensen
<forme...@spamfree.trigeminal.nospam.com> wrote:
>Steve,
>
>Several of these bugs were ones that I was assigned to help the Jet and DAO
>developers track down in Access 97/Jet 3.5 timeframe (they actually fixed
>the bugs that were found!).
>
>Remembering that DAO is simply a layer over Jet, there were times
>(especially with transactions, but other times as well) that the object
>would be freed, and DAO would try to close it down but it would fail to do
>so in some case where Jet still "needed" it for rollback or cleanup purposes
>of its own. Since the object was now out of scope, no one knew to ask it to
>be freed... and so it would not be.
>
In this case, why can the same problem not also occur when explicitly
setting the reference to Nothing?
>Other bugs involved reference count mismatches between DAO objects. Remember
>that in C/C++, you do not have a language like VB/VBA that automatically
>calls AddRef and Release on objects, it must be done explicitly. In some
>cases you would not want to do this because of the circular reference
>problem, but the work being done missed a code path and then you had an
>unfreed object, so DAO was still open.
>
>Most people would likely not have noticed if not for code in Access that
>checks for open DAO objects and if there are any then it would not close.
>Very unfortunate stuff, but sort of a natural side effect of sufficiently
>complex code.
>
Yes, I see. This makes a good case for designing a robust framework
first (including things factories, reference counters, etc.), and
staying within it at (almost) all times. Of course, that can result
in somewhat slower code, but also smaller and easier to maintain. Oh
well, too late to rewrite it now :)
Michael (michka) Kaplan
order of operations. There are times when the explicit shutdown will have a
more marked effect than the implicit one.
--
MichKa
random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Steve Jorgensen" <nos...@nospam.nospam> wrote in message
news:39c15424...@news.teleport.com...
Michael (michka) Kaplan
explicitly set to nothing you control the order of the shutdown. That order
is what can get you into trouble as the implicit method may not pick a very
smart one.
It is impossible to discuss details without getting into implementation
details that are clearly under NDA for at least the next 2-3 years, so I
cannot say too much more than this. But I can gauarntee you that this was
not anticipated.
--
MichKa
random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Steve Jorgensen" <nos...@nospam.nospam> wrote in message
news:39c18300...@news.teleport.com...
> On Thu, 14 Sep 2000 18:42:14 -0700, "Michael \(michka\) Kaplan"
> <forme...@spamfree.trigeminal.nospam.com> wrote:
>
> >As to why it sometimes happens and sometimes does not, it has to do with
the
> >order of operations. There are times when the explicit shutdown will have
a
> >more marked effect than the implicit one.
> >
> >--
> >MichKa
> >
>
>
> At the risk of sounding redundant - I guess what never made sense to
> me is why a reference going out of scope would be handled in any way
> differently than one being explicitly set it to nothing. What would
> could be the benefit of such a difference? The disadvantage has
> certainly been made clear.
Steve Jorgensen
Steve Jorgensen
in a precise order such that an object is not released until its
dependencies are also released. If the references all go out of
scope, they are released willy nilly, and who knows what may happen.
This makes sense.
On Thu, 14 Sep 2000 19:27:49 -0700, "Michael \(michka\) Kaplan"
<forme...@spamfree.trigeminal.nospam.com> wrote:
>I am NOT saying this was the intentional design. I am saying that when you
>explicitly set to nothing you control the order of the shutdown. That order
>is what can get you into trouble as the implicit method may not pick a very
>smart one.
>
>It is impossible to discuss details without getting into implementation
>details that are clearly under NDA for at least the next 2-3 years, so I
>cannot say too much more than this. But I can gauarntee you that this was
>not anticipated.
>
>--
>MichKa
>
>random junk of dubious value at the
>multilingual http://www.trigeminal.com/ and
>a new book on internationalization in VB at
>http://www.i18nWithVB.com/
>
>"Steve Jorgensen" <nos...@nospam.nospam> wrote in message
>news:39c18300...@news.teleport.com...
Tony Toews
>In many of my procedures, I need to build and/or save querydefs.
I used to do this. But now I build a basis query which contains all the data which I
want to update or append. Then I build another query on top of that basis query
which does the update/append including the parameters, get the SQL code for the query
and put that SQL code in VBA along with substituting the various parms from my
various sources.
Something like
strSQL = "SELECT * FROM [Invoicing - Price Book Calcs - Matrix] " & _
"WHERE lopbhPriceBooksID =" & CStr(lngPriceBookID) & " AND " & _
"lotType=" & CStr(intLabourOpType) & " AND " & _
"lopbdMaterialScheduleID=" & CStr(lngMaterialScheduleID) & " AND " & _"lopbdSize >= "
& CStr(sngPipeSize) & ";"
Set RS = MyDB.OpenRecordset(strSQL)
although this one opens a record set.
This makes maintenance much easier as I can just review the basis query for any logic
failures and simply update the strSQL with any minor tweaking. Or if necessary build
the basis query again which should only take a few seconds.
Tony
----
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
VolStar http://www.volstar.com Manage hundreds or
thousands of volunteers for special events.