DataView.Dispose

  • Thread starter Thread starter Alex Pecoraro
  • Start date Start date
A

Alex Pecoraro

Is it a good idea to call DataView.Dispose() after an allocated DataView
falls out of scope?

Relatedly, if the DataView is Bound to a Control, is it safe (or necessary)
to call Dispose()?

We've found that not calling DataSet.Dispose can cause problems, but didn't
realize that there was a dispose function on the DataView till today.

Any information you can provide on the bestpractices on this subject would
be appreciated.

Thanks,
Alex
 
Hi Alex,

Frankly, I've never called dataview.dispose and I use dataviews all the time
and have never had a problem.

What problem did you experience?

Bernie Yaeger
 
Both dataset and dataview have Dispose method because they are derived from
classes that implement IDisposable.
However, there is no need to invoke Dispose on either of them.
And I would say that it is not a wise thing to Dispose either of them while
they are databound.
 
Both dataset and dataview have Dispose method because they are derived
from
classes that implement IDisposable.
However, there is no need to invoke Dispose on either of them.
Click to expand...

How is this known?

Brad Williams
 
Brad Williams said:
How is this known?
Click to expand...

Documentation, experience, common sense :)
IMO Dispose is (normally) necessary on objects that either hold unmanaged
resources or hold a managed resource opened (such as connection, for
example).
 
I agree. Dispose is usefull when the destruction of one object hinges on
the destruction of another. If this is not the case, then your object will
Dispose itself when it falls out of scope.
 
I'd prefer just documentation!

IDispose is on several ADO.NET classes. If on some of these Dispose is
*never* necessary, Microsoft should tell us that. If it is not necessary
now, but may be in the future ... well, they can't go changing the, er,
implicit protocol that everyone depends on like that, can they? And if we
*cannot* call dispose when databound without bad consequences as you
suspect, or in some other situations, I'm sure I'm not the only one who
would like official confirmation.

In short, Microsoft needs to spill the beans on this gray area.

Brad Williams
 
Ok Brad, easy now, we hear you. It's just that this is more of a conceptual
issue IMHO. It just make sense that an object that is not bound to any
others would not need to have Dispose explicitly called. Now for many
objects, it is up to the programmer to decide whether or not it will be
"tied" to other objects, so how could MS tell you one way or the other?
 
True it is the programmer's responsibility to not call Dispose when he or
she *knows* the object is still in use. But that still leaves issues open
given that we don't know what is released, if anything, in the
implementation of Dispose. That is why this thread was started, and my team
went through the exact same wonderings a year ago. Smart people wonder
about this, and did you notice that the "experience" of two different
programmers in this very thread led them to opposite conclusions about
calling Dispose on a DataSet? This is a system library, ideally we
shouldn't need to infer it's implementation or to depend on experience or a
smart guy like Miha to know correct usage, the documentation should make the
rules explicit and clear. If I am wrong here then I wonder why the rules of
usage are not in fact obvious to everybody. Maybe some of us are just not
smart enough to use Microsoft libraries and I should switch to real estate.
;)

Brad Williams
 
Brad Williams said:
True it is the programmer's responsibility to not call Dispose when he or
she *knows* the object is still in use. But that still leaves issues open
given that we don't know what is released, if anything, in the
implementation of Dispose. That is why this thread was started, and my team
went through the exact same wonderings a year ago. Smart people wonder
about this, and did you notice that the "experience" of two different
programmers in this very thread led them to opposite conclusions about
calling Dispose on a DataSet? This is a system library, ideally we
shouldn't need to infer it's implementation or to depend on experience or a
smart guy like Miha to know correct usage,
Click to expand...

(for audience: that's me :) )

the documentation should make the
rules explicit and clear. If I am wrong here then I wonder why the rules of
usage are not in fact obvious to everybody. Maybe some of us are just not
smart enough to use Microsoft libraries and I should switch to real estate.
;)
Click to expand...

Yes, the documentation is not 100% accurate and clear - no wonder in so huge
pile of (good) files.
However, normally, it is written clearly that you need to call Dispose (or
Close) on classes that need to.
But hey, I wouldn't mind a check box near to a class definition that states
([ ] Dispose or Close necessary - even better if it is within IntelliSense
tooltips).
 
Hi Miha,

I see this so often in this newsgroup
However, normally, it is written clearly that you need to call Dispose (or
Close) on classes that need to.
Click to expand...

Where is this written?

I never saw it, I only saw as advice to use dispose with hugh memory
spending objects (by instance bitmaps).

I do not see any reason to dispose a connection, specialy not now Angel has
given such a clear sample that it only delete the connection string from the
object but is not disposing the object.

Do not misunderstand me, I see a lot of reasons to close a connection.

So please tell me what I do not see?
(Or where is written at MSDN that you have to dispose a connection).

Cor
 
Hi Cor,

Cor said:
Hi Miha,

I see this so often in this newsgroup


Where is this written?

I never saw it, I only saw as advice to use dispose with hugh memory
spending objects (by instance bitmaps).

I do not see any reason to dispose a connection, specialy not now Angel has
given such a clear sample that it only delete the connection string from the
object but is not disposing the object.

Do not misunderstand me, I see a lot of reasons to close a connection.
Click to expand...

That's why I've written "or Close" near to Dispose :)
Even .net help on SqlConnection says:
"If the SqlConnection goes out of scope, it is not closed. Therefore, you
must explicitly close the connection by calling Close or Dispose."

Happy? :)
 
Hi Miha,

I found it but no explanation why,

Do you think that that sentence is right?

I see not any reason why to dispose (removing the connection string)

As far as I can see it gives only extra overhead in my opinion.

So therefore I am still curious what is the reason to dispose.

(In the VB.language group it is standard to tell not to dispose if there is
not a really good reason)

Cor
 
So therefore I am still curious what is the reason to dispose.
Click to expand...

Dispose is there because of IDisposable.
Not really necessary to release the connection string, yes.
(In the VB.language group it is standard to tell not to dispose if there is
not a really good reason)
Click to expand...

Those VB weirdos :)
 
Hi Brad,

I think I can give you an answer precise enough so that you can
formulate your own rule re. when to call IDisposable.Dispose and when
not.

All framework classes that internally use unmanaged resources
implement the IDisposable interface. This means that you CAN (but
don't HAVE TO) explicitly tell the class instance to release the
unmanaged resources once you do not need it any more.

If you decide to call Dispose, there might be some performance or
memory benefits, although they sometimes are so small that they are
almost not measurable. If you decide not to call Dispose, the garbage
collector eventually will call the inherited Finalize method of the
class at least once (usually twice), which will invoke the class'
destructor, which will internally make the Dispose call that you did
not make. However you decide, there will be no destabilizing effects.
Just some extra calls which could be avoided.

However, for some framework classes, it IS extremely important that
their internally managed resources be released ASAP. How do you
recognize such classes? Simple: They always have, in addition to the
Dispose method, a method such as Close that makes it unmistakeably
clear what it is there for. Internally, Close simply calls Dispose.
You can call either one of them. Usually (but not always), Close can
be called only once, whereas Dispose always can be called as often as
you like (it's a common convention).

Conclusion:
Rule no. 1: If there is a method such as Close, ALWAYS make sure it is
called (e.g., enclose it in a "finally" clause).

Rule no. 2: If the class only implements Dispose, but has no method
such as Close, make your own decision. As to myself, I always call
it, because this is never wrong - and, after all, it's just one
statement! However, I do not construct "finally" clauses just to
protect the call to Dispose from any unexpected errors.
 
Back
Top