Finalize and database connection... contradiction in msdn or a misunderstaning from my part ?

[Joe Abou Jaoude]

hi,

I have a component that uses a database connection.

In the finalizer I dispose the connection because I read in msdn the
following:

"A type must implement Finalize when it uses unmanaged resources such as
file handles or database connections that must be released when the
managed object that uses them is reclaimed."

but this resulted in the folowing exception:
Run-time exception thrown : System.InvalidOperationException - Handle is
not initialized.

Then while reading in msdn to see what might be causing this exception I
read the folowing :

"Do not call Close or Dispose on a Connection, a DataReader, or any
other managed object in the Finalize method of your class."

Is there a contradiction in msnd , or have I understood wrong ?
are handles file and database connections unmanaged ressources used in a
managed object or what ?

And another question:
I know that GC works when the more the memory is loaded. But is there a
memory limit for an application, or can it use all the PC memory ?

Regards

*** Sent via Developersdex http://www.developersdex.com ***

[Stephany Young]

No. There is no contradiction.

One statement is talking about UNMANAGED resources and the other is talking
about MANAGED objects.

I am sure there are a lot of subtleties about what ia a managed object and
what is an unmanaged resource, but the rule of thumb I apply is that if an
object is an instance of a class, etc. that is provided by or derived from
the framework then it is managed, otherwise it is unmanaged (e.g. a handle
or other resource obtained by calling an API function directly).
"Joe Abou Jaoude" <an*******@devdex.com> wrote in message
news:uI**************@tk2msftngp13.phx.gbl...

hi,

I have a component that uses a database connection.

In the finalizer I dispose the connection because I read in msdn the
following:

"A type must implement Finalize when it uses unmanaged resources such as
file handles or database connections that must be released when the
managed object that uses them is reclaimed."

but this resulted in the folowing exception:
Run-time exception thrown : System.InvalidOperationException - Handle is
not initialized.

Then while reading in msdn to see what might be causing this exception I
read the folowing :

"Do not call Close or Dispose on a Connection, a DataReader, or any
other managed object in the Finalize method of your class."

Is there a contradiction in msnd , or have I understood wrong ?
are handles file and database connections unmanaged ressources used in a
managed object or what ?

And another question:
I know that GC works when the more the memory is loaded. But is there a
memory limit for an application, or can it use all the PC memory ?

Regards

*** Sent via Developersdex http://www.developersdex.com ***

[Joe Abou Jaoude]

hi stephany,
I agree with u that one statement is talking about UNMANAGED resources
and the other is talking about MANAGED objects....

But is the database connection a managed or unmanaged object ?
Basically, It should be considered as a managed object since it's an
instance of a class provided by the .Net framework.

However when reading this in msdn "A type must implement Finalize when
it uses unmanaged resources such as file handles or database connections
that must be released when the managed object that uses them is
reclaimed." I don't know what to think , because I don't think that a
database connection is obtained by calling an API
*** Sent via Developersdex http://www.developersdex.com ***

[Stephany Young]

You've answered your own question:

'considered as a managed object since it's an instance of a class provided
by the .Net framework'

If your database connection object uses any unmanaged resources then it
already knows about them and will implement Finalize to release them and you
dont not have to worry about this.

What it really means is that if you write your own class, 'Widget', that
obtains and holds an unmanaged resource then you are responsible for
releasing it by implementing Finalize.

Air Code:
---------
Class Widget

Private handle as IntPtr

Sub New()
' Obtain a handle to an unmanaged resource
GetHandle(handle)
End Sub

Protected Sub Finalize()
' Release the unmanaged resource
CloseHandle(handle)
End Sub

End Class

Get the picture?
"Joe Abou Jaoude" <an*******@devdex.com> wrote in message
news:ub**************@tk2msftngp13.phx.gbl...

hi stephany,
I agree with u that one statement is talking about UNMANAGED resources
and the other is talking about MANAGED objects....

But is the database connection a managed or unmanaged object ?
Basically, It should be considered as a managed object since it's an
instance of a class provided by the .Net framework.

However when reading this in msdn "A type must implement Finalize when
it uses unmanaged resources such as file handles or database connections
that must be released when the managed object that uses them is
reclaimed." I don't know what to think , because I don't think that a
database connection is obtained by calling an API
*** Sent via Developersdex http://www.developersdex.com ***

