when to dispose a datatable?

[Smokey Grindle]

I have a list box on my form, but I need to databind it to a data table that
is a private member of the form's class... so I basically have

Public Class MyForm
priate m_MyTable as new datatable
End Class

now where would I properly dispose of this? In the finalize method? I am
loading the data for the table in a subroutine that is executed at form
load, of course all the commands tied to it are wrapped in using blocks, but
I cant wrap the table in that because it i put it in a using block then
databind it, of course it will disappear when it exits that block and then
the databinding is gone, so I made it at the class level instead and want
its life time to be that of the form.. thanks!

 

[AlexS]

Dispose it when you don't need table anymore.

You can do that in FormClosing or in form Dispose if you implement it

HTH

 

[Miha Markic]

Just a note that you don't actually need to dispose datatable, but it is a
good practice.
And yes, dispose it when you are done with it (form's dispose might be a
good place if you can't dispose it earlier)

 

[Smokey Grindle]

what about in a custom control? should it be in the dispose method or
finalize method? I remember this is a difference between them, i believe
that dispose is immediate and finalize can happen at any time after the
object has fallen out of scope?

Just a note that you don't actually need to dispose datatable, but it is a
good practice.
And yes, dispose it when you are done with it (form's dispose might be a
good place if you can't dispose it earlier)

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

I have a list box on my form, but I need to databind it to a data table
that is a private member of the form's class... so I basically have

Public Class MyForm
priate m_MyTable as new datatable
End Class

now where would I properly dispose of this? In the finalize method? I am
loading the data for the table in a subroutine that is executed at form
load, of course all the commands tied to it are wrapped in using blocks,
but I cant wrap the table in that because it i put it in a using block
then databind it, of course it will disappear when it exits that block
and then the databinding is gone, so I made it at the class level instead
and want its life time to be that of the form.. thanks!

 

[Miha Markic]

Finalize is a place for disposing *unmanaged* controls.
Furthermore, controls placed on form are disposed automatically when form is
disposed, so no action is required.

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

what about in a custom control? should it be in the dispose method or
finalize method? I remember this is a difference between them, i believe
that dispose is immediate and finalize can happen at any time after the
object has fallen out of scope?

Just a note that you don't actually need to dispose datatable, but it is
a good practice.
And yes, dispose it when you are done with it (form's dispose might be a
good place if you can't dispose it earlier)

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

I have a list box on my form, but I need to databind it to a data table
that is a private member of the form's class... so I basically have

Public Class MyForm
priate m_MyTable as new datatable
End Class

now where would I properly dispose of this? In the finalize method? I am
loading the data for the table in a subroutine that is executed at form
load, of course all the commands tied to it are wrapped in using blocks,
but I cant wrap the table in that because it i put it in a using block
then databind it, of course it will disappear when it exits that block
and then the databinding is gone, so I made it at the class level
instead and want its life time to be that of the form.. thanks!

 

[Cor Ligthert [MVP]]

Miha,

Not only on forms, this is as well for components or whereever there where
Idisposible is nice implemented.

I assume you knew this, so for the OP.

Cor

Finalize is a place for disposing *unmanaged* controls.
Furthermore, controls placed on form are disposed automatically when form
is disposed, so no action is required.

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

what about in a custom control? should it be in the dispose method or
finalize method? I remember this is a difference between them, i believe
that dispose is immediate and finalize can happen at any time after the
object has fallen out of scope?

Just a note that you don't actually need to dispose datatable, but it is
a good practice.
And yes, dispose it when you are done with it (form's dispose might be a
good place if you can't dispose it earlier)

--
Miha Markic [MVP C#, INETA Country Leader for Slovenia]
RightHand .NET consulting & development www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/

I have a list box on my form, but I need to databind it to a data table
that is a private member of the form's class... so I basically have

Public Class MyForm
priate m_MyTable as new datatable
End Class

now where would I properly dispose of this? In the finalize method? I
am loading the data for the table in a subroutine that is executed at
form load, of course all the commands tied to it are wrapped in using
blocks, but I cant wrap the table in that because it i put it in a
using block then databind it, of course it will disappear when it exits
that block and then the databinding is gone, so I made it at the class
level instead and want its life time to be that of the form.. thanks!

 

[Cor Ligthert [MVP]]

Smokey,

In the Data namespace there is only one thing that can be disposed, which is
up to you and that is the connection. As you use the using clause it is even
astatically disposed.

Dispose is not (read not) the same as finalizing, you are using managed
code, it is setting the object ready for removing by the GC. Some people
think that how quicker they do that how better. If there is no need for
extra resources, it is the opposite. So let your managed code do the work,
and interfere not in that what the developers by Microsoft made for you.

Cor

 

[Miha Markic]

Smokey,

In the Data namespace there is only one thing that can be disposed, which
is up to you and that is the connection. As you use the using clause it is
even astatically disposed.

Dispose is not (read not) the same as finalizing, you are using managed
code, it is setting the object ready for removing by the GC.

No, Dispose doesn't affect the GC for the instance where Dispose is called
in any way whatsoever.
IOW if you call someobject.Dispose() it won't affect the GC for someobject.

Some people

think that how quicker they do that how better. If there is no need for
extra resources, it is the opposite. So let your managed code do the work,
and interfere not in that what the developers by Microsoft made for you.

I assume you are talking about Data namespace where Dispose usually does not
very much.
However, in general, Dispose has to be called to release resources.
Furthermore even on classes that doesn't handle unmanaged code directly the
Dispose might be of help. It might set references to other objects to null
thus leaving those objects for garbage collection.
Basically I recommended to call Dispose always when IDisposable is involved.
Even if you know that Dispose does nothing the situation might change in the
future.

 

[Cor Ligthert [MVP]]

Miha,

Even if you know that Dispose does nothing the situation might change in
the future.

Yea the same with the + sign, maybe it subtracts in future,

Both the VB and the C# team take a lot of time to see that there are no
breaking change, they surely won't do that in the case of the Dispose.

Cor

 

[Miha Markic]

Both the VB and the C# team take a lot of time to see that there are no
breaking change, they surely won't do that in the case of the Dispose.

What exactly have language teams with BCL implementation (IOW Dispose
implementation)? And what do they have with 3rd party software Dispose
implementation?
You are certainly not saying that language teams control Dispose
implementation of all classes on the world, do you?

 

[Jack Jackson]

Smokey,

In the Data namespace there is only one thing that can be disposed, which is
up to you and that is the connection. As you use the using clause it is even
astatically disposed.

How do you know this? Is it documented anywhere?

I have been disposing all of the Data namespace items because I didn't
know if I needed to to not.

 

[rowe_newsgroups]

What exactly have language teams with BCL implementation (IOW Dispose
implementation)? And what do they have with 3rd party software Dispose
implementation?
You are certainly not saying that language teams control Dispose
implementation of all classes on the world, do you?

Miha - just as a warning - I along with many others have been down
this path with Cor quite a few times to no avail. You're welcome to
keep trying but I doubt anything will change.

Thanks,

Seth Rowe

 

[Miha Markic]

Miha - just as a warning - I along with many others have been down
this path with Cor quite a few times to no avail. You're welcome to
keep trying but I doubt anything will change.

Yes, yes, I know. I am actually not trying to go that path. I just can't
let false statements about disposing flow here.
There is already so much Dispose/GC misunderstandings all over the
community...

 

[Brian Gideon]

Dispose is not (read not) the same as finalizing, you are using managed
code, it is setting the object ready for removing by the GC. Some people
think that how quicker they do that how better. If there is no need for
extra resources, it is the opposite. So let your managed code do the work,
and interfere not in that what the developers by Microsoft made for you.

In most cases it is imperative to call Dispose as soon as the object
is no longer needed. An argument could be made that a DataTable is an
excpetion to that rule, but a FileHandle, IDbConnection, and the like
are not.

The canonical implementation of Dispose will only prevent the GC from
calling Finalize via GC.SuppressFinalize. Other than that the garbage
collection process is same as with any other class.

Also, are you saying that it is better to avoid calling Dispose?

Brian

 

[Cor Ligthert [MVP]]

Brian,

I am not saying it is better, I see this however often in relation with
cleaning memory.

Cleaning memory takes time and gives nothing back. So let it be done in the
proper time, when there is nothing else to be done, something the GC is
standard doing.

Cor

 

[AMoose]

Cor,

Can you provide a link to documentation where it states that the GC does
cleanup when there is nothing else to be done?

Thanks
Moose

 

[Miha Markic]

Hi Brian,

The canonical implementation of Dispose will only prevent the GC from
calling Finalize via GC.SuppressFinalize. Other than that the garbage
collection process is same as with any other class.

Not exactly true. SuppressFinalize is only required if a finalizer is
implemented. And you need a finalizer only when you are dealing with
unmanaged memory which is very rare. Thus the canonical implementation is to
dispose child objects and nothing more.

 

[Miha Markic]

Brian,

I am not saying it is better, I see this however often in relation with
cleaning memory.

Cleaning memory takes time and gives nothing back.

Well, it gives back free memory

So let it be done in the

proper time, when there is nothing else to be done, something the GC is
standard doing.

The only relation between Dispose and cleaning memory/GC is in the fact that
Dispose implementation *might* release references to objects. Dispose
doesn't affect the scheduling of GC.

 

[Miha Markic]

Cor,

Can you provide a link to documentation where it states that the GC does
cleanup when there is nothing else to be done?

GC does cleanup when it decides to do it. It has a built in smart scheduler
that should do in most cases.

 

[AMoose]

True.

But its been my experience that the GC does most of its cleanup when there
is some level of memory pressure, not when "there is nothing else to be
done".

Matter of fact I had an application that opened a file, it set the file
object to nothing (ready for cleanup by the gc) but failed to do a close or
dispose. But because there was little activity on the machine, lots of free
memory, and the application wasn't causing sufficient memory pressure, the
gc never cleaned up the "dead" file object that still had the underlying
file open. There was definitely "nothing else to be done" on the machine and
within the application process, but the GC did not clean up the object.

In contrast, on a busy server you will often see the GC run more often
because of the need to clean resources.

So in my experience it has been the opposite of what Cor has said, and from
everything I read you cannot predict when the GC will run, so I was just
asking Cor for some reference material to back up his statement. Do know if
what Cor said is true?