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.InvalidO perationExcepti on - 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*******@devd ex.com> wrote in message
news:uI******** ******@tk2msftn gp13.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.InvalidO perationExcepti on - 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(handl e)
End Sub

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

End Class

Get the picture?
"Joe Abou Jaoude" <an*******@devd ex.com> wrote in message
news:ub******** ******@tk2msftn gp13.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(handl e)
End Sub

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

End Class

Get the picture?
"Joe Abou Jaoude" <an*******@devd ex.com> wrote in message
news:ub******** ******@tk2msftn gp13.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

LongRunningProc edure()

End Sub

The Garbage Collector might do its stuff a number of times before
LongRunningProc edure returns, but _w will still not be tidied up until
sometime after LongRunningProc edure returns and the End Sub is executed. So,
while LongRunningProc edure 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

LongRunningProc edure()

End Sub

or

Private Sub AAA()

Dim _w as Widget

_w = New Widget

Me.Label1.Text = _w.Description

_w.Dispose()

LongRunningProc edure()

End Sub

Now, if the Garbage Collector does it suff (and feels so inclined) while
LongRunningProc edure 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****@discuss ions.microsoft. com> wrote in message
news:00******** *************** ***********@mic rosoft.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(handl e)
End Sub

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

End Class

Get the picture?
"Joe Abou Jaoude" <an*******@devd ex.com> wrote in message
news:ub******** ******@tk2msftn gp13.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 connectionstrin g again. The dispose on the connection is
overloaded and removes the connectionstrin g.
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 "automatica lly dispose" of
anything! You need to manually call IDisposable.Dis pose 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 "automatica lly disposing" of objects that
implement the IDisposable interface.

| The Garbage Collector might do its stuff a number of times before
| LongRunningProc edure returns, but _w will still not be tidied up until
| sometime after LongRunningProc edure 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 LongRunningProc edure 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.Dis pose. 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@localhos t> wrote in message
news:uh******** ******@tk2msftn gp13.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
|
| LongRunningProc edure()
|
| End Sub
|
| The Garbage Collector might do its stuff a number of times before
| LongRunningProc edure returns, but _w will still not be tidied up until
| sometime after LongRunningProc edure returns and the End Sub is executed.
So,
| while LongRunningProc edure 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
|
| LongRunningProc edure()
|
| End Sub
|
| or
|
| Private Sub AAA()
|
| Dim _w as Widget
|
| _w = New Widget
|
| Me.Label1.Text = _w.Description
|
| _w.Dispose()
|
| LongRunningProc edure()
|
| End Sub
|
| Now, if the Garbage Collector does it suff (and feels so inclined) while
| LongRunningProc edure 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****@discuss ions.microsoft. com> wrote in message
| news:00******** *************** ***********@mic rosoft.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(handl e)
| >> End Sub
| >>
| >> Protected Sub Finalize()
| >> ' Release the unmanaged resource
| >> CloseHandle(han dle)
| >> End Sub
| >>
| >> End Class
| >>
| >> Get the picture?
| >>
| >>
| >> "Joe Abou Jaoude" <an*******@devd ex.com> wrote in message
| >> news:ub******** ******@tk2msftn gp13.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******** ******@TK2MSFTN GP12.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 "automatica lly dispose" of
anything! You need to manually call IDisposable.Dis pose 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 "automatica lly disposing" of objects that
implement the IDisposable interface.

| The Garbage Collector might do its stuff a number of times before
| LongRunningProc edure returns, but _w will still not be tidied up until
| sometime after LongRunningProc edure 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 LongRunningProc edure 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.Dis pose. 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@localhos t> wrote in message
news:uh******** ******@tk2msftn gp13.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
|
| LongRunningProc edure()
|
| End Sub
|
| The Garbage Collector might do its stuff a number of times before
| LongRunningProc edure returns, but _w will still not be tidied up until
| sometime after LongRunningProc edure returns and the End Sub is executed.
So,
| while LongRunningProc edure 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
|
| LongRunningProc edure()
|
| End Sub
|
| or
|
| Private Sub AAA()
|
| Dim _w as Widget
|
| _w = New Widget
|
| Me.Label1.Text = _w.Description
|
| _w.Dispose()
|
| LongRunningProc edure()
|
| End Sub
|
| Now, if the Garbage Collector does it suff (and feels so inclined) while
| LongRunningProc edure 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****@discuss ions.microsoft. com> wrote in message
| news:00******** *************** ***********@mic rosoft.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(handl e)
| >> End Sub
| >>
| >> Protected Sub Finalize()
| >> ' Release the unmanaged resource
| >> CloseHandle(han dle)
| >> End Sub
| >>
| >> End Class
| >>
| >> Get the picture?
| >>
| >>
| >> "Joe Abou Jaoude" <an*******@devd ex.com> wrote in message
| >> news:ub******** ******@tk2msftn gp13.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 ***
| >>
| >>
| >>
|
|