[Dennis]

You are then saying that a graphics object created with the .CreateGraphics
method and the associated Pens and Brushes you use need not be disposed since
they will be disposed by the Finalize method of the class they are used in
which, from what I read, is correct but it is recommended that you dispose of
them as soon as you are finished with them and many on thie newsgroup also
advocate disposing of them rather than relying on the Finalize method.

A question, if you open a database (conn.open) then if you close it
(conn.close) you can reopen it at any time within the same scope using
conn.Open again. However, if you close it (conn.dispose), you can't reopen
it unless you re-instantiate it..is this correct?

"Stephany Young" wrote:

You've answered your own question:

'considered as a managed object since it's an instance of a class provided
by the .Net framework'

If your database connection object uses any unmanaged resources then it
already knows about them and will implement Finalize to release them and you
dont not have to worry about this.

What it really means is that if you write your own class, 'Widget', that
obtains and holds an unmanaged resource then you are responsible for
releasing it by implementing Finalize.

Air Code:
---------
Class Widget

Private handle as IntPtr

Sub New()
' Obtain a handle to an unmanaged resource
GetHandle(handle)
End Sub

Protected Sub Finalize()
' Release the unmanaged resource
CloseHandle(handle)
End Sub

End Class

Get the picture?
"Joe Abou Jaoude" <an*******@devdex.com> wrote in message
news:ub**************@tk2msftngp13.phx.gbl...

hi stephany,
I agree with u that one statement is talking about UNMANAGED resources
and the other is talking about MANAGED objects....

But is the database connection a managed or unmanaged object ?
Basically, It should be considered as a managed object since it's an
instance of a class provided by the .Net framework.

However when reading this in msdn "A type must implement Finalize when
it uses unmanaged resources such as file handles or database connections
that must be released when the managed object that uses them is
reclaimed." I don't know what to think , because I don't think that a
database connection is obtained by calling an API
*** Sent via Developersdex http://www.developersdex.com ***

[Stephany Young]

In a nutshell, yes that is what I am saying. BUT ... it's a bit more
complicated than that.

Factors like, the scope of an object, how long the life of an object is, how
instantiated objects impact on available resources and probably a whole raft
of other things that I can't think of right now.

Take the following procedure as an example:

Private Sub AAA()

Dim _w as Widget

_w = New Widget

Me.Label1.Text = _w.Description

End Sub

All you are doing is instantiating a Widget object, grabbing the value of
its Description property and forgetting about it. Because the object
variable _w is local to the procedure it will 'go out of scope' as soon as
the Ens Sub is executed. When it goes out of scope it will be automatically
disposed of and, at that stage, will become avaible for the Garbage
Collector to have its wicked way with it when it is ready.

Now add a call to a long running procedure after you have grabbed the
Description and before the End Sub.

Private Sub AAA()

Dim _w as Widget

_w = New Widget

Me.Label1.Text = _w.Description

LongRunningProcedure()

End Sub

The Garbage Collector might do its stuff a number of times before
LongRunningProcedure returns, but _w will still not be tidied up until
sometime after LongRunningProcedure returns and the End Sub is executed. So,
while LongRunningProcedure is executing, _w is just sitting there doing
nothing but occupying some resource.

if you so wish, and it is not mandatory to do so, you might 'dispose' of _w
early. One way of doing this is to set it to nothing. Another way, if the
Widget class implements the IDisposable interface, is to call its Dispose
method. Setting it to nothing tidies it up properly even it it doesn't
implement IDisposable.

Private Sub AAA()

Dim _w as Widget

_w = New Widget

Me.Label1.Text = _w.Description

_w = Nothing

LongRunningProcedure()

End Sub

or

Private Sub AAA()

Dim _w as Widget

_w = New Widget

Me.Label1.Text = _w.Description

_w.Dispose()

LongRunningProcedure()

End Sub

Now, if the Garbage Collector does it suff (and feels so inclined) while
LongRunningProcedure is executing, then it might tidy up _w.

I have no intention of getting into a discussion of what the Garbage
Collecter does or how it does it's stuff.

