14 个解决方案
#1
把timeout设置时间再长一些
#2
ConnectionTimeout没有进行设置,应该是取默认值900秒吧
PS:在程序启动时建立与数据库的连接(程序运行中不会关闭或重新建立连接),此后由定时器每1小时存储一次数据,这个是不是会导致此问题。
PS:在程序启动时建立与数据库的连接(程序运行中不会关闭或重新建立连接),此后由定时器每1小时存储一次数据,这个是不是会导致此问题。
#3
检查一下阻塞,看看是不是等待时间太长,也就是说你的脚本没提交
#4
好像没什么问题,我的数据量其实并不大(开定时器每小时存储300条数据)
是要设置哪里的timeout呢?m_pCommand->CommandTimeout=0?
#5
CommandTimeout=0 这个应该是无限大了吧
#6
如果都设为无限大是不是不会产生这个问题?
#7
设为无限大,那只能靠SQL Server本身自带的功能来避免过长等待了。建议设小一点,不够再调大,同时sql代码中,如果用到事务,显式开始及显式提交或回滚。同时可以根据业务需要考虑是否设置下图中的选项:
#8
其实看当时是否产生阻塞或是死锁。一味的设置超时时间,是解决不了基本问题的。
#9
设为无限大,那只能靠SQL Server本身自带的功能来避免过长等待了。建议设小一点,不够再调大,同时sql代码中,如果用到事务,显式开始及显式提交或回滚。同时可以根据业务需要考虑是否设置下图中的选项:
CommandTimeout=0 这个应该是无限大了吧
如果都设为无限大是不是不会产生这个问题?
通过观察活动监视器,程序对数据库有如下活动:
根据上图好像没有造成阻塞吧。如果出现阻塞应该怎么处理呢?
PS:数据库中对表建立了触发器,会对插入的数据进行处理。
#10
周期性执行:
如果有数据,那用DBCC INPUTBUFFER(SPID)这个SPID是上面语句中第一列
看看执行了什么,然后看看是否执行过久或者有阻塞,还可以用DBCC OPENTRAN来看看有没有打开了的事务,如果有,且已经保持了很久,有可能就是未提交,阻塞了其他事务等等
select * from sys.sysprocesses where blocked<>0
如果有数据,那用DBCC INPUTBUFFER(SPID)这个SPID是上面语句中第一列
看看执行了什么,然后看看是否执行过久或者有阻塞,还可以用DBCC OPENTRAN来看看有没有打开了的事务,如果有,且已经保持了很久,有可能就是未提交,阻塞了其他事务等等
#11
就显示“超时已过期”的错误?这样的话原因很多的,没有更详细的信息吗?
你最好给出额外的异常信息,比如在“超时已过期”的前后有没有是“获取连接池”啦,或者是执行的查询语句未完成啦,之类的,
要精确定位,必须给出更多的异常信息。
你最好给出额外的异常信息,比如在“超时已过期”的前后有没有是“获取连接池”啦,或者是执行的查询语句未完成啦,之类的,
要精确定位,必须给出更多的异常信息。
#12
就显示“超时已过期”的错误?这样的话原因很多的,没有更详细的信息吗?
你最好给出额外的异常信息,比如在“超时已过期”的前后有没有是“获取连接池”啦,或者是执行的查询语句未完成啦,之类的,
要精确定位,必须给出更多的异常信息。
VC编写的应用程序,下图是存储数据的函数,错误信息就是这里报出的,怎样才能获得更多信息呢?
#13
你那个e.Description() 就就只显示“超时已过期” ,没有更多的信息吗?
#14
你那个e.Description() 就就只显示“超时已过期” ,没有更多的信息吗?
恩,就显示“超时已过期”
#1
把timeout设置时间再长一些
#2
把timeout设置时间再长一些
PS:在程序启动时建立与数据库的连接(程序运行中不会关闭或重新建立连接),此后由定时器每1小时存储一次数据,这个是不是会导致此问题。
#3
检查一下阻塞,看看是不是等待时间太长,也就是说你的脚本没提交
#4
检查一下阻塞,看看是不是等待时间太长,也就是说你的脚本没提交
好像没什么问题,我的数据量其实并不大(开定时器每小时存储300条数据)
是要设置哪里的timeout呢?m_pCommand->CommandTimeout=0?
#5
CommandTimeout=0 这个应该是无限大了吧
#6
CommandTimeout=0 这个应该是无限大了吧
如果都设为无限大是不是不会产生这个问题?
#7
CommandTimeout=0 这个应该是无限大了吧
如果都设为无限大是不是不会产生这个问题?
#8
其实看当时是否产生阻塞或是死锁。一味的设置超时时间,是解决不了基本问题的。
#9
设为无限大,那只能靠SQL Server本身自带的功能来避免过长等待了。建议设小一点,不够再调大,同时sql代码中,如果用到事务,显式开始及显式提交或回滚。同时可以根据业务需要考虑是否设置下图中的选项:
CommandTimeout=0 这个应该是无限大了吧
如果都设为无限大是不是不会产生这个问题?
通过观察活动监视器,程序对数据库有如下活动:
根据上图好像没有造成阻塞吧。如果出现阻塞应该怎么处理呢?
PS:数据库中对表建立了触发器,会对插入的数据进行处理。
#10
周期性执行:
如果有数据,那用DBCC INPUTBUFFER(SPID)这个SPID是上面语句中第一列
看看执行了什么,然后看看是否执行过久或者有阻塞,还可以用DBCC OPENTRAN来看看有没有打开了的事务,如果有,且已经保持了很久,有可能就是未提交,阻塞了其他事务等等
select * from sys.sysprocesses where blocked<>0
如果有数据,那用DBCC INPUTBUFFER(SPID)这个SPID是上面语句中第一列
看看执行了什么,然后看看是否执行过久或者有阻塞,还可以用DBCC OPENTRAN来看看有没有打开了的事务,如果有,且已经保持了很久,有可能就是未提交,阻塞了其他事务等等
#11
就显示“超时已过期”的错误?这样的话原因很多的,没有更详细的信息吗?
你最好给出额外的异常信息,比如在“超时已过期”的前后有没有是“获取连接池”啦,或者是执行的查询语句未完成啦,之类的,
要精确定位,必须给出更多的异常信息。
你最好给出额外的异常信息,比如在“超时已过期”的前后有没有是“获取连接池”啦,或者是执行的查询语句未完成啦,之类的,
要精确定位,必须给出更多的异常信息。
#12
就显示“超时已过期”的错误?这样的话原因很多的,没有更详细的信息吗?
你最好给出额外的异常信息,比如在“超时已过期”的前后有没有是“获取连接池”啦,或者是执行的查询语句未完成啦,之类的,
要精确定位,必须给出更多的异常信息。
VC编写的应用程序,下图是存储数据的函数,错误信息就是这里报出的,怎样才能获得更多信息呢?
#13
你那个e.Description() 就就只显示“超时已过期” ,没有更多的信息吗?
#14
你那个e.Description() 就就只显示“超时已过期” ,没有更多的信息吗?
恩,就显示“超时已过期”