Disposing dataview

  • Thread starter Thread starter John
  • Start date Start date
Hi IdoNotKnowWhoThisIs.

When you make samples, make them than right
MV.Table = DT
MV = Nothing
Click to expand...

You set here a reference in the table.
To remove this reference you should not set the dataview to nothing..

You should set the table reference to nothing,
MV.Table = Nothing

It looks if you want to use dirty programming, maybe you can use for that
the dispose and than everytime construct a new object. However that I do not
know.

I hope this helps?

Cor
 
How do you know that "MV.Table = Nothing" clears everything that the Dispose method does?

Table is only one property. For every property you set in the dataview are going to go through and set all those properties to Nothing also before setting the dataview to nothing? What happens if you send the dataview to another method which sets up more properties, are you going to take responsibility to set all those properties to nothing also?

What happens if while working with the dataview object and it internally hooks up more events that you don't know about, and you only call "MV.Table = Nothing", isn't still possible that some of those events are still hooked up

For every object that implements IDispose that doesn't have a managed resource, are you going to make sure all relevant properties are set to nothing before setting the objects referenece to nothing? Instead of calling the Dispose method

The developer has implemented IDispose so when you are done with the object you call the dispose method to totally clean up all properties and events before being set to nothing. This isn't dirty programming, its called encapsulation and you the user don't have to know which properties to clean up and which ones don't. You just call Dispose
 
Hi Somebody,

No that is the difference between you and me, I do not care about that, I
trust the managed system Microsoft made. What Val too said in this thread
by the way.

And when I needed to set a property to nothing, I do it in the right way.
Not by trying to set a top reference to nothing while the rest stays on the
managed heap.

Cor
 
No that is the difference between you and me, I do not care about that,
trust the managed system Microsoft made. What Val too said in this threa
by the way
Click to expand...

I have said that I trust MS also but thats not the point. In the current CLR written by MS, the finalization method has a huge impact on the performance, it is expensive, the CLR architects have written about this over and over again. They also state the finalize method may not be called for a long time even though the object could have been GC'd along time ago, so you are not guaranteed that the resources will be cleaned up soon or ever.

If calling dispose improves performance, scalability, and gaurantees that the resource will be cleaned up, while choosing to not call it does not provide any of those things, then why would you not call it? What is the reasoning
And when I needed to set a property to nothing, I do it in the right way
Not by trying to set a top reference to nothing while the rest stays on th
managed heap
Click to expand...

So you are telling me that for every object that you create in your code, you go through and set all its properties to Nothing? You must write a lot of code

Setting SomeDataView.Table = Nothing does not take the table off the managed heap. It only sets the dataview's member reference to the table to nothing. There could be other references to the same table elsewhere so the table may be around a lot longer than the dataview. Thats why the developer wants you to call the Dispose method, to have the dataview that you have a reference to, to unsubscribe from the datatable's events.

How do you know that setting the SomeDataView.Table = nothing does the same thing as SomeDataView.Dispose? You don't without looking at the code. This breaks encapsulation and is bad programming.

The Table property means set/get an internal property to some value. Nothing more, nothing less, it does not mean clean up. Dispose means do a total clean up of the internals of the dataview. So when you are done with an object should you go through and set all its properties to Nothing which does not gaurantee total clean up? Or should you call a sinlge method that means exactly what its name implies, total clean up?
 
Trol

What??? Please explain to me how I am a troll????? What part of my messages deserve this type of response? Seriously, I would like to know
 
Hey Cor,

SomebodyElse says this:

Dim MV As New DataView
Dim DT As New DataTable("MyTable")
MV.Table = DT
'do some work here
MV.Dispose()
MV = Nothing
'the existing datatable is kept around
'to do some more work
DT.Columns.Add(New DataColumn("SomeColumn"))

SomebodyElse says to call the Dispose is needed
because MV will keep responding to events of the
DT object, which is true.

You say:

Dim MV As New DataView
Dim DT As New DataTable("MyTable")
MV.Table = DT
'do some work here
MV.Table = Nothing
MV = Nothing
'the existing datatable is kept around
'to do some more work
DT.Columns.Add(New DataColumn("SomeColumn"))

