Hi z.f.

connection.close the way to go.


--
Regards,
Chua Wen Ching


"z. f." wrote:

> must i call connection.dispose()
> or the close() method is enough,
> on my sql server i see many connections created.
>
> TIA, z.
>
>
>

Hi ZF,

connection.dispose
(It is one of the exceptions)

It works almost the same as the close however when you want to open the
connection again you have to add the connectionstring again. (Of course
instead of the close not extra)

Cor

must i call connection.dispose()
or the close() method is enough,
on my sql server i see many connections created.

TIA, z.

The Dispose method mainly calls Close().

-mike
MVP

"Cor Ligthert" <(E-Mail Removed)> wrote in message
news:epm7%(E-Mail Removed)...
> Hi ZF,
>
> connection.dispose
> (It is one of the exceptions)
>
> It works almost the same as the close however when you want to open the
> connection again you have to add the connectionstring again. (Of course
> instead of the close not extra)
>
> Cor
>
>

When you want to destroy the connection instance, call Dispose. When you
want only to close the connection, call Close.
There is not much difference as Cor mentioned, however, in the future the
behaviour might change.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com

"z. f." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> must i call connection.dispose()
> or the close() method is enough,
> on my sql server i see many connections created.
>
> TIA, z.
>
>

The unmanaged resource we're concerned about *is* the literal connection
though, right? By that I mean that any differences between Close and
Dispose are somewhat moot for practical resource management concerns, isn't
it?

Also, what if you just rely on the following code to close the connection?
Then technically you don't need to explicitly close or dispose the
connection object itself, right?
..ExecuteReader(CommandBehavior.CloseConnection)



"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
news:%(E-Mail Removed)...
> When you want to destroy the connection instance, call Dispose. When you
> want only to close the connection, call Close.
> There is not much difference as Cor mentioned, however, in the future the
> behaviour might change.
>
> --
> Miha Markic [MVP C#] - RightHand .NET consulting & development
> miha at rthand com

Strictly speaking, the SqlConnection object is just a managed object, so
it's no big deal by itself. However, one of it's internal objects manages
native resources (network connections, native buffers, etc.) which need to
be carefully tracked to make sure we don't leak them. That's why is so
important to call Close or Dispose on the connection, so the internal
objects are properly cleaned-up.

Using CommandBehavior.CloseConnection is a great option if you know that you
won't need the connection after processing the result-set. Keep in mind,
though, that in this case you have to make sure you close the DataReader;
it's as important as closing the connection, because we'll close the
connection when you close the reader if CloseConnection is specified.

--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.


"Daniel Billingsley" <dbillingsley@NO_durcon_SPAAMM.com> wrote in message
news:(E-Mail Removed)...
> The unmanaged resource we're concerned about *is* the literal connection
> though, right? By that I mean that any differences between Close and
> Dispose are somewhat moot for practical resource management concerns,
isn't
> it?
>
> Also, what if you just rely on the following code to close the connection?
> Then technically you don't need to explicitly close or dispose the
> connection object itself, right?
> .ExecuteReader(CommandBehavior.CloseConnection)
>
>
>
> "Miha Markic [MVP C#]" <miha at rthand com> wrote in message
> news:%(E-Mail Removed)...
> > When you want to destroy the connection instance, call Dispose. When you
> > want only to close the connection, call Close.
> > There is not much difference as Cor mentioned, however, in the future
the
> > behaviour might change.
> >
> > --
> > Miha Markic [MVP C#] - RightHand .NET consulting & development
> > miha at rthand com
>
>

Yes, but that's a general description of why there is a Dispose on some
objects in the first place, isn't it? The objects themselves are handled
fine by GC, the nasty unmanaged resources inside them notwithstanding -
hence the propensity for leaks. Correct?

Glad to hear the second answer.. in my case I created a data factory to
return a DataReader... I can't wrap the connection in a using inside the
factory class since the DataReader is of course useless once the connection
is closed. Yeah I'm depending on the next layer developer to Dispose the
DataReader, but that person is me. Actually, I'm returning a wrapper for
the DataReader, so this is probably a case where there's a strong argument
for making my wrapper class throw an exception in the Finalizer since proper
disposal is so important yet out of the control of the factory class.

"Pablo Castro [MS]" <(E-Mail Removed)> wrote in message
news:uE%(E-Mail Removed)...
> Strictly speaking, the SqlConnection object is just a managed object, so
> it's no big deal by itself. However, one of it's internal objects manages
> native resources (network connections, native buffers, etc.) which need to
> be carefully tracked to make sure we don't leak them. That's why is so
> important to call Close or Dispose on the connection, so the internal
> objects are properly cleaned-up.
>
> Using CommandBehavior.CloseConnection is a great option if you know that
you
> won't need the connection after processing the result-set. Keep in mind,
> though, that in this case you have to make sure you close the DataReader;
> it's as important as closing the connection, because we'll close the
> connection when you close the reader if CloseConnection is specified.
>
> --
> Pablo Castro
> Program Manager - ADO.NET Team
> Microsoft Corp.
>

Yes, you're right in the statement below regarding general pattern for
Dispose().

Regarding throwing an exception in the finalizer...I'm not sure that's a
good idea. Who's going to catch the exception? there is no user code on top
of your finalizer in the finalizer thread...you can log it somewhere or
something like that.

--
Pablo Castro
Program Manager - ADO.NET Team
Microsoft Corp.

This posting is provided "AS IS" with no warranties, and confers no rights.


"Daniel Billingsley" <dbillingsley@NO_durcon_SPAAMM.com> wrote in message
news:OIlKF%(E-Mail Removed)...
> Yes, but that's a general description of why there is a Dispose on some
> objects in the first place, isn't it? The objects themselves are handled
> fine by GC, the nasty unmanaged resources inside them notwithstanding -
> hence the propensity for leaks. Correct?
>
> Glad to hear the second answer.. in my case I created a data factory to
> return a DataReader... I can't wrap the connection in a using inside the
> factory class since the DataReader is of course useless once the
connection
> is closed. Yeah I'm depending on the next layer developer to Dispose the
> DataReader, but that person is me. Actually, I'm returning a wrapper for
> the DataReader, so this is probably a case where there's a strong argument
> for making my wrapper class throw an exception in the Finalizer since
proper
> disposal is so important yet out of the control of the factory class.
>
> "Pablo Castro [MS]" <(E-Mail Removed)> wrote in message
> news:uE%(E-Mail Removed)...
> > Strictly speaking, the SqlConnection object is just a managed object, so
> > it's no big deal by itself. However, one of it's internal objects
manages
> > native resources (network connections, native buffers, etc.) which need
to
> > be carefully tracked to make sure we don't leak them. That's why is so
> > important to call Close or Dispose on the connection, so the internal
> > objects are properly cleaned-up.
> >
> > Using CommandBehavior.CloseConnection is a great option if you know that
> you
> > won't need the connection after processing the result-set. Keep in mind,
> > though, that in this case you have to make sure you close the
DataReader;
> > it's as important as closing the connection, because we'll close the
> > connection when you close the reader if CloseConnection is specified.
> >
> > --
> > Pablo Castro
> > Program Manager - ADO.NET Team
> > Microsoft Corp.
> >
>
>