connection.dispose()

[Guest]

Hi z.f.

connection.close the way to go.

 

[Cor Ligthert]

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

 

[z. f.]

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

TIA, z.

 

[Michael Giagnocavo [MVP]]

The Dispose method mainly calls Close().

-mike
MVP

 

[Miha Markic [MVP C#]]

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.

 

[Daniel Billingsley]

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)

 

[Pablo Castro [MS]]

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.

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)

 

[Daniel Billingsley]

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]]

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.