In normal circumstances one does not really have to worry about it. You
really only have to worry about it if there is a specific reason to do so.

As you can see it is an complex area that, in my opinion is worthy of a book
specfically about Dispose, Finalize and the Garbage Collector.

All you can really do is read as much as you can on the subject, decide what
is good advice, what is bad advice and make your own judgement calls.

Remember that just because you read it somewhare does not make it fact. Some
people advocate explicit disposing of everting all the time, others advocate
never explicitly disposing. I take the middle ground and use it when I
consider it appropriate to do so.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:00**********************************@microsof t.com...

You are then saying that a graphics object created with the
.CreateGraphics
method and the associated Pens and Brushes you use need not be disposed
since
they will be disposed by the Finalize method of the class they are used in
which, from what I read, is correct but it is recommended that you dispose
of
them as soon as you are finished with them and many on thie newsgroup also
advocate disposing of them rather than relying on the Finalize method.

A question, if you open a database (conn.open) then if you close it
(conn.close) you can reopen it at any time within the same scope using
conn.Open again. However, if you close it (conn.dispose), you can't
reopen
it unless you re-instantiate it..is this correct?

"Stephany Young" wrote:

You've answered your own question:

'considered as a managed object since it's an instance of a class
provided
by the .Net framework'

If your database connection object uses any unmanaged resources then it
already knows about them and will implement Finalize to release them and
you
dont not have to worry about this.

What it really means is that if you write your own class, 'Widget', that
obtains and holds an unmanaged resource then you are responsible for
releasing it by implementing Finalize.

Air Code:
---------
Class Widget

Private handle as IntPtr

Sub New()
' Obtain a handle to an unmanaged resource
GetHandle(handle)
End Sub

Protected Sub Finalize()
' Release the unmanaged resource
CloseHandle(handle)
End Sub

End Class

Get the picture?
"Joe Abou Jaoude" <an*******@devdex.com> wrote in message
news:ub**************@tk2msftngp13.phx.gbl...

>
>
> hi stephany,
> I agree with u that one statement is talking about UNMANAGED resources
> and the other is talking about MANAGED objects....
>
> But is the database connection a managed or unmanaged object ?
> Basically, It should be considered as a managed object since it's an
> instance of a class provided by the .Net framework.
>
> However when reading this in msdn "A type must implement Finalize when
> it uses unmanaged resources such as file handles or database
> connections
> that must be released when the managed object that uses them is
> reclaimed." I don't know what to think , because I don't think that a
> database connection is obtained by calling an API
>
>
> *** Sent via Developersdex http://www.developersdex.com ***

[Joe Abou Jaoude]

ok, thank u for ur time

*** Sent via Developersdex http://www.developersdex.com ***

[Cor Ligthert]

Dennis,

Not directly, did you try on a global created connection which is disposed
to add the connectionstring again. The dispose on the connection is
overloaded and removes the connectionstring.
Cor

[Jay B. Harlow [MVP - Outlook]]

Stephany,
| When it goes out of scope it will be automatically
| disposed of and, at that stage,
VB.NET 1.0 & 1.1 (VS.NET 2002 & 2003) does not "automatically dispose" of
anything! You need to manually call IDisposable.Dispose if you want the
object to be disposed of.

VB.NET 2005 supports the Using statement (ala C#'s using statement in VS.NET
2002 & 2003) which will support "automatically disposing" of objects that
implement the IDisposable interface.

| The Garbage Collector might do its stuff a number of times before
| LongRunningProcedure returns, but _w will still not be tidied up until
| sometime after LongRunningProcedure returns and the End Sub is executed
This is true for Debug builds (I don't remember if you need to be also
running under the debugger or not), however under Release builds the GC &
JIT sees that _w is no longer used & makes it eligible for collection!
Setting a variable to Nothing, does exactly that, sets the variable to
Nothing. My understanding it may actually hurt the GC's job in release
builds. In release builds the JIT & GC can determine when the variable is no
longer being used & if you wait until after LongRunningProcedure is finished
to set it to Nothing, the GC & JIT may think the object is still in use,
possibly causing it (the object) to be promoted to the 1st or 2nd generation
heap.
Based on a couple of discussions last couple of weeks I have started a list
of when to Call Dispose, actually its now a list of when its OK not to call
Dispose! As you should always explicitly call Dispose if the framework does
not implicitly call it for you! Which happens to be my new rule for calling
IDisposable.Dispose. However I've been busy & have not had a chance to
review the discussion publish a synopsis yet.
Some useful links on the GC:

