Timeout 时间已到。在操作完成之前超时时间已过或服务器未响应。

Microsoft SQL Server 2008 R2   这是我使用的数据库。我是从接口中取到一个XML，然后将XMl传到存储过程中，在存储过程中针对XML进行操作。但是由于XML的数据量过大，因此会出现如标题一样的错误。 我百度了   看到网友说在连接字符串上写Connection Timeout=0;  我加了这个。我的sql连接字符串如下“server=service;UserID=sa;Password=123;database=test;Connection Timeout=0;Connection Reset=FALSE”

但是这样没有效果。所以求老鸟指教    看我这新手又是哪个步骤给丢了  求指教

最佳答案

你理解错了，Connection Timeout 是指等待连接打开的时间（以秒为单位）。默认值为 15 秒。

你现在的问题是连接已经成功了，并不是等待连接超时，你应该把那个异常给贴出来。

鉴于你提到存储过程执行周期较长，因此这里的超时是指的客户端等待服务器响应的超时，同Connection Timeout没有任何关系。

目前我还没找到如何控制TCP层面的超时设置，但是你可以尝试使用异步的方式来执行这个存储过程，在连接字符串中标记：Asynch = True，在调用时采用 BeginExecute 来执行你得存储过程。



你可以尝试用 SqlCommand.CommandTimeout 来设置超时。

在异步方法调用（如 BeginExecuteReader）过程中，CommandTimeout 属性将被忽略

因此上面两种方式应该都可以解决你的问题。
收获园豆：10

Launcher|高人七级|园豆：26930 | 2013-01-07 14:10
.



嗯     我的错误
已经解决了     是我理解错误了   我那个不是连接超时   而是执行的时间太长


备注


--------------------------------------------------------------------------------



在连接字符串中使用 ConnectTimeout 或 Connection Timeout 关键字，可以设置某个连接等待超时的时间。值 0 指示无限制，在 ConnectionString 中应避免值 0，否则会无限期地等待连接尝试。



为0的时候是不受时间限制了。  我不知道是不是数据库的原因，在有的帖子上看到说sqlserver2008的时间是自动去设置的   我不知道是不是这个原因


-----------------------事务超时-----------------------------------




C#中分布式事务的超时处理问题
.
2012-09-05 11:48501人阅读评论(0)收藏举报

c#insert测试google微软


  事务是个很精妙的存在，我们在数据层、服务层、业务逻辑层等多处地方都会使用到。

      在这里我只说下TransactionScope这个微软推荐使用的隐式事务。它是从Framework 2.0开始引入的一个事务管理类，在使用隐式事务时，事务完成前 程序应调用TransactionScope的Complete()方法，将事务提交，然后利用Dispose()释放事务对象。若执行期间出现错误，事务将自动回滚。

   比如：
     using (ransactionScope scope = new TransactionScope())

     {

        //to do something

        scope.Complete();

     }

在这里个人建议用using来创建，因为using实现了IDispose接口，它会隐式的调用TransactionScope对象的Dispose方法，即使发生异常时也是如此，能确保在事务结束或者异常的时候也能正确的释放资源。其实我们反编译一下，它的内部实现就是一个try...finally代码块，这样也就不难理解using的作用了。

说主题，在某地市的某库升级中，为避免程序运行中产生脏数据以及数据更新不一致导致的重复同步情况，在可能产生上述问题的考虑下，我用这个TransactionScope来对上述的操作进行事务处理。在本机的测试环境中，运行结果是正常的，当然这个运行正常的前提是数据量较小的情况下，我每次只对一条或者十几条数据的不同表进行insert和update。然而部署到生产环境针对真实数据运行之后，发现这个事务总是回滚，一直无法正常提交。程序也就没法正常跑起来。因为生产环境中的数据有60W左右，insert一次、update一次，最后再insert一条同步语句，前2个操作都是比较耗时的。我切换回测试环境调试了一下，逐行运行，发现当执行完第一个insert之后,执行第二个update时发生异常了。这个异常由TransactionScope抛出，异常提示是：事务已中止。这个错误，在数据量小的情况下不会发生，数据量大一些就出现了，这个是不是和事务处理的时间长短有关呢？因为我明显感觉到在这次调试的时候，执行的时间比之前数据量只有一条的时候长了很多，至少花费1分钟以上。于是google一下，验证了我的想法。
        TransactionScope有些重载函数是可以接受TimeSpan类型的值，这个就是事务的超时时间了。当事务实现隔离的时候，事务范围内的资源将会被锁定，如果一些事务长期占有资源，那将很容易造成死锁，为了避免这个问题，TransactionScope事务会定义一个超时限制，这个超时默认值为60秒。如果事务超过此时间，即使没有发生异常，也会自动中止。上面问题的原因算是找到了，知道了原因，那么也就很好解决了。我们可以在Web.Config 中配置:
<configuration>


<system.transactions>

    <defaultSettings timeout="00:05:00" />

</system.transactions>

</configuration>



或者在using的时候就定义好超时时间：




using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required,
new TimeSpan(0, 5, 0)))

或者先初始化事物行为的附加信息，然后定义超时时间：



TransactionOptions tOpt = new TransactionOptions();

tOpt.IsolationLevel = IsolationLevel.ReadCommitted; //设置TransactionOptions模式

tOpt.Timeout = new TimeSpan(0, 5, 0); // 设置超时时间为5分钟                       
using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required, tOpt))


我这里定义的是5分钟，其实整个过程处理起来也就第一次处理历史数据需要1到2分钟时间，以后每天只需处理几十条数据，这个时间基本是秒级别的。
       这里说明下， 超时时间如果设置为0时表示超时无限长。无限长的设置主要对调试有用，调试过程中可能要逐步通过代码来隔离业务逻辑中的问题，并且在尝试确定问题期间不希望所调试的事务超时。在所有其他情况下使用无限长的超时时一定要格外小心，因为它会覆盖防止事务死锁的保护。