SQL超时解决方法
现把解决方法总结一下:
影响服务器产生超时的设置大致有:
1. Server.scrīptTimeout,
2. Connection对象的CommandTimeOut属性,
3. Command对象的CommandTimeOut属性,
4. IE浏览器的设置.
Server.scrīptTimeout,默认值是90秒.
要增大它,在你的asp文件中加一句,如下:
Server.scrīptTimeout=999,
将页面超时设为999秒.
最初我只设置Server.scrīptTimeout,
但仍会出现timeout错误,无论它的值设成都多大.
后在社区里看到一帖子,提到commandTimeout属性,
于是查看Option Pack文档,果然还有其他的timeout.
Connection对象和Command对象都有个CommandTimeOut属性,
连接字符串中设置了 Connect Timeout只对SqlConnection起作用。
SqlCommand.CommandTimeout
获取或设置在终止执行命令的尝试并生成错误之前的等待时间。
等待命令执行的时间（以秒为单位）。默认为 30 秒。
SqlConnection.ConnectionTimeout
获取在尝试建立连接时终止尝试并生成错误之前所等待的时间。
等待连接打开的时间（以秒为单位）。默认值为 15 秒。
一些更详细的对这个问题的描述看：http://www.eggheadcafe.com/PrintSearchContent.asp?LINKID=357
如果你有一个耗时的查询或数据处理,
很容易就超时了.要增大它,也很容易,创建对象后,
设置它的属性,如下:
con.CommandTimeOut = 999,
设为999秒,其中con是一Connection对象.
如设为零,将无限等待,没有这一timeout限制.
Command对象不会继承Connection的这一属性,
所以对可能超时的Command也要单独设置CommandTimeout属性.
最后IE也有个超时设置,5分钟从服务器得不到数据,也超时.
这种情况可能很少碰到,
但当我把一10多万查询的结果保存为mdb文件时,
就遇到了.(至于保存的方法,请参看精华区中的一篇帖子.)
解决方法:(原文请参照微软KB中的Q181050)
1. IE要4.01 sp1以上版本.
2. 在注册表中HKEY_CURRENT_USERSoftwareMicrosoft
WindowsCurrentVersionInternet Settings中
加一DWORD类型ReceiveTimeout,值设为比如8个9.
3. restart computer.
下面是一篇详细的讨论：
"The timeout period elapsed prior to completion of the operation or the server is not responding."
If this sounds familiar using the SqlClient Class or the Data Access Application Blocks "SqlHelper", and you have increased the Connection Timeout and the Connect Lifetime (for pooling) in your connection string(s), its probably because you forgot to set the COMMAND timeout!
A command can be timed out after a certain number of seconds. You might want to set this limit if you foresee to run across particularly lengthy operations. As in ADO, the property to check is CommandTimeout. Its default value is 30 seconds.
You can set this once the command instance has been created. A value of "0" (zero) means the command will wait for completion indefinitely, but this is not recommended by Microsoft. Better to set a large value in seconds.
Unlike ADO, ADO.NET lets you specify the expected behavior of the command through the CommandBehavior enum. Such values specify a description of the results and how the query should affect the data source. In Beta 1, you had a CommandBehavior property to set for each command. Starting with Beta 2, you use values from the CommandBehavior enum only as an argument for ExecuteReader.
Among the other options, you can ask a query command to limit to obtain key and schema information. In this case, the command will be executed without any locking on the selected rows. This behavior is given by the KeyInfo flag. If you have long running queries or multiple threads accessing Sql Server simultaneously,
this can be very helpful.
As an alternative, you might want to obtain column information only, without affecting the database state with locks. This option is SchemaOnly. Another option, SingleResult, lets you specify that you want back only one resultset, no matter how many would originate from the command. In this case, the command returns only the first resultset found. A fourth option is CloseConnection that forces the SqlDataReader object associated with a query command to automatically close the connection as the final step of its Close method.
If you use the SqlHelper "Best practices" class as I do, it might be a good idea to recompile it, setting "cmd.CommandTimeout=howmanyseconds. There are a number of instances of this in the class.
And, as a final caveat, don't call Dispose() on a SqlConnection unless you want to have it removed from the connection pool, because that's what Dispose() does! In almost all cases, you would simple call the Close() method and let ADO.NET take care of returning the connection to the pool.