此处是否是DELPHI的一个BUG？？？？？？(0分)

在DELPHI的ADO访问方式中，超时问题可能是DELPHI的一个BUG，我都已经追述到她的OLE处
了仍然没有解决此超时问题，我同时使用VB写相同的程序，语句一样，发现执行相当好（
只是执行时间长与30秒，在50秒左右）。
不是BUG，那是什么？
无论是TConnection的connection timeout,command timeout,还是在connection string中
的time out=240等，还是ODBC的Connection pooling，我已经都试过了。我看了ADOINT中
的源代码，发现她就是用了connection timeout 和Command timeout。
那位大虾可以给我一个合理的解释？
怎么样才能解决此问题呢？是否我的程序有错误？
//**************************************************************************
//**************************************************************************
我在写数据库是，有时用BDE，有时用ADO。在用BDE时，可以很好的控制超时的问题，在
耗时的查询中，将超时的时间设置为240等即可。但是，在用ADO时，却发现无论我在哪儿
设置，在运算过程中，只要到30秒时，系统就提示超时错误，查询被停止。
我设置的地方有：
1、在ODBC的Connection Pools中将SQL SERVER 项目设置为：240；
2、在Connection控件中，设置：Time Out = 240；
3、在ADOQuery控件中，设置：Time Out =240；
为什么系统还是在进行查询30秒（一定时30秒）时报超时错误，而马上切换到BDE的Query
控件却运行50秒后得出了正确的结果？（同一个窗体中，不退出程序，不退出此窗体）
谢谢解答！

踢

>>

我检查过很多人的电脑了，效果都一样，此处应该是DELPHI的一个BUG，对于
ADOCOMMAND，ADODATASET两项，DELPHI可以没有什么错误的进行支持，不过对于
ADOTABLE，ADOQUERY，的的确确存在问题。我估计国外也有人意识到了这一点。我发现美国
西蒙出的《DELPHI 5 开发人员指南》上，说ADOQUERY，ADOTABLE ，只是为了照顾大家的
习惯才加上的。它鼓励用户使用ADOCOMMAND，ADODATASET。
那位老大向BORLAND公司汇报一下吧，该改一下了。