Disposing dataview

[John]

Hi

I am using a data view as; Dim dv As New DataView(ds.Job_Types). What are
the correct step to dispose and clear the resources being used by dv?

Thanks

Regards

 

[William Ryan eMVP]

Hi John:

Hi

I am using a data view as; Dim dv As New DataView(ds.Job_Types). What are
the correct step to dispose and clear the resources being used by dv?

Thanks

Regards

Val answered your question and I absolutely agree. I'm wondering though, is
your question about object cleanup in general or is it specific to a
DataView? If it's the first, then I don't have anything to add. However if
there's something specific about a DataView that you have a questino about,
let me know. I only ask b/c they are a little different from many other
objects in that they're based on a DataTable, their only real usefulness is
within the context of a datatable but if you dispose of it there's no
effect on the datatable.

Bill

 

[Val Mazur]

Hi John,

According to the documentation even if you do not dispose it, garbage
collector will clear memory anyway when object is out of scope. But my
personal opinion is to use Dispose method anyway and setting variable to
Nothing is the best way to do the job

dv.Dispose
dv=Nothing

 

[Cor Ligthert]

Hi Val,

dv.Dispose

This means, do an extra action to place the managed resource dataview at the
garbagde, do not wait for the managed system.

dv=Nothing

Set the reference of the disposed dataview to nothing.

Are you paid per line?

(Although this will not be recoginized, I think this makes the program only
slower)

Cor

 

[Cor Ligthert]

Hi Bill,

See my comments at Val

Cor

 

