When a connection closes....

[Twitch]

WRT:
System.Data.SqlClient.SqlConnection

When an SqlConnection goes out of scope, is the .close() called by it's
destructor?

thanks.

 

[Miha Markic [MVP C#]]

Hi,

Depends on the provider. SqlConnection doesn't close when finalized.
And there is another problem - even if it is closed you won't never know
when it closes because it is in hands of garbage collection.
Bottom point:
Always, close the connection explicitly asap (put Close in finally part of
try/finally).

 

[Twitch]

So this little snippet from DataAccess Application block is bad mojo?

public static int ExecuteNonQuery(string connectionString, CommandType commandType, string commandText, params SqlParameter[] commandParameters)
{
//create & open a SqlConnection, and dispose of it after we are done.
using (SqlConnection cn = new SqlConnection(connectionString))
{
cn.Open();
//call the overload that takes a connection in place of the connection string
return ExecuteNonQuery(cn, commandType, commandText, commandParameters);
}
}

Hi,

Depends on the provider. SqlConnection doesn't close when finalized.
And there is another problem - even if it is closed you won't never know
when it closes because it is in hands of garbage collection.
Bottom point:
Always, close the connection explicitly asap (put Close in finally part of
try/finally).

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

WRT:
System.Data.SqlClient.SqlConnection

When an SqlConnection goes out of scope, is the .close() called by it's
destructor?

thanks.

 

[William \(Bill\) Vaughn]

Nope. It's ok. Note that the Using operator automatically calls Dispose on objects created in its scope. Dispose calls Close.
No, I don't like this approach because it causes perfectly sane developers to ask questions (good questions) like this. I prefer to call Close explicitly--but with this syntax there was no place to put a Close.

This operator comes to VB.NET in the Whidbey timeframe. I guess we had (all) be prepared to understand its use.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

So this little snippet from DataAccess Application block is bad mojo?

public static int ExecuteNonQuery(string connectionString, CommandType commandType, string commandText, params SqlParameter[] commandParameters)
{
//create & open a SqlConnection, and dispose of it after we are done.
using (SqlConnection cn = new SqlConnection(connectionString))
{
cn.Open();
//call the overload that takes a connection in place of the connection string
return ExecuteNonQuery(cn, commandType, commandText, commandParameters);
}
}

Hi,

Depends on the provider. SqlConnection doesn't close when finalized.
And there is another problem - even if it is closed you won't never know
when it closes because it is in hands of garbage collection.
Bottom point:
Always, close the connection explicitly asap (put Close in finally part of
try/finally).

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

WRT:
System.Data.SqlClient.SqlConnection

When an SqlConnection goes out of scope, is the .close() called by it's
destructor?

thanks.

 

[bruce barker]

yes, but the destructor is not called until the GC get around to it (which
may not be until task exit). by convention, any object that uses unmanaged
resoures implements a Dispose method (and often a Close that calls it). This
allows code to release the unmanaged resources when done, rather than when
the GC needs to.

the GC only collects an object when it needs the memory, and has no way to
know that the object is hoarding critial unmanaged resources (like file or
sql connections).

C# supplies the "using" statement to make using this bad boys easier and
safer. if you don't use the "using" statement, than you should always use a
try/catch/finally and Dispose/Close the object in the finally clause.

-- bruce (sqlwork.com)

 

[Angel Saenz-Badillos[MS]]

I love the "using" construct, just think of it as
ry{ }finally{myUsedObject.Dispose() }.

To make it clear, the following two pieces of code are exactly the same:

====================
using (SqlConnection cn = new SqlConnection(connectionString))
{
cn.Open();
return ExecuteNonQuery(cn, commandType, commandText,
commandParameters);
}
====================================
SqlConnection cn=null;
try
{
cn = new SqlConnection(connectionString))
cn.Open();
return ExecuteNonQuery(cn, commandType, commandText,
commandParameters);
}
finally
{
cn.Dispose();
}
=====================

The benefit that both of these examples have is that Dispose will always get
called, even if an exception is thrown inside ExecuteNonQuery, since the
finally is guaranteed to run. If you don't have the finally then you would
not close the connection at all on exceptions, enough of those put together
and bad mojo will happen.


--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.

Nope. It's ok. Note that the Using operator automatically calls Dispose on
objects created in its scope. Dispose calls Close.
No, I don't like this approach because it causes perfectly sane developers
to ask questions (good questions) like this. I prefer to call Close
explicitly--but with this syntax there was no place to put a Close.

This operator comes to VB.NET in the Whidbey timeframe. I guess we had (all)
be prepared to understand its use.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

So this little snippet from DataAccess Application block is bad mojo?

public static int ExecuteNonQuery(string connectionString, CommandType
commandType, string commandText, params SqlParameter[] commandParameters)
{
//create & open a SqlConnection, and dispose of it after we are done.
using (SqlConnection cn = new SqlConnection(connectionString))
{
cn.Open();
//call the overload that takes a connection in place of the
connection string
return ExecuteNonQuery(cn, commandType, commandText,
commandParameters);
}
}

Hi,

Depends on the provider. SqlConnection doesn't close when finalized.
And there is another problem - even if it is closed you won't never know
when it closes because it is in hands of garbage collection.
Bottom point:
Always, close the connection explicitly asap (put Close in finally part of
try/finally).

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

WRT:
System.Data.SqlClient.SqlConnection

When an SqlConnection goes out of scope, is the .close() called by it's
destructor?

thanks.