ADO的并行处理能力是否很弱？在线程中使用ADO并行查询经常出错，请教。 (200分)

能解决问题，用户说满意就是好滴！[]

是啊。不过，Dirk 的这个测试还是满不错的，总算逼着去看了看源代码。并行早前在 X86
上除了 FPU 外，确实有点自欺欺人，现在有点不同了，部分东西确实开始真正并行了，尤
其是高速缓存。
关于连接，不对网络造成问题，成问题的是服务端连接池开销，实际上突然出现的多个连接
正是多线程需要的，MSSQL 可以工作在多 CPU 下，我的机器启动 MSSQL 就会检查我是否使
用多 CPU 证书，检查完后它会自动调整到多 CPU 状态工作。如果使用 TADOConnection 只
为了使连接数减小，好像也是不可能的哇，假如 TADOConnection 是一个可以多线程工作的
元件，它应该不会让连接排队吧，因为它做的工作只是记录连接，以避免连接和连接之间张
冠李戴，如果它让连接排队，那么它本身就成了一个瓶颈，SQL 服务器舒服了，多线程并行
也就不存在了。使用 TADOConnection 最大的好处，是不是它可以直接返回 Error 对象啊？
关于网络，它的问题是数据集的返回。如果使用一个透明的游标，效果是好了，来来回回的
数据量就大了。实际上到目前为止，这个问题还是没有办法解决的，只能是择中考虑。

多线程，sql server管理器在导入倒出数据就是这样，效率很高，不知怎么实现

　　呵呵，只要大家有兴趣，技术讨论还是很喜欢的，那就讨论到底吧。
　　
　　其实我并不是要证明“并行　＝　单行”，而是说在并行时，某些环节，实际上还是必须单行，比如CPU，如果是多个的话，存在并行问题，但如果多个CPU共同执行一个任务的话，肯定有个同步的问题，同步，就意味着各进程的进度不一致，有前有后，有些线程必须等待另一些线程，可以说，在等待的这一刻，其实就是“单行”。
　　同理，在程序代码环境，多线程确实是并行的，但还提供了同步功能，为什么？就因为有些工作，是互相制约的，一定要按指定的次序执行才行，比如说同一ADOConnection下各个ADOQUERY的OPEN操作，是一定要一个一个来才行的，不能嵌套(我认为)，但也许是ADO开发人员的疏忽，或者是多线程操作的测试不够，他们并没有在这一操作上加入锁定机制，故而会产生相应的错误。这时，如果以一个程序员的眼光来看这个问题，就可以说：它在这一部分没有处理好，那么我就把这一部分补充好，使它避免这个错误。但如果是从一个纯客户的眼光来看，就会说：ADO的多线程是不安全的，以后不要用它，或者宁可多浪费点资源，还是用其它的(土？笨？)办法吧。
　　关于打开多个ADOConnection时浪费资源，这个是从书上看到的，至于对程序运行的性能有多大影响，我们并没有一个量化的数据，说到这里，就很佩服李维的态度，他在介绍“dbExpress”时，就做了很多查找、读取数据的测试实例，用实在的数据来比较“dbExpress”和“BDE”的优劣，那么对于多个ADOQUERY引入各自的ADOConnection，究竟在效率和性能上和共用一个ADOConnection有多大区别，如果dirk有兴趣，倒不妨用实例测试一下。
　　
　　互相讨论，不在于最后谁对谁错，关键在于和同行进行交流，了解和思考了一些更新的东西。不过现在很讨厌自己说话老是语锋逼人，唯我独尊的情形了，搞的别人都不好发言，自己也觉得很没趣，所以最近也深自收敛。其实很希望别人能有理有据的批驳自己，可惜[]！是不是当年的独孤求败也是这份心境，不得而知[]。

对于每个线程中创建一个ADOConnection是测试过了的，不过没有具体计算时间，因为50个线程的运行速度明显比共用一个ADOConnection慢很多，我考虑可以使用线程自用ADOConnection的原因是因为同时开7、8个线程的速度还是可以忍受的，毕竟开50、100个线程是做压力测试，实用中不太可能出现这样的情形。

你没有做同步，我以前做的时候遇到过，后来做了同步就可以了。很好的啊。