http://msdn.microsoft.com/msdnmag/issues/1100/gci/
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/

http://msdn.microsoft.com/library/de...izeDispose.asp

Both of these blogs contain a plethora of articles on the GC:
http://blogs.msdn.com/ricom/
http://blogs.msdn.com/maoni/

Hope this helps
Jay
"Stephany Young" <noone@localhost> wrote in message
news:uh**************@tk2msftngp13.phx.gbl...
| In a nutshell, yes that is what I am saying. BUT ... it's a bit more
| complicated than that.
|
| Factors like, the scope of an object, how long the life of an object is,
how
| instantiated objects impact on available resources and probably a whole
raft
| of other things that I can't think of right now.
|
| Take the following procedure as an example:
|
| Private Sub AAA()
|
| Dim _w as Widget
|
| _w = New Widget
|
| Me.Label1.Text = _w.Description
|
| End Sub
|
| All you are doing is instantiating a Widget object, grabbing the value of
| its Description property and forgetting about it. Because the object
| variable _w is local to the procedure it will 'go out of scope' as soon as
| the Ens Sub is executed. When it goes out of scope it will be
automatically
| disposed of and, at that stage, will become avaible for the Garbage
| Collector to have its wicked way with it when it is ready.
|
| Now add a call to a long running procedure after you have grabbed the
| Description and before the End Sub.
|
| Private Sub AAA()
|
| Dim _w as Widget
|
| _w = New Widget
|
| Me.Label1.Text = _w.Description
|
| LongRunningProcedure()
|
| End Sub
|
| The Garbage Collector might do its stuff a number of times before
| LongRunningProcedure returns, but _w will still not be tidied up until
| sometime after LongRunningProcedure returns and the End Sub is executed.
So,
| while LongRunningProcedure is executing, _w is just sitting there doing
| nothing but occupying some resource.
|
| if you so wish, and it is not mandatory to do so, you might 'dispose' of
_w
| early. One way of doing this is to set it to nothing. Another way, if the
| Widget class implements the IDisposable interface, is to call its Dispose
| method. Setting it to nothing tidies it up properly even it it doesn't
| implement IDisposable.
|
| Private Sub AAA()
|
| Dim _w as Widget
|
| _w = New Widget
|
| Me.Label1.Text = _w.Description
|
| _w = Nothing
|
| LongRunningProcedure()
|
| End Sub
|
| or
|
| Private Sub AAA()
|
| Dim _w as Widget
|
| _w = New Widget
|
| Me.Label1.Text = _w.Description
|
| _w.Dispose()
|
| LongRunningProcedure()
|
| End Sub
|
| Now, if the Garbage Collector does it suff (and feels so inclined) while
| LongRunningProcedure is executing, then it might tidy up _w.
|
| I have no intention of getting into a discussion of what the Garbage
| Collecter does or how it does it's stuff.
|
| In normal circumstances one does not really have to worry about it. You
| really only have to worry about it if there is a specific reason to do so.
|
| As you can see it is an complex area that, in my opinion is worthy of a
book
| specfically about Dispose, Finalize and the Garbage Collector.
|
| All you can really do is read as much as you can on the subject, decide
what
| is good advice, what is bad advice and make your own judgement calls.
|
| Remember that just because you read it somewhare does not make it fact.
Some
| people advocate explicit disposing of everting all the time, others
advocate
| never explicitly disposing. I take the middle ground and use it when I
| consider it appropriate to do so.
|
|
| "Dennis" <De****@discussions.microsoft.com> wrote in message
| news:00**********************************@microsof t.com...
| > You are then saying that a graphics object created with the
| > .CreateGraphics
| > method and the associated Pens and Brushes you use need not be disposed
| > since
| > they will be disposed by the Finalize method of the class they are used
in
| > which, from what I read, is correct but it is recommended that you
dispose
| > of
| > them as soon as you are finished with them and many on thie newsgroup
also
| > advocate disposing of them rather than relying on the Finalize method.
| >
| > A question, if you open a database (conn.open) then if you close it
| > (conn.close) you can reopen it at any time within the same scope using
| > conn.Open again. However, if you close it (conn.dispose), you can't
| > reopen
| > it unless you re-instantiate it..is this correct?
| >
| > "Stephany Young" wrote:
| >
| >> You've answered your own question:
| >>
| >> 'considered as a managed object since it's an instance of a class
| >> provided
| >> by the .Net framework'
| >>
| >> If your database connection object uses any unmanaged resources then it
| >> already knows about them and will implement Finalize to release them
and
| >> you
| >> dont not have to worry about this.
| >>
| >> What it really means is that if you write your own class, 'Widget',
that
| >> obtains and holds an unmanaged resource then you are responsible for
| >> releasing it by implementing Finalize.
| >>
| >> Air Code:
| >> ---------
| >> Class Widget
| >>
| >> Private handle as IntPtr
| >>
| >> Sub New()
| >> ' Obtain a handle to an unmanaged resource
| >> GetHandle(handle)
| >> End Sub
| >>
| >> Protected Sub Finalize()
| >> ' Release the unmanaged resource
| >> CloseHandle(handle)
| >> End Sub
| >>
| >> End Class
| >>
| >> Get the picture?
| >>
| >>
| >> "Joe Abou Jaoude" <an*******@devdex.com> wrote in message
| >> news:ub**************@tk2msftngp13.phx.gbl...
| >> >
| >> >
| >> > hi stephany,
| >> > I agree with u that one statement is talking about UNMANAGED
resources
| >> > and the other is talking about MANAGED objects....
| >> >
| >> > But is the database connection a managed or unmanaged object ?
| >> > Basically, It should be considered as a managed object since it's an
| >> > instance of a class provided by the .Net framework.
| >> >
| >> > However when reading this in msdn "A type must implement Finalize
when
| >> > it uses unmanaged resources such as file handles or database
| >> > connections
| >> > that must be released when the managed object that uses them is
| >> > reclaimed." I don't know what to think , because I don't think that a
| >> > database connection is obtained by calling an API
| >> >
| >> >
| >> > *** Sent via Developersdex http://www.developersdex.com ***
| >>
| >>
| >>
|
|

