|
测试程序中重用了原工程中InitADOCmd (_Command** ppiCmd)方法。
这个方法利用ADO.Command::put_ActiveConnection方法来建立数据库连接的：
varConn = _bstr_t("Provider=SQLOLEDB.1;……”);
hr = t_piCmd->put_ActiveConnection(varConn);
在Windows XP环境中，循环调用这个函数到了1980次，程序就出现几秒钟的停顿。之后，就得到0x80004005的错误返回值。这个值是由put_ActiveConnection方法返回的，并不是异常。所以看不到ADO异常描述。
我们通过测试程序停滞时，立刻用一个VBS脚本再次请求建立数据库连接。于是，VBS脚本一起停滞，隔了几秒钟后，抛出异常，错误描述为：
"[DBNETLIB][ConnectionOpen (PreLoginHandshake()).]一般性网络错误。请检查网络文档。"
之后的1981、1982、...次put_ActiveConnectio调用，都会是同一个错误返回值。
在SQL Server事件探查器中，看到1980次调用之前，都只有Audit Login事件。除非关闭测试程序，才会唰地一下所有的Audit Logout事件出来了。
有时候，当第1981次建立连接的请求被SQL Server 2000认为超出允许范围时，SQL Server 2000会主动将这一千多个的连接同时全部中断。于是乎，在SQL Server事件探查器中，你也可以看到唰地一下所有的Audit Logout事件出来了。
如果测试程序维持着这些数据库连接的话，内存会持续增长，如下所示：
在WinXP上(Win2000上允许连接的数目少)，
情况1：
单纯反复执行ADO.Command::put_ActiveConnection，则只有“Audit Login”事件，没有Logout事件。这种请求最多达到1980之后，就会出现“一般性网络错误”。
情况2：
如果是反复执行
ADO.Command::put_ActiveConnection方法，然后又执行了查询，返回记录集，则这种循环最多达到483之后，就会出现“一般性网络错误”。
在实际测试中，第1种情况，最开始Demo用了6MB内存，最后累积的内存是：104MB。
第2种情况下，最开始Demo用了6MB内存，最后累积的内存是：39.5MB。
你可以通过下面的SQL语句察看当前与SQL Server保持的连接都来自于哪里，有多少个：
SELECT dbid,DB_NAME(dbid) as DBName,hostname,status,last_batch
FROM sysprocesses
WHERE DB_NAME(dbid)='%YourDatabaseName%' AND (last_batch > 'YY-MM-DD MM:SS:00')
ORDER BY last_batch DESC
总结：
虽然这种情况出现的比较罕见，但是如果排除了网络质量原因，你也许可以注意一下当前服务器与SQL Server的connection数目是否维持在一个正在高涨的数量。
当连接不断增加的时候，就要当心，服务器连接数据库是有一定限制的，而且达到最大值后，其他程序再次请求连接时，就可能得到“一般性网络错误”的警告，而且错误号80004005也并没有说明到底发生了什么，SQL Server和ADO并不会告诉你连接数已经达到最大值。
Disclaimers：
本文档所包含的信息代表了在发布之日，zhengyun对所讨论问题的当前看法。本文档不应理解为zhengyun一方的承诺，zhengyun不保证所给信息在发布之日以后的准确性。
上一页 [1] [2] [3] 下一页
没有相关教程
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