Why the extra call to MV.Table = Nothing exactly?
Isn't your call to MV.Table = Nothing have the
same purpose as SomebodyElse's call to MV.Dispose()?
To unregister the events or help to clean up and not
rely on the asynch garbage collection?

Because looking at the IL code of the dataview, the
call to MV.Table = Nothing and the call to MV.Dispose()
basically do the same code underneath, that is call
System.Data.DataViewListener::UnregisterMetaDataEvents
with the existing table.

Surely the call MV.Table = Nothing is not needed to clean
up managed resources. Because doesn't the managed
environment, take care of the clean up for me? I mean
I don't do this code ever:

Dim SomeObj as Object = new Object()
AL.Add(SomeObj)
AL.Add(SomeObj)
AL.Add(SomeObj)
'Do some work
AL(0) = Nothing
AL(1) = Nothing
AL(2) = Nothing
AL = Nothing
'Do some more work with SomeObj

I just write AL = Nothing and the managed environment
takes care of everything else for me.

Val wrote this earlier:
dv.Dispose
dv=Nothing
And your quote was "Are you paid per line?"

Isn't your code
MV.Table = Nothing
MV = Nothing
The same thing?

AH
 
Hi Anonymous,

I do not do that setting to nothing, I only said that the sentence from
Somebodyelse had no sense.

With his program, he said he proved that when you did not do the dispose,
the reference to the table would persist. That was in this situation because
there is a persistent reference to that table.

When you change that in the way I showed, you would see that that reference
from the table to the dataview is gone.

It was only to show that in my opinion the test sample had a major error. I
set seldom things to nothing. (In a dataview this would be possible when
there would be the need to add other tables).

That is what I tell all the time in this thread, however "somebodyelse"
tries to change my words and is now telling that I set all things to
nothing.

In the start of the thread I said that it was useless to dispose the
dataview AND set after that the reference from that dataview to nothing.
Which I did not write, however find even crazier.

I hope this explains it a little bit.

Cor
 
Hey Cor,
It was only to show that in my opinion the test sample had a major error.
Click to expand...

I do not think his example had a major error.

Here is another example, I could have a dataset in memory with a single
table in a regular windows application. In one dialog I use a dataview to
view that data in a specific way. At the end of the dialog I want to get rid
of the dataview but I want to keep the dataset and its table cached in
memory because I'm still working with the data. If you just set the dataview
to nothing, it would still be responding to any events from the datatable
kept in cache until its GC'd. This is exactly like SomebodyElse's example
and is proven by SomebodyElse's example.

Before setting the dataview to nothing at the end of the dialog you would
either (A) have to call the dataview's dispose so it unhooks itself from
cached table's events or (B) set the dataview table property to nothing so
it unhooks itself from cached table's events. If you don't do (A) or (B) the
dataview still has a reference to the datatable until its GC'd at some point
in the future but in the mean time would still be responding to the
datatable's events. So you are forced to to do (A) or (B) before setting the
dataview to nothing, for the same reason, to clean up the dataview. There is
no difference.

If you look at the IL code for setting a dataview's table property to
Nothing and the call to dataview's Dispose method, setting the table
property to Nothing actually does more work than the dispose! The dispose
actually does a small subset of the same logic in the dataview's table
property set method when value being set is Nothing.


AH
 
Hi Anonymous,

Again as long as there is a reference on the managed heap the object will
stay (until there is a garbage action)

So when you do not remove that reference that will stay, what other
reference you are setting to nothing that you think that has someting to do
with it.

When you dispose the complete object it will run the disposing routine (as
all classes derived from the MarshalByComenent have). However in my opinion
is the fact that something is inherrited from a higher class not the reason
that it should be used.

I never saw that by instance stated with the memberwiseclone.

I hope that this clears it something what I try to say.

Cor
 
I hope that this clears it something what I try to say.

Unfortunately no. It doesn't look like I'm getting my points across either.
I'm calling it quits.
 
Back
Top