[Stephany Young]

OK. The sentence, from which you ommitted to quote the important bit, should
have read:

When it goes out of scope it will will become avaible for the Garbage
Collector to have its wicked way with it when it is ready.

Yes, I can see how the extraneous phrase could have been confusing if one
read the sentence, or that part of the sentence, out of context

The further point I was making was that the GC would do it's stuff at some
point in the function WITHOUT any special action from the programmer, and
that, in MOST CASES, one does not even need to consider it. I was not about
to attempt to list the cases where action from the programmer, but I am sure
that someone at MIT is probably writing a post-doctoral thesis on the
vagaries if the GC as we speak.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:ux**************@TK2MSFTNGP12.phx.gbl...

Stephany,
| When it goes out of scope it will be automatically
| disposed of and, at that stage,
VB.NET 1.0 & 1.1 (VS.NET 2002 & 2003) does not "automatically dispose" of
anything! You need to manually call IDisposable.Dispose if you want the
object to be disposed of.

VB.NET 2005 supports the Using statement (ala C#'s using statement in
VS.NET
2002 & 2003) which will support "automatically disposing" of objects that
implement the IDisposable interface.

| The Garbage Collector might do its stuff a number of times before
| LongRunningProcedure returns, but _w will still not be tidied up until
| sometime after LongRunningProcedure returns and the End Sub is executed
This is true for Debug builds (I don't remember if you need to be also
running under the debugger or not), however under Release builds the GC &
JIT sees that _w is no longer used & makes it eligible for collection!
Setting a variable to Nothing, does exactly that, sets the variable to
Nothing. My understanding it may actually hurt the GC's job in release
builds. In release builds the JIT & GC can determine when the variable is
no
longer being used & if you wait until after LongRunningProcedure is
finished
to set it to Nothing, the GC & JIT may think the object is still in use,
possibly causing it (the object) to be promoted to the 1st or 2nd
generation
heap.
Based on a couple of discussions last couple of weeks I have started a
list
of when to Call Dispose, actually its now a list of when its OK not to
call
Dispose! As you should always explicitly call Dispose if the framework
does
not implicitly call it for you! Which happens to be my new rule for
calling
IDisposable.Dispose. However I've been busy & have not had a chance to
review the discussion publish a synopsis yet.
Some useful links on the GC:

