What happend if:
Roberto Araoz
Dim rdoRSBlock As rdoResultset
Set rdoRSBlock = Nothing
DO I NEED TO :
rdoRSBlock.Close ???
OR CLOSES ITSELF ?
¸.·´¯`·.¸/ Roberto Araoz \¸.·´¯`·.¸
Chris Anderson
IMHO you should always explicity close anything that supplies a "Close" type
method.
--
Chris Anderson
(aka Merak on VISBAS-L)
"Roberto Araoz" <robert...@hotmail.com> wrote in message
news:uqG#7OyNBHA.864@tkmsftngp05...
Roberto Araoz
"Chris Anderson" <me...@vbREreMOalVEm.co.uk> wrote in message
news:uaevXhyNBHA.1844@tkmsftngp05...
VOrtex
if not rs.state = adstateopen then
rs.close
end if
set rs = nothing
end if
Something like that
Regards
VOrtex
"Roberto Araoz" <robert...@hotmail.com> wrote in message
news:emRYYpyNBHA.2036@tkmsftngp03...
Randy Birch
Nothing statement is redundant, as VB takes rs out of scope automatically
when the routine ends.
--
Randy Birch
MVP Visual Basic
Please respond only to the newsgroups so all can benefit.
"VOrtex" <as...@askme.nospam> wrote in message
news:eYwpVuyNBHA.864@tkmsftngp05...
: if not rs is nothing then
: > > >
: > > > 8.74/`7.8/ Roberto Araoz \8.74/`7.8
: > > >
: > > >
: > >
: > >
: >
: >
:
:
James McComb
It *probably* (and IMHO should) close itself....but why risk it?
James McComb writes:
And to be really safe, you can write code like this:
Public Sub MySub
Dim MyString As String
MyString = ""
Dim MyClient As Client
Set MyClient = New Client
MyString = "Bob"
MyClient.Name = MyString
Set MyClient = Nothing
MyString = ""
End Sub
Why risk it? :)
Michael (michka) Kaplan
Um, this is dumb.
You are basically freeing a string and then allocating a new string of zero
length. If you are trying to free the resource, then try
MyString = vbNullString
I actually owned a large VBA project (over 85,000 lines) that found that
shutdown was up to 2 seconds faster (30 seconds in debug) if strings were
cleared this way instead of all ZLS's. So it *can* make a difference.
--
MichKa
the only book on internationalization in VB at
http://www.i18nWithVB.com/
"James McComb" <the_idio...@hotmale.kom> wrote in message
news:eATFv30NBHA.2124@tkmsftngp05...
James McComb
James
Joe "Nuke Me Xemu" Foster
> How can I know if a resultset it's Open ?
>
> "Chris Anderson" <me...@vbREreMOalVEm.co.uk> wrote in message
> news:uaevXhyNBHA.1844@tkmsftngp05...
> > It *probably* (and IMHO should) close itself....but why risk it?
> >
> > IMHO you should always explicity close anything that supplies a "Close"
> type
> > method.
The approach I usually take is to Set objects to Nothing as soon as
I've cleaned them up. Steven A. Mitchell may disapprove, but it
does make writing error handlers much easier, and if you're worried
about calling Close or what have you, you probably do need an error
handler.
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Joe "Nuke Me Xemu" Foster
> Chris Anderson wrote:
You sure these last two actually worked? Better not risk it!
Set MyClient = Nothing
MyString = vbNullBrain
Set MyClient = Nothing
MyString = vbNullBrain
Set MyClient = Nothing
MyString = vbNullBrain
Set MyClient = Nothing
MyString = vbNullBrain
Set MyClient = Nothing
MyString = vbNullBrain
Set MyClient = Nothing
MyString = vbNullBrain
Set MyClient = Nothing
MyString = vbNullBrain
> End Sub
>
> Why risk it? :)
Indeed.
--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
Roberto Araoz
"VOrtex" <as...@askme.nospam> wrote in message
news:eYwpVuyNBHA.864@tkmsftngp05...
Jeff Johnson
> What happend if:
>
> Dim rdoRSBlock As rdoResultset
>
> Set rdoRSBlock = Nothing
>
>
> DO I NEED TO :
> rdoRSBlock.Close ???
>
> OR CLOSES ITSELF ?
I realize it's going to start the debate again, but NEITHER closing nor
setting to Nothing is necessary. Since this is a procedure-level variable,
it will go out of scope when the procedure exits. And when it goes out of
scope, it will close and be set to Nothing. I do this (or rather, DON'T do
this) in all my apps and they work fine. Every time.
Jeff Johnson
"James McComb" <the_idio...@hotmale.kom> wrote in message
> Irony's not your strong point, is it Mike? :)
I thought it was sarcasm.
Michael (michka) Kaplan
news:Ob5#pUBOBHA.1472@tkmsftngp03...
Correct, Jeff.
James suffers from something known in many circles as "Alanis Morrissette
Disease" which is a strong desire to call things ironic that actually are
not ironic at all? :-)
Michael (michka) Kaplan
indeed help, and there have been numerous bugs in versions of RDO, ADO,
ODBCDirect, and ADO associated with not doing explicit Closes.
There are currently no known bugs about setting or not setting to Nothing,
though there were some Jet 3.5/DAO bugs that related to teardown order (if
you did not clean up objects yourself -- in the right order -- but instead
depended on VB to cleanup, you could get into trouble.
This is neither a RELIGIOUS issue nor one to claim is not present, I have
seen the bugs, I have even helped track them down in the past for MS. Please
do not minimize the issue, okay?
--
MichKa
the only book on internationalization in VB at
http://www.i18nWithVB.com/
"Jeff Johnson" <pawp...@com.geocities> wrote in message
news:eCpqpUBOBHA.1472@tkmsftngp03...
Joe "Nuke Me Xemu" Foster
> Jeff, you are incorrect about CLOSE. There are many cases where it can
> indeed help, and there have been numerous bugs in versions of RDO, ADO,
> ODBCDirect, and ADO associated with not doing explicit Closes.
>
> There are currently no known bugs about setting or not setting to Nothing,
> though there were some Jet 3.5/DAO bugs that related to teardown order (if
> you did not clean up objects yourself -- in the right order -- but instead
> depended on VB to cleanup, you could get into trouble.
Was DAO the only component ever affected, or have there been others, such
as certain third-party bugware, as well?
> This is neither a RELIGIOUS issue nor one to claim is not present, I have
> seen the bugs, I have even helped track them down in the past for MS. Please
> do not minimize the issue, okay?
Cites? It's not that *I* disbelieve you -- it's for the benefit of those
folks here who continue simply to refuse to accept that tear-down order
could *ever* *possibly* matter in any way *whatsoever*:
news://msnews.microsoft.com/1608d01c12a70%24d2d20ed0%249ae62ecf%40tkmsftngxa02
(Interesting how the "moron" forgot all about the .Close in the above, eh?)
news://msnews.microsoft.com/10db301c12a69%24c00c78a0%24a5e62ecf%40tkmsftngxa07
news://msnews.microsoft.com/1487201c1317b%24a93907b0%24a5e62ecf%40tkmsftngxa07
I wonder if he's gotten around to flaming *himself* yet:
http://groups.google.com/groups?selm=eQBkYVKLAHA.255%40cppssbbsa05
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
Michael (michka) Kaplan
news:ueY1MSIOBHA.1524@tkmsftngp03...
> > There are currently no known bugs about setting or not
> > setting to Nothing, though there were some Jet 3.5/DAO
> > bugs that related to teardown order (if you did not clean
> > up objects yourself -- in the right order -- but instead
> > depended on VB to cleanup, you could get into trouble.
>
> Was DAO the only component ever affected, or have there
> been others, such as certain third-party bugware, as well?
It is obviously not specific to databases, so any software could have the
problem. The DAO case often related to times that you would shut down a
database prior to a recordset, or especially where you would use an Access
recordsetclone (where you have no control over the db connection at all). It
easy to see how a component one writes could have such a bug -- remember
that in in C/C++ you do not have somebody doing refcounting for you, so it
is easy for a component to make a mistake here.
> > This is neither a RELIGIOUS issue nor one to claim is not
> > present, I have seen the bugs, I have even helped track them
> > down in the past for MS. Please do not minimize the issue,
> > okay?
> Cites? It's not that *I* disbelieve you -- it's for the benefit of those
> folks here who continue simply to refuse to accept that tear-down order
> could *ever* *possibly* matter in any way *whatsoever*:
Although I am sure I could track down exact bug descriptions and repro
steps, I am unclear on whether or not I would be allowed to discuss them
since I investigated them "on someone's clock", so to speak?
Any moron can imagine how such a bug MIGHT exist. With all the people who
like to slam Microsoft, I cannot believe it is so hard for those same people
to imagine a refcount bug -- sometimes I think that VB/VBA has spoiled too
many people such that they do not understand basic software issues.
If anyone does NOT get it, maybe they will get it some day. Or maybe I will
write some VB code that messes up the ref count (in both directions) so that
people can see the crashes and the memory leaks, directly?
--
MichKa
Michael Kaplan
Trigeminal Software, Inc.
http://www.trigeminal.com/
(principal developer of the MSLU)
Joe "Nuke Me Xemu" Foster
> "Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
> news:ueY1MSIOBHA.1524@tkmsftngp03...
>
>
> > > There are currently no known bugs about setting or not
> > > setting to Nothing, though there were some Jet 3.5/DAO
> > > bugs that related to teardown order (if you did not clean
> > > up objects yourself -- in the right order -- but instead
> > > depended on VB to cleanup, you could get into trouble.
> >
> > Was DAO the only component ever affected, or have there
> > been others, such as certain third-party bugware, as well?
>
> It is obviously not specific to databases, so any software could have the
> problem. The DAO case often related to times that you would shut down a
> database prior to a recordset, or especially where you would use an Access
> recordsetclone (where you have no control over the db connection at all). It
> easy to see how a component one writes could have such a bug -- remember
> that in in C/C++ you do not have somebody doing refcounting for you, so it
> is easy for a component to make a mistake here.
I also vaguely recall something about using a boolean field's default
property within an If statement, but that may have been specific to
Access 2.0.
> > > This is neither a RELIGIOUS issue nor one to claim is not
> > > present, I have seen the bugs, I have even helped track them
> > > down in the past for MS. Please do not minimize the issue,
> > > okay?
>
> > Cites? It's not that *I* disbelieve you -- it's for the benefit of those
> > folks here who continue simply to refuse to accept that tear-down order
> > could *ever* *possibly* matter in any way *whatsoever*:
>
> Although I am sure I could track down exact bug descriptions and repro
> steps, I am unclear on whether or not I would be allowed to discuss them
> since I investigated them "on someone's clock", so to speak?
Are you implying they might not all be in the Microsoft Knowledge Base
for all too stumble across? I'm shocked, *shocked* at your scurrilous
and irresponsible accusations!
> Any moron can imagine how such a bug MIGHT exist. With all the people who
> like to slam Microsoft, I cannot believe it is so hard for those same people
> to imagine a refcount bug -- sometimes I think that VB/VBA has spoiled too
> many people such that they do not understand basic software issues.
>
> If anyone does NOT get it, maybe they will get it some day. Or maybe I will
> write some VB code that messes up the ref count (in both directions) so that
> people can see the crashes and the memory leaks, directly?
That won't prove anything, since as every fool knows, only VB code can
ever possibly "leak", and even then only through circular references!
That's obviously mere "pilot error" by stoopid wannabe macro-coders,
though perhaps it can also be caused by insisting on Setting objects
to Nothing explicitly instead of just letting them go out of scope, to
be cleaned up in an arbitrary sequence which will have absolutely no
impact whatsoever on any components' internal cleanup code. Duh.
--
Joe Foster <mailto:jlfoster%40znet.com> Sacrament R2-45 <http://www.xenu.net/>
Michael (michka) Kaplan
> I also vaguely recall something about using a boolean field's default
> property within an If statement, but that may have been specific to
> Access 2.0.
Actually, this is a known bug in later versions and NOT in Access 2.0.
> Are you implying they might not all be in the Microsoft Knowledge Base
> for all too stumble across? I'm shocked, *shocked* at your scurrilous
> and irresponsible accusations!
Hopefully this is just sarcasm.
These bugs took DAYS to even understand what the cause was -- and that was
with access to source code; it would take a BOOK, not a KB article to
explain them.
> That won't prove anything, since as every fool knows, only VB code can
> ever possibly "leak", and even then only through circular references!
> That's obviously mere "pilot error" by stoopid wannabe macro-coders,
> though perhaps it can also be caused by insisting on Setting objects
> to Nothing explicitly instead of just letting them go out of scope, to
> be cleaned up in an arbitrary sequence which will have absolutely no
> impact whatsoever on any components' internal cleanup code. Duh.
Again, I hope this is sarcasm.
Anyone can guess at the possible causes for a bug such as this. Imagine that
ths rs needs a pointer to the database connection (obviously it does), and
imagine that there are strange issues with shutting down the db object you
have and the effect it has on the one that the recordset has. Someone makes
a mistake in the case where you shut down the db, and now oops! A recordset
bug. Then they fix it in a way that causes there to be an orphan db
reference if you do not close it down -- oops! Access won't close. Now
consider that the actual bugs are like 100 times more complex to track down
than this butt-stupid example -- and then you will realize the people who do
not believe such things are possible are total morons.
This is almost worthy of an interview question -- "how could you create such
a bug?". If they claim it is impossible, than do not hire them a they are
braindead (the followup question would be "how do you fix the bug now?".
--
MichKa
Michael Kaplan
Trigeminal Software, Inc.
http://www.trigeminal.com/
(principal developer of the MSLU)
>
Joe "Nuke Me Xemu" Foster
> "Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
> news:eMEP1IMOBHA.2048@tkmsftngp04...
> > That won't prove anything, since as every fool knows, only VB code can
> > ever possibly "leak", and even then only through circular references!
> > That's obviously mere "pilot error" by stoopid wannabe macro-coders,
> > though perhaps it can also be caused by insisting on Setting objects
> > to Nothing explicitly instead of just letting them go out of scope, to
> > be cleaned up in an arbitrary sequence which will have absolutely no
> > impact whatsoever on any components' internal cleanup code. Duh.
>
> Again, I hope this is sarcasm.
I did lay it on a bit thick, didn't I? If so, sorry.
> Anyone can guess at the possible causes for a bug such as this. Imagine that
> ths rs needs a pointer to the database connection (obviously it does), and
> imagine that there are strange issues with shutting down the db object you
> have and the effect it has on the one that the recordset has. Someone makes
> a mistake in the case where you shut down the db, and now oops! A recordset
> bug. Then they fix it in a way that causes there to be an orphan db
> reference if you do not close it down -- oops! Access won't close. Now
> consider that the actual bugs are like 100 times more complex to track down
> than this butt-stupid example -- and then you will realize the people who do
> not believe such things are possible are total morons.
For those just tuning in:
news://msnews.microsoft.com/udTQGJCOBHA.1688@tkmsftngp05
> This is almost worthy of an interview question -- "how could you create such
> a bug?". If they claim it is impossible, than do not hire them a they are
> braindead (the followup question would be "how do you fix the bug now?".
I know! Let's ask Steven A. "it's impossible" Mitchell!
"Set to nothing releases the reference before the variable
goes out of scope. That's all it does. If you have a
memory leak, a simple set to nothing is never
*sufficient*." -- Steven A. Mitchell, 2001-08-21, in article
news://msnews.microsoft.com/10db301c12a69$c00c78a0$a5e62ecf@tkmsftngxa07
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
Michael (michka) Kaplan
> "Michael (michka) Kaplan"
> For those just tuning in:
>
> news://msnews.microsoft.com/udTQGJCOBHA.1688@tkmsftngp05
>
> > This is almost worthy of an interview question -- "how could you create
such
> > a bug?". If they claim it is impossible, than do not hire them a they
are
> > braindead (the followup question would be "how do you fix the bug now?".
>
> I know! Let's ask Steven A. "it's impossible" Mitchell!
>
> "Set to nothing releases the reference before the variable
> goes out of scope. That's all it does. If you have a
> memory leak, a simple set to nothing is never
> *sufficient*." -- Steven A. Mitchell, 2001-08-21, in article
> news://msnews.microsoft.com/10db301c12a69$c00c78a0$a5e62ecf@tkmsftngxa07
Well, I am not sure how this proves or disproves what I said? I am saying
that those who do NOT work in VB have to actually CHOOSE to properly
refcount many things, or not choose to, as the case may be. They must also
choose to release refs.
If they do not, there can be bugs.
--
MichKa
Michael Kaplan
(principal developer of the MSLU)
Trigeminal Software, Inc. -- http://www.trigeminal.com/
the book -- http://www.i18nWithVB.com/
Joe "Nuke Me Xemu" Foster
> > "Set to nothing releases the reference before the variable
> > goes out of scope. That's all it does. If you have a
> > memory leak, a simple set to nothing is never
> > *sufficient*." -- Steven A. Mitchell, 2001-08-21, in article
> > news://msnews.microsoft.com/10db301c12a69$c00c78a0$a5e62ecf@tkmsftngxa07
>
> Well, I am not sure how this proves or disproves what I said? I am saying
It does neither one. He has, however, spent the past year denying the
possibility of refcount bugs that might be worked around by explicitly
releasing reference variables in a specific order before they go out of
scope, and the above quote is an example of such a denial. He has even
lambasted me for using Set to Nothing after a Close as a way to hint to
error handlers that the reference has already been Closed and cleaned
up. Apparently,
Every Set is sacred,
every Set is great,
If a Set is wasted,
Steve gets quite irate.
> that those who do NOT work in VB have to actually CHOOSE to properly
> refcount many things, or not choose to, as the case may be. They must also
> choose to release refs.
I have seen some non-COM, STL-compatible, reference-counting smart-pointer
classes which may make this easier in new C++ code or refactored old code.
> If they do not, there can be bugs.
Not in ATL, there can't! ATL is perfect. Just ask in the DevX forums,
as they'll tell you again, and again, and again...
http://www.winternet.com/~mikelr/flame69.html
Michael (michka) Kaplan
> It does neither one. He has, however, spent the past year denying the
> possibility of refcount bugs that might be worked around by explicitly
> releasing reference variables in a specific order before they go out of
> scope, and the above quote is an example of such a denial.
Well, he is wrong. Nuff said.
Bob Butler
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
<cut>
> Every Set is sacred,
> every Set is great,
> If a Set is wasted,
> Steve gets quite irate.
ROTFLMAO!