我的应用程序引起了很多麻烦。这是一个.NET应用程序，它通过Web服务连接到SQL Server 2005. 该程序具有由长时间运行的存储过程填充的网格，该存储过程容易超时。如果超时并抛出SqlException，则没有执行处理来关闭连接。

这种情况的实际后果是什么？我认为框架或者SQL Server可能会以一种或者另一种方式来处理它，但不确定。

添加
该程序在早晨总是可以正常运行，但是在使用了大约一个小时后，它基本上停止了工作。问题不是我不知道如何正确编码连接。我需要知道这些症状是否可以由未关闭的连接引起。更改生产代码很重要，我想知道至少有可能成为问题。

结论
我将这种故障设计为在数百个同时连接上发生。我从来没有能够在应用程序环境中重现故障情况。标记为最佳做法的答案是正确的。谢谢大家。

解决方案

有连接限制。如果应用经常崩溃并且没有自动关闭连接，则新的连接请求将被拒绝。

也就是说，如果连接没有关闭，连接会在一段时间后超时。

如果经常发生连接，我们可能会用完可用的连接，应该在执行命令的所有位置使用finally来关闭连接。

垃圾收集器最终将最终确定打开的连接对象，但是我们不知道下次GC何时到来。在此之前，如果流量很大或者它是共享的sql服务器，则池中的连接可能用完了。

为什么不将其放置在try / catch块的最后部分中？

finally
{
   if (cn != null)
   {
      cn.Dispose();
      cn = null;
   }
}

显然，这应该在Web服务方法中完成。

try
{
    sqlCommandObject.Execute(); // this line will throw a timeout exception
}
finally
{
    sqlConnectionObject.Close(); // this will execute no matter what happens
}

如果应用程序在一个小时左右后停止工作，那肯定是由未关闭/未断开连接引起的。

由于SqlConnection在处理时关闭，因此我通常使用此语法

using (SqlConnection conn = new SqlConnection())
{
  // SqlCode here 
}

这就是为什么在使用ADO.Net时'using'关键字如此重要的原因

using ( SqlConnection conn = new SqlConnection() )
 {
     ...
 }

这会使用IDispose接口在ADO.Net对象上强制执行一种确定性垃圾回收。

大多数数据库代码为此目的使用了许多嵌套的" using"子句。