http://msdn.microsoft.com/msdnmag/issues/1100/gci/
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/

http://msdn.microsoft.com/library/de...izeDispose.asp

Both of these blogs contain a plethora of articles on the GC:
http://blogs.msdn.com/ricom/
http://blogs.msdn.com/maoni/

Hope this helps
Jay
"Stephany Young" <noone@localhost> wrote in message
news:uh**************@tk2msftngp13.phx.gbl...
| In a nutshell, yes that is what I am saying. BUT ... it's a bit more
| complicated than that.
|
| Factors like, the scope of an object, how long the life of an object is,
how
| instantiated objects impact on available resources and probably a whole
raft
| of other things that I can't think of right now.
|
| Take the following procedure as an example:
|
| Private Sub AAA()
|
| Dim _w as Widget
|
| _w = New Widget
|
| Me.Label1.Text = _w.Description
|
| End Sub
|
| All you are doing is instantiating a Widget object, grabbing the value
of
| its Description property and forgetting about it. Because the object
| variable _w is local to the procedure it will 'go out of scope' as soon
as
| the Ens Sub is executed. When it goes out of scope it will be
automatically
| disposed of and, at that stage, will become avaible for the Garbage
| Collector to have its wicked way with it when it is ready.
|
| Now add a call to a long running procedure after you have grabbed the
| Description and before the End Sub.
|
| Private Sub AAA()
|
| Dim _w as Widget
|
| _w = New Widget
|
| Me.Label1.Text = _w.Description
|
| LongRunningProcedure()
|
| End Sub
|
| The Garbage Collector might do its stuff a number of times before
| LongRunningProcedure returns, but _w will still not be tidied up until
| sometime after LongRunningProcedure returns and the End Sub is executed.
So,
| while LongRunningProcedure is executing, _w is just sitting there doing
| nothing but occupying some resource.
|
| if you so wish, and it is not mandatory to do so, you might 'dispose' of
_w
| early. One way of doing this is to set it to nothing. Another way, if
the
| Widget class implements the IDisposable interface, is to call its
Dispose
| method. Setting it to nothing tidies it up properly even it it doesn't
| implement IDisposable.
|
| Private Sub AAA()
|
| Dim _w as Widget
|
| _w = New Widget
|
| Me.Label1.Text = _w.Description
|
| _w = Nothing
|
| LongRunningProcedure()
|
| End Sub
|
| or
|
| Private Sub AAA()
|
| Dim _w as Widget
|
| _w = New Widget
|
| Me.Label1.Text = _w.Description
|
| _w.Dispose()
|
| LongRunningProcedure()
|
| End Sub
|
| Now, if the Garbage Collector does it suff (and feels so inclined) while
| LongRunningProcedure is executing, then it might tidy up _w.
|
| I have no intention of getting into a discussion of what the Garbage
| Collecter does or how it does it's stuff.
|
| In normal circumstances one does not really have to worry about it. You
| really only have to worry about it if there is a specific reason to do
so.
|
| As you can see it is an complex area that, in my opinion is worthy of a
book
| specfically about Dispose, Finalize and the Garbage Collector.
|
| All you can really do is read as much as you can on the subject, decide
what
| is good advice, what is bad advice and make your own judgement calls.
|
| Remember that just because you read it somewhare does not make it fact.
Some
| people advocate explicit disposing of everting all the time, others
advocate
| never explicitly disposing. I take the middle ground and use it when I
| consider it appropriate to do so.
|
|
| "Dennis" <De****@discussions.microsoft.com> wrote in message
| news:00**********************************@microsof t.com...
| > You are then saying that a graphics object created with the
| > .CreateGraphics
| > method and the associated Pens and Brushes you use need not be
disposed
| > since
| > they will be disposed by the Finalize method of the class they are
used
in
| > which, from what I read, is correct but it is recommended that you
dispose
| > of
| > them as soon as you are finished with them and many on thie newsgroup
also
| > advocate disposing of them rather than relying on the Finalize method.
| >
| > A question, if you open a database (conn.open) then if you close it
| > (conn.close) you can reopen it at any time within the same scope using
| > conn.Open again. However, if you close it (conn.dispose), you can't
| > reopen
| > it unless you re-instantiate it..is this correct?
| >
| > "Stephany Young" wrote:
| >
| >> You've answered your own question:
| >>
| >> 'considered as a managed object since it's an instance of a class
| >> provided
| >> by the .Net framework'
| >>
| >> If your database connection object uses any unmanaged resources then
it
| >> already knows about them and will implement Finalize to release them
and
| >> you
| >> dont not have to worry about this.
| >>
| >> What it really means is that if you write your own class, 'Widget',
that
| >> obtains and holds an unmanaged resource then you are responsible for
| >> releasing it by implementing Finalize.
| >>
| >> Air Code:
| >> ---------
| >> Class Widget
| >>
| >> Private handle as IntPtr
| >>
| >> Sub New()
| >> ' Obtain a handle to an unmanaged resource
| >> GetHandle(handle)
| >> End Sub
| >>
| >> Protected Sub Finalize()
| >> ' Release the unmanaged resource
| >> CloseHandle(handle)
| >> End Sub
| >>
| >> End Class
| >>
| >> Get the picture?
| >>
| >>
| >> "Joe Abou Jaoude" <an*******@devdex.com> wrote in message
| >> news:ub**************@tk2msftngp13.phx.gbl...
| >> >
| >> >
| >> > hi stephany,
| >> > I agree with u that one statement is talking about UNMANAGED
resources
| >> > and the other is talking about MANAGED objects....
| >> >
| >> > But is the database connection a managed or unmanaged object ?
| >> > Basically, It should be considered as a managed object since it's
an
| >> > instance of a class provided by the .Net framework.
| >> >
| >> > However when reading this in msdn "A type must implement Finalize
when
| >> > it uses unmanaged resources such as file handles or database
| >> > connections
| >> > that must be released when the managed object that uses them is
| >> > reclaimed." I don't know what to think , because I don't think that
a
| >> > database connection is obtained by calling an API
| >> >
| >> >
| >> > *** Sent via Developersdex http://www.developersdex.com ***
| >>
| >>
| >>
|
|