[Miha Markic [MVP C#]]

Hi Cor,

Hi Val,


This means, do an extra action to place the managed resource dataview at the
garbagde, do not wait for the managed system.

Actually, this means dispose all the resources used (both unmanaged and
managed).
The finalizer won't dispose the managed resources.

 

[Cor Ligthert]

Hi Miha,

In my humble opinion I see not any reason to dispose a dataview.

In the language.vb general group was an arguing about the connection and I
know that there are unmanaged resources in. Angel has said in this newsgroup
you should dispose that because of the connection pooling. And he gave an
example. I said I did not need that when you say that I believe you. (And I
know that the connection seems to be a simple wrapper about the connection
API).

However Marina did after that I told it to here in the language.vb group,
check it, and could not find any reasons to dispose the connection on her
server. That while she had made a lot of connections which where automaticly
closed on the server and she did keep all the time 2 connections open. (You
know that Marina and I stand side by side about the overdoing of disposing).

Although in my opinion is managing "managing" is always said you have to
dispose unmanaged resources. And now comes my problem, as I said managing is
managing, what means controling resources in my opinion. It is crazy that
you can manage unmanaged resources. (I can think about not so well done
implementations as Angels in a way stated, nothing is perfect).

However even if that would be clear that you have to dispose unmanaged
resources which are managed by the framework. What can than be the unmanaged
resource in a Dataview.

I am curious to your reaction

Cor

 

[Val Mazur]

Hi Cor,

Of course disposing will not come for free, but it is not a huge time and
you will benefit, since you will know for sure, that application released
resources. It is just good programming practice. If you do not care about
it, then leave it as is

 

[Miha Markic [MVP C#]]

Hi Cor,

Calling Dispose is good even if it does nothing.
The reason is that you never know what the future brings.
BTW, I normally didn't care about calling Dispose myself.
But puting it in that way changed my way of doing Dispose.

 

[Cor Ligthert]

Of course disposing will not come for free, but it is not a huge time and
you will benefit, since you will know for sure, that application released
resources. It is just good programming practice. If you do not care about
it, then leave it as is

Hi Val,

This is very bad programming practise.

Or do you also make this kind of instructions

a = b + c
If a <> b + c then messagebox.show ("the addition went wrong")

And than you say, of course dit not come for free, but it is not a huge time
and
you will benefit, since you will know for sure, that the addition went
right..

Than I understand it.

Cor

 

[Cor Ligthert]

Hi Miha,

See my answer to Val

Cor

 

[Miha Markic [MVP C#]]

HI Cor,

Hi Val,

This is very bad programming practise.

Actually it is a very good defensive practice.

Or do you also make this kind of instructions

a = b + c
If a <> b + c then messagebox.show ("the addition went wrong")

In the case of doubles it won't work ;-)

 

[Cor Ligthert]

Hi Miha,

In the case of doubles it won't work ;-)

I did let it special open to let you and Val give this kind of answer.



And I was tooo thinking there was something wrong (there is in my opinion
still a strange operater behaviour in VB). However apart from what I
described there seems to be technical nothing wrong in this coding.

And about defending programming, when you as me have once in your live bring
programs back from thenthousands of rows to programs from 200 rows just
because the rest was only "nothing" doing defending rows as I showed, you
will find all useless defending programming bad practise.

You should have seen maybe too that I also stated often here to use only a
try catch block when you are unable to catch that with a normal "if" (And
that is in ADONET or file handling often).

However this goes (before you write it, with option strict on)

Dim a, b, c As Double
b = 2
c = 3
a = b + c
If a = b + c Then MessageBox.Show(a.ToString)



Cor

 

[Val Mazur]

Hi,

Cleaning after yourself is not a bad practice. If you DO NOT clean after
your self, then this is a bad practice. It does not mean that garbage
collector will not do it later on, but using explicit code gives you more
control and less potential memory leaks

 

[Cor Ligthert]

Cleaning after yourself is not a bad practice. If you DO NOT clean after

your self, then this is a bad practice. It does not mean that garbage
collector will not do it later on, but using explicit code gives you more
control and less potential memory leaks

Hi Val Mazur,

With this you are saying in my opinon that it is needed to control yourself
all managed resources because the Microsoft managed code is not save.

The same as checking if a calculation is done right, afterwards, which you
did not answer in the message by the way, is that your style, not answering
questions?

And when you are so in doubt in the functions of Microsoft code, how do you
be so sure the dispose works, should that not be checked?

I told you already that I have more trust than you in the code from
Microsoft and only will check when there is a bug, what in my opinon is
always a possibility in code, however needs only to a workaround when you
know it

Cor

 

[Guest]

With this you are saying in my opinon that it is needed to control yoursel

all managed resources because the Microsoft managed code is not save

This is not true. By implementing IDispose a developer's intent is to give a user a way to clean up the object immediately and not wait for GC, and usually for a specific reason. That waiting for the GC to clean up this object may have side effects. Two side effects are needless code execution while the object is waiting to be cleaned up (which is why dataview implements IDispose by the way) and deterministic memory release. Also if the object implements the finalize method it can be about improving the GC performance also

The same as checking if a calculation is done right, afterwards,

Not its not. That has nothing to do with IDispose. IDispose is about avoiding non-deterministic clean up and avoiding side effects. Your example has nothing to do with either of those

I have more trust than you in the code from Microsof

Its not about GC trust. I know the object will be cleaned up sometime, but in the mean time the object may be repsonding to events and doing processing, it may be holding onto valuable resources, you don't know what the object may be doing

You know why dataview calls dispose? Because there is a member that has registered to ~6 events in the datatable and that member also hands its reference off to the datatable for who knows what but probably for callbacks. So while the dataview is waiting to be cleaned up, that dataview and its member may be responding to events from the datatable and doing needless processing. So which is worse? Needlessly responding to these events while waiting to be cleaned up, or calling IDispose and incur the unregistering events code hit up front? This needless reponding to events may not be just about extra processing but actual bugs. I have seen code where the developer thinks the object is dead but is still responding to events and executing code that had no right to still be executing

only will check when there is a bu

Talk about bad programming practice. I pray that you are not developing air traffic control systems or banking software

From my view there are three approaches to take. Always call dispose, always wait and let the GC clean up, or approach each dispose situation individually and examine the IL source/source/profile(if you don't have the code) to see if you should call dispose or not in the specific situation.

If you always wait for the GC, bugs can and will arise in your code, thats a fact just read the newsgroups for awhile. Not calling dispose leaves a large unknown in your code and that is dangerous. Knowing this but still not calling dispose and putting this code in release is BAD programming and unacceptable

If you always call IDispose you incur some overhead upfront but that overhead would be done anyways later on. You also remove that unknown I mentioned earlier. Also if the object implements the finalize method then calling dispose can have a positive performance impact on the GC during cleanup.

The last choice is probably good for any developer who wants to know exactly whats going on at every step in their code, and wiegh the consequences of not calling Dispose upfront. But even if you know whats going on in this version of the code, how do you know it will be the same in the next version. This programming decision can become a maintainence nightmare and can cause bugs in future versions

So when it comes down to it I vote for calling dispose regardless

 

[Val Mazur]

I did not say that Managed code is not save, but using explicit disposing
will give you advantage when you need to clean memory for other use.

 

[Cor Ligthert]

Hi Val,

I did not say that Managed code is not save, but using explicit disposing
will give you advantage when you need to clean memory for other use.

Are we living in the 70's

I also find disposing right when we are talking about huge consuming memory
objects as images (and I thought that the image has a side effect that it
locks the stream, that are those rare situations I talked about before).

I never said you should never dispose I can think of a lot of situations.

However the dataview is nothing more than a referencing object to a
datatable.

And that was where we where talking about.

Cor

 

[Guest]

Any object that implements finalize will be dramatically slower than a
object that doesn't when it comes to GC. This is true whether the object ha
wrapped an unmanaged resource or not. If the object implements the IDispos
interface to do the resource cleanup and also calls the GC.SuppressFinalize
and the users call the dispose method, this will improve the GC performance

Any object that implements the finalize method, whether the object ha
wrapped an unmanaged resource or not, will at least go through two rounds o
garbage collections to be collected. The time between the moment when the G
detects an object as unreachable and the call to the finalize method i
indeterminate and can be a long time, and in theory, possible that it neve
gets called

Finalization is expensive and should be avoided. IDispose helps this

So not calling dispose hinders performance, scalability, and canno
guarantee that resources actually get cleaned up including the objec
itself. No matter if there unmanaged resources or not, and no matter the
size of the unmanaged resources

While on the other hand calling dispose improves performance, scalability
assures that the resources actually do get cleaned up

Sounds like calling dispose is good thing to me, and should be called all the
time for any objects that implement it, unless for specifc reasons. Not the
other way around

 

[Guest]

And concerning dataview specifically, the user should call dispose. The example below shows that even though setting the dataview object to nothing, it still listening and repsonding to events within the datatable. Calling IDispose unhooks the events. Do you really want the object still doing processing even though you set it to nothing

Imports System.Dat
Imports System.ComponentMode

Module Module

Public Class MyDataVie
Inherits DataVie

Protected Overrides Sub ColumnCollectionChanged(ByVal sender As Object,
ByVal e As CollectionChangeEventArgs
Console.WriteLine("Column changed"
End Su
End Clas

Sub Main(

Console.WriteLine("-----------------------------------------------------------"
Console.WriteLine("Test Case - Still listenting and responding even though "
Console.WriteLine(" object is nothing"
Console.WriteLine("-----------------------------------------------------------"
Dim MV As New MyDataVie
Dim DT As New DataTable("MyTable"
MV.Table = D
MV = Nothin
DT.Columns.Add(New DataColumn("SomeColumn")

Console.WriteLine("-------------------------------------"
Console.WriteLine("New Test Case - IDispose"
Console.WriteLine("-------------------------------------"
Dim MV2 As New MyDataVie
Dim DT2 As New DataTable("MyTable"
MV2.Table = DT
MV2.Dispose(
MV2 = Nothin
DT2.Columns.Add(New DataColumn("SomeColumn")

End Su

End Module