问题标签 [command-timeout]

如果我使用下面的 c# 代码从数据库中检索存储过程

ReadQueueDB中的程序：

当我从代码执行命令时，超时时间是 0 还是 120 秒？

谢谢你。

当存储过程花费的时间超过默认超时值时，我似乎遇到了一些随机问题；我被告知这里。

所以我增加了价值，这似乎有所帮助。

但这让我想知道：为什么不总是把它设为一个非常高的数字，以防查询或操作需要很长时间？并不是因为这是允许的 MAX 就需要那么长时间，对吧？

既然如此（我想），为什么默认值会这么低（我相信是 30 秒）？

更新

我最初将 SqlCommand 的 CommandTimeout 值设置为 300（5 分钟），但这样我得到了“发生上下文切换死锁”。所以我把它减少到 120（2 分钟），这对我来说似乎或多或少是“甜蜜点”。在几次测试中，我确实有一次“超时已过期”，但是当我重试相同的确切范围时，它第二次成功完成，所以我想这只是“其中之一” - 120 有时还不够超时，但 300 显然太多了。IOW，这种太少和太多之间的平衡行为似乎不是“一门精确的科学”。

我们将一些旧软件迁移到新服务器上。我们过去使用 SQL Server 2008 Enterprise，现在我们在新机器上使用 SQL Server 2014 Enterprise，所以现在应该更快。

旧软件是旧软件，即将到期，因此我不想花太多精力来修复它。但由于某种原因，有一个 C# 函数针对我收到错误消息的数据库运行 SQL 查询

超时已过。在操作完成之前超时时间已过或服务器没有响应。

我读到的只是，我必须通过使用来延长超时时间CommandTimeout。但不幸的是，一切都在“上下文连接=真”下运行。因此，重建此功能并有机会更改超时将需要相当多的工作。

我在问自己，为什么这会在旧机器上运行，而不会在新机器上运行。所以它必须对新机器或新的 SQL Server 引擎做点什么。有什么方法可以更改 .NET Framework 或 SQL Server 中命令的标准超时 30 秒？

非常感谢您的任何建议！

I'm using Entity Framework 6 to access a SQL Server in an API application. The API server and DB server are separate. I have a known long query that takes a little more than a minute to run. I have set the CommandTimeout on my EF DbContext using the following code:

Unfortunately, this does not seem to have any affect because the query still times out in less than a minute and the server returns a 504 Gateway Timeout error.

Why does this change not have any affect on the command execution time limit?

Is there something else I should be doing to allow this query to run longer?

Some more details:

I have written a desktop app that makes API calls to an API server which in turn makes queries to the db server. On the desktop application side, I have set the HttpClient property:

On the API server side, I have set the execution timeout:

And on the API server, I've set the SQL command timeout as above.

At some point, the response always ends after a little less than a minute despite the fact that I've set all the timeouts I can think of to 20 minutes. I assumed the 504 was caused by the db timeout, but I suppose it's just as likely that it's between the desktop app and the API server.

Regardless, I'm running out of ideas so anything will help.

我只有一个一般类型的问题。如果我有一个调用 SQL Server 存储过程的 C# 应用程序，并且 C# 应用程序超时，服务器上的过程调用是否会继续运行直到完成？

我想为查询执行设置命令超时，目前我正在做context.Database.CommandTimeout = 90;，但我觉得这不起作用，我尝试检查数据库中的进程日志，但发现时间差总是小于 90 秒。

有人可以帮助我如何在 Entity Framework 6 中设置数据库超时吗？

我在 Windows 服务中有一个运行时间相当长的进程，它会定期抛出“ContextSwitchDeadlock”异常：

我还操纵我的服务向自己发送电子邮件，其中包含有关遇到的异常的详细信息。我得到：

...然后三秒钟后：

顺便说一句：至少它是一致的：我有三对这样的异常，每次第二个的日期时间都在第一个之后的三秒。

我以前有过以这种或那种方式调整 SQLCommand 的 CommandTimeout 值（当前设置为 360）的经验，这似乎有点像蒙着眼睛扔飞镖，甚至是黑魔法。有没有更好的方法来防止这种死锁？

我有其他非常相似的方法不会导致这个问题；那些需要更少的时间。方法的持续时间（特别是查询运行所需的时间长度）似乎是“问题”。我无法改变这一点——“它就是这样”——那我还能做什么？

更新

自然地，在发布上述内容之后，顽固的过程“让我成为骗子”，因为我又得到了两对异常，这次是第二对错误消息发生在第一个而不是三个之后一秒。如果我等待的时间足够长，也许第二个异常会在第一个异常之前发生。

在此处对上一个问题的回答中，建议我也询问此相关问题。

有时，我的报告生成代码会引发两个异常（它们不会显示给用户，而且他们认为一切都是笨拙的），但我会通过电子邮件将它们发送给我。

第一个是“超时时间已过。在操作完成之前超时时间已过或服务器没有响应。 ”

...而此后总是很快跟进的是，“找不到表 0 ”

第一条异常消息认为，以下方法中 try 部分的最后一行代码（“new SqlDataAdapter(cmd).Fill(ds);”）正在引发异常：

第二条异常消息声称它来自上述方法中的最后一行（“ return ds.Tables[0]; ”）以及这一行：

FILL_RATE_BY_DISTRIBUTOR_BY_CUSTOMER_STORED_PROC是一个存储过程，在我在这里的努力和活动之前在其他地方使用，所以不是 SP 本身导致了问题。

对于超级好奇的人，上面代码中的定制方法调用是：

我注意到在 Dapper.NET 中使用异步 API 时，我在扩展方法中传递的命令超时值不受尊重。然后我遇到了 SqlCommand.CommandTimeout 的MSDN 文档，这似乎是它不“支持”的东西。

在异步方法调用（例如 BeginExecuteReader）期间，CommandTimeout 属性将被忽略。

我在基类中使用以下方法。

说CommandTimeoutDefault是 30，我可以确定仍然会评估需要 50 秒的请求。

任何想法如何使用异步 Dapper.NET API 在超时间隔内断开连接和处理连接？

所以，我正在编写这段代码来执行一个在 30 秒内超时的存储过程（经过一些搜索，我理解为默认值）。当我寻找增加 CommandTimeout 的方法时，我得到了很多建议使用 IObjectContextAdapter 接口设置超时的答案，如下所示：

当我检查上下文对象时，我在数据库对象中找到了 CommandTimeout 属性，当我编写以下代码时，一切正常，超时时间增加到我设置的值：

我想知道以这种方式设置 CommandTimeout 是否有任何问题，或者是否推荐使用 IObjectContextAdapter 方法。

提前致谢。