学习ADO连接池是个很枯燥很烦恼的事，和显示统计的报表,实际减轻了做报表的许多麻烦,初期未注意用户数据量的问题,一直没有什么问题,但是随着用户的数据量的急剧增大,已达百万条,特别是在做内联接的查询时。
为了尽量不更改数据结构(如可以用增加表的方法,或是用存储过程的方法,或是用job的方法先期统计等),所以一直在试验能不能在ADO连接池解决,先后尝试了许多方法,终于试验成功,我的连接数据库的公用文件是#t#
ADO连接池其实就是OLEDB连接池，是存在的。不过，MSDN的资料显示，连接池应该有至少一个常驻的连接存在才会起作用，ADO连接池所以应该创建一个全局的连接并打开它。然后，在应用程序中创建每次可用的临时连接对象，再使用它。全局对象在程序退出释放，但并不使用。你可以测试这样做的效率和共享一个连接对象的效率。
死锁的原因是因为事务中加锁的顺序。如果都是隐式的事务即单条SQL语句基本不会造成死锁。显式事务和游标操作即recordset的movenext等，ADO连接池会造成死锁，要分析事务的加锁过程，更新锁、只读锁、独占锁等的次序问题。如果事务的开始就是独占锁或更新锁大多数情况不会死锁。
COM的智能指针_ConnectionPtr已经封装了异常机制不需要FAILED(HRESULT)，源程序if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this)); ConnectionPtr.Close是关闭连接但不是释放COM对象，释放对象要_ConnectionPtr.Release()，ADO的程序注意MDAC的版本，***2.6以上。
pooling是ado自己实现的，对开发者是透明的，不过要想充分利用ado的pooling机制，需要注意几点问题 ***：ADO连接池必须用完全同样的连接字符串 第二：用完connection对象后，尽量快的调用close()关闭它，在vb,vbscript里也要显式的调用close() 这样ado会自动把连接放入池中，直到超时或应用程序关闭。
com+里的pooling和ado的pooling基本上是不相干的，只有当com+对象池中某对象被完全清除时，和此对象联系的ADO连接池中的连接也会清空。 ado.net中连接池和ado中基本相同，只不过你可以明确的选择不使用连接池机制。