[Dennis]

Yes, you are correct in that I tried it on a Global Connection string.

Isn't the discussion regarding the Dispose interesting...As you know there
have been several threads on this topic and still it seems confusions reigns!
Based on what I can gather from reading everyone's notes and M'soft articles
in Dispose, it doesn't hurt so if I instantiate an object that has a dispose
method, I always dispose of it myself when I'm thru with it.

"Cor Ligthert" wrote:

Dennis,

Not directly, did you try on a global created connection which is disposed
to add the connectionstring again. The dispose on the connection is
overloaded and removes the connectionstring.
Cor

[Cor Ligthert]

Dennis,

Of course is that does not hurt true. However a statement like that tells
for me direct that the writter who wrote this, does not know about what he
is writting. It does not hurt to fill your pogram with 1000 statements like
this.

dim a as integer = 1
a =2
a =3
a =4
a = 5
etc.

It cost a minimal amount of time, however it does not hurt.

See this thread in the ADONET newsgroup where I was as well involved. It has
in my opinion a good conclusion at the end.

http://groups-beta.google.com/group/...9bf0424ffb9b1f

I hope it gives some ideas.

Cor
"Dennis" <De****@discussions.microsoft.com> schreef in bericht
news:AB27EA84-
34*************************@microsoft.com...

Yes, you are correct in that I tried it on a Global Connection string.

Isn't the discussion regarding the Dispose interesting...As you know there
have been several threads on this topic and still it seems confusions
reigns!
Based on what I can gather from reading everyone's notes and M'soft
articles
in Dispose, it doesn't hurt so if I instantiate an object that has a
dispose
method, I always dispose of it myself when I'm thru with it.

"Cor Ligthert" wrote:

Dennis,

Not directly, did you try on a global created connection which is
disposed
to add the connectionstring again. The dispose on the connection is
overloaded and removes the connectionstring.
Cor

