DBPROP_COMMANDTIMEOUT does not seem to work?
作者:黄敏 日期:2010-06-03
This is set as a property to a dbcommand,
程序代码
propSet.AddProperty(DBPROP_COMMANDTIMEOUT, 30);
But the command does not seem to work after 30 seconds.
This post appears making sense to me:
引用内容
o The timeout no longer counts, once the client library have received some
data back from SQL Server. (This is something I have read in a book; I
have not verified it myself.)
o If the timeout elapses when SQL Server has been inserting data into a
table for 30 seconds, or even worse been updating rows row 30 seconds,
it will not yield on the spot. The effect of the currently executing
statement must be rolled back. And rollbacks usually takes longer than
command that started the operation.
In my case, the first one makes sense because the query in my test command does return 696164 rows. That explains why the command took around 175 seconds and did not report any timeout failure. After all, if there is data incoming, why the command can be assumed hanged?
If I put a sleep in a sproc, the timeout will still occur, obviously since no data is returned to the client, the client think the command is stalled.
Further reading:
This MSDN blog explains query timeouts are a client-side concept only.
But this is probably the best explanation about how the timeout is calculated: http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout.aspx
引用内容
This property is the cumulative time-out for all network reads during command execution or processing of the results. A time-out can still occur after the first row is returned, and does not include user processing time, only network read time.
程序代码propSet.AddProperty(DBPROP_COMMANDTIMEOUT, 30);
But the command does not seem to work after 30 seconds.
This post appears making sense to me:
引用内容o The timeout no longer counts, once the client library have received some
data back from SQL Server. (This is something I have read in a book; I
have not verified it myself.)
o If the timeout elapses when SQL Server has been inserting data into a
table for 30 seconds, or even worse been updating rows row 30 seconds,
it will not yield on the spot. The effect of the currently executing
statement must be rolled back. And rollbacks usually takes longer than
command that started the operation.
In my case, the first one makes sense because the query in my test command does return 696164 rows. That explains why the command took around 175 seconds and did not report any timeout failure. After all, if there is data incoming, why the command can be assumed hanged?
If I put a sleep in a sproc, the timeout will still occur, obviously since no data is returned to the client, the client think the command is stalled.
Further reading:
This MSDN blog explains query timeouts are a client-side concept only.
But this is probably the best explanation about how the timeout is calculated: http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout.aspx
引用内容This property is the cumulative time-out for all network reads during command execution or processing of the results. A time-out can still occur after the first row is returned, and does not include user processing time, only network read time.
评论: 0 | 引用: 0 | 查看次数: 192
发表评论
上一篇
下一篇


文章来自:
Tags: 