CommandBuilder.Dispose - should I use it?

[Ed]

I just learned how to use the Commandbuilder and have
researched it a little bit further and see that there is a
dispose property. Should this be used after invoking the
command builder or does vb.net cleanup after itself on its
own? If I don't use it would this lead to a memory leak?

TIA,
Ed

[Sahil Malik]

This brings up a vast topic of "How memory handling works in .NET".

First of all - try not to use CommandBuilder, it's not the recommended
approach unless your application is aimed to be quick and dirty.

Secondly - Dispose is thanks to IDisposable, all expensive objects must
implement dispose. Calling dispose will immediately ask the object to clean
itself. The other option is Finalize - which is well equal to the destructor
with a difference that you donot know when it will be called. It is
eventually called by the garbage collector, but you don't know when that
will happen and you cannot determine that with any degree of certainity.

Therefore, if an object exposes a dispose - call it when ur done with it.

Will not calling it result in a memory leak? It could .. though restarting
ur app will fix that to some extent and call the finalizers on each of the
objects, but thats not good either.

- Sahil Malik
Independent Consultant
You can reach me thru my blog - http://dotnetjunkies.com/WebLog/sahilmalik/

"Ed" <an*******@discussions.microsoft.com> wrote in message
news:1c*****************************@phx.gbl...

I just learned how to use the Commandbuilder and have
researched it a little bit further and see that there is a
dispose property. Should this be used after invoking the
command builder or does vb.net cleanup after itself on its
own? If I don't use it would this lead to a memory leak?

TIA,
Ed

[Ed]

Thanks for your reply. Someone suggested I could use the
commandbuilder for the InsertCommand of the dataAdapter
object. My issue is/was that I felt I was writing too
many line of code for sqlParameters for the InsertCommand.

sqlParm = sqlDa.Parameters(New SqlParameter("@fld0",
Nvarchar (50), "fld0")
....
sqlParm = sqlDA.Parameters(New SqlParameter("@fld40",...)
....

The commandBuilder looked/looks quite appealing instead of
writing a bunch of extra lines of code as above.

So I suppose it would be a good idea to call Dispose when
I am done inserting data.

Thanks,
Ed

-----Original Message-----
This brings up a vast topic of "How memory handling works in .NET".
First of all - try not to use CommandBuilder, it's not the recommendedapproach unless your application is aimed to be quick and dirty.
Secondly - Dispose is thanks to IDisposable, all expensive objects mustimplement dispose. Calling dispose will immediately ask the object to cleanitself. The other option is Finalize - which is well equal to the destructorwith a difference that you donot know when it will be called. It iseventually called by the garbage collector, but you don't know when thatwill happen and you cannot determine that with any degree of certainity.
Therefore, if an object exposes a dispose - call it when ur done with it.
Will not calling it result in a memory leak? It could .. though restartingur app will fix that to some extent and call the finalizers on each of theobjects, but thats not good either.

- Sahil Malik
Independent Consultant
You can reach me thru my blog - http://dotnetjunkies.com/WebLog/sahilmalik/
"Ed" <an*******@discussions.microsoft.com> wrote in messagenews:1c*****************************@phx.gbl...

I just learned how to use the Commandbuilder and have
researched it a little bit further and see that there is a dispose property. Should this be used after invoking the command builder or does vb.net cleanup after itself on its own? If I don't use it would this lead to a memory leak?
TIA,
Ed

.

[Cor Ligthert]

Hi Ed,

When your programs have no troubles why would you not use the
commandbuilder, it has bugs however there are more parts in dotNet which
have bugs, so should that mean you should not use them. (The most terrible
one with bugs is that nice control the combobox). Therefore you should test
every program again and again.

The dispose should be used when there are unmanaged resources.

There are texts to use it always when it is implemented as a method, because
there is nothing wrong to do that. That is for me the same sentence as that
it does nothing wrong to set every value to zero before you close your
program. A lot of dispose are in a classes because it comes from a derived
class as the component class. (By instance every label has it).

Really separatly adviced it is with:
When you implements unmanaged resources in your classes.
Bitmaps
Dialogforms
Connections with more than 100 connections on a network (instead of close,
the dispose is here removing the connection string and probably something
extra in that method what is not dispose, however used by the devellopers to
reset the connectionpool).

I hope this helps?

Cor