[Jay B. Harlow [MVP - Outlook]]

Cor & Dennis,
Unfortunately DataSet.Dispose is one "isolated" case that requires knowing
the specific implementation details of the DataSet class. I hope you will
agree knowing specific implementation details of a class should not be
needed to use said class.

Attempting to apply how DataSet works to all classes that implement
IDisposable or Inherit from Component, such as I was attempting to do in
another thread on Dispose, is now IMHO not very advisable. Sometimes you
need to kick things around to see the folly of your own ways ;-)
A rough draft of my rule for calling Dispose is:

1. Explicitly call Dispose if the class implements IDisposable unless
Dispose is implicitly called for you.

Yep only a single rule! Yes my position has changed since (because of
really) March 21st. Actually it may not have changed as simply been
clarified & simplified :-)

Exceptions to the above rule: (rather then Exceptions maybe when Dispose is
implicitly called is a better label).
1. Be mindful of classes with methods are synonymous with Dispose. Such as
FileStream.Close or SqlConnection.Close. (I need better wording on this
one).

2. Windows Forms: Form will implicitly call Dispose for controls added to
the Control.Controls collection. If you directly or indirectly use Form.Show
to show a form, Dispose will automatically be called on the form when it is
closed. If you use Form.ShowDialog to display the form, then you need to
explicitly call Form.Dispose.
2.a If you remove a control from the Controls collection (on a Form or
another control) you need to explicitly call Dispose on it.
2.b Form will implicitly call Dispose for Components added to the
Form.components collection. For details see:
http://www.vbinfozine.com/a_disposable_comp.shtml

3. Web Forms: ASP.NET will implicitly call Dispose for controls added to the
page's control collection. ASP.NET implicitly calls Dispose on the page
during page processing.

4. ADO.NET: Controversial! DataSet doesn't really need Dispose called on it,
however due to the first (only) rule we probably should call Dispose on
it...

Although rule 4 is very popular I have not decided if I will "allow" it or
not in my code. It has the controversial moniker as developers needed to
look at the source for the type itself either Mono, Rotor, ILDASM to
Reflector to determine that not calling "Dispose" is safe on it.

Even more controversially I was going to have a generalized rule if the
class inherits from Component or MarshalByValueComponent in
System.ComponentModel and does not overide Dispose(Boolean) or implement
IDisposable, however I don't think I will include that rule as it requires
too much "special knowledge" of the implementation details of the class (use
of Reflector or ILDASM).

I need to go through my notes for possible additions.

Hope this helps
Jay
"Cor Ligthert" <no************@planet.nl> wrote in message
news:OM**************@TK2MSFTNGP12.phx.gbl...
| Dennis,
|
| Of course is that does not hurt true. However a statement like that tells
| for me direct that the writter who wrote this, does not know about what he
| is writting. It does not hurt to fill your pogram with 1000 statements
like
| this.
|
| dim a as integer = 1
| a =2
| a =3
| a =4
| a = 5
| etc.
|
| It cost a minimal amount of time, however it does not hurt.
|
| See this thread in the ADONET newsgroup where I was as well involved. It
has
| in my opinion a good conclusion at the end.
|
|
http://groups-beta.google.com/group/...9bf0424ffb9b1f
|
| I hope it gives some ideas.
|
| Cor
|
|
| "Dennis" <De****@discussions.microsoft.com> schreef in bericht
| news:AB27EA84-
| 34*************************@microsoft.com...
| > Yes, you are correct in that I tried it on a Global Connection string.
| >
| > Isn't the discussion regarding the Dispose interesting...As you know
there
| > have been several threads on this topic and still it seems confusions
| > reigns!
| > Based on what I can gather from reading everyone's notes and M'soft
| > articles
| > in Dispose, it doesn't hurt so if I instantiate an object that has a
| > dispose
| > method, I always dispose of it myself when I'm thru with it.
| >
| > "Cor Ligthert" wrote:
| >
| >> Dennis,
| >>
| >> Not directly, did you try on a global created connection which is
| >> disposed
| >> to add the connectionstring again. The dispose on the connection is
| >> overloaded and removes the connectionstring.
| >>
| >>
| >> Cor
| >>
| >>
| >>
|
|