Tquery的真相？？？！！！（欢迎大侠们讨论）(300分)

我用D5+SQL7建立了一个三层系统，远程数据模块为TSession+
Tdatabase+Tquery+Tdatasetprovider，一直以来运行非常正常，正暗自高兴，
忽然有一天，用SQL Monitor检查了一下执行情况，才发现两个大问题。
一、假设有两个Tquery，SQL语句分别为Select * from table1;
Select * from table2，客户端用两Clientdataset与之相联，Packedreacord
均为20，当打开第一个Query时，SQL Monitor可以清楚看到有二十个
Fetch语句，一切正常，但这时再打开第二个Query，怪事发生了，它会
先将Query1余下的所有记录全部Fectch过来，再执行Select * from table2，
也就说，假定table1有一万条记录，打开时，会先取20条，如果这时再打开
其它query，就会先将余下的9980条记录全下到应用程序服务器（不会下到
客户端），再打开其它查询，反之亦然，速度非常慢。
其时这一问题也好解决，给每一个query指定不同的databasename就行，
但如果有数十个Query，是不是很烦，也很不好维护。
二、如果只有一个query，不会出问题吧。NO，你试着修改一个值，再
保存看，同样的事情又发生了，它会先将所有余下的记录全下应用程序服务器，
再保存。记录少，不会有什么感觉，但记录多，可就够等了，怪不得经常有
人抱怨Applyupdates慢了。
这两个问题不止是三层，C/S也如此，由于其极大的影响程序的执行效率，
必须解决，几天来也想了不少办法，但总觉不够理想，以下是一些偿试。
一、实际上造成这一问题的根源就在SQL语句上，如果SQL语句不加
Where限制条件，面对所有记录，就会出现这一问题，但如果SQL语句每次
只返回不多的记录，虽然仍旧会传余下的记录，但由于记录不多，也就无有谓。
但这样的SQL语句不好写啊！比如怎样写才能20条20条的往下返回，
我办不到，甚至20条左右都不行。
二、用ADO：Select top 20 * From table1 Where key>???，
这条语句是可以每次往下返回20条记录的，但ADO不够稳定（第一次出现
的东西都这样），并且SQL Monitor无法跟踪ADO，怎么敢用。
三、用Ttable代替Tquery，说实话，这样做效果非常好，两个问题
立即荡然无存，数据存取的效率非常高，但现在几乎所有的文章都劝不用
Ttable，论坛更是如此，不知道Ttable会不会有其它毛病，所以一直下
不了决心。
四、数据的存取全部自己写，不用Delphi代劳，这样做当然是可行了，
但劳动强度是不是太大了，并且出的问题肯定也不会少。
我已经无计可施了，各位大侠有何高见。

用Tquery直接做SQL语句的处理，而且每个语句之前都用query1.close来释放掉前一次的资源。
此外，在ExecSQL之前最好是prepare一下，执行后再unprepare，据help上说这样能大大
提高效率，但耗费数据库服务器的资源。prepare对open语句无效。

其实使用TTable页不过是使用query来实现的，只不过ttable可以将数据全部下载倒客户
机器上。我觉得IKnow所说的比较合理，我都是这样做的，没发现你所说的问题。

To Ikown 在执行之前用query1.close，我没用过，估计是可行的，但如果要同时打开
两个查询或两个录入窗口，难道将第一个关掉不成。况且在存盘时，就算
你先close，open，再存盘，同样的情况会再发生。
To Zengre 这两天我仔细研究了Ttable，完全改变了我以前的观念，我用一个十万条
记录的表进行操作，发现Ttable的效率高的惊人，在数据输入时绝对比
Query高，并且在query中的一些问题在table中根本不存在。通过SQL
跟踪也验证了这点。
另：你说用Query没有我遇到的问题，是否用了什么决窍，可不要保密呵（^_^）。

嗯，我也想说一句，对TTable的“偏见”大概始于delphi3，
那时候一个是delphi刚流行，另一个是sql server之类的数据库也开始流行
因此用的人很多，却发现对于client server模式，ttable兼容性极差。
结果ttable的恶名由此传开，每个人都嗤之以鼻。
但是，既然用得少了，就带来一个副作用 -- 即使后来的delphi版本对
ttable作了很大改进，我们也很难知道，因此依然拒绝使用。
我偶然情况下使用ttable，发现简单的对于整个表的增删改之类的操作，
ttable还是非常合适的，比tquery要好得多，至少避开了极为令人讨厌的
requestlive的问题。也希望大家改变观念，还ttable一个清白

同时打开的话也无所谓的呀，比如query1和query2，但是如果在query1打开的情况下需要用
query1重新获取其他数据的时候，就应该先close了。
保存的方法通常不应该用query的applyupdate之类的，因为此时query会将数据库做一个
快照（snapshot），而且更新方式缺省是whereAll,而不是whereChanged，即它的更新是用
delete + insert, 而不是update
通常意义上query只是做sql语句的处理的，而对整表数据进行编辑的话还是用ttable，虽然
对整表数据进行编辑不是一个好的思路.

我就用Ttable,除了不够通用，其他方面都不错
关注

嗯，看来有空要好好研究一下TQuery的源代码了，
谁有sql server 2000的经验？

我用Ttable、Tquery传送数据总是不能传递字符型的，后来改用adoquery 才好了，
你有什么看法吗？我用的是sql server+delphi4.0

TTable确实不行啊，温兄，你试试去用TTable去对离线数据库来个INSERT、UPDATE ：）
呵呵。等待的时间可以去喝早茶了。
对三层来说，select * from XXX 是致命的错误，这样做当然慢了。有什么好抱怨的。
一定要这样做，就用C/S吧。别抱着C/S的想法来做三层。就赶个三层的名字时髦。。。

旧雨：我也遇到同样的问题，不过我的数据库是从access导到SQL 7。0才会这样
我已前用SQL 7。0直接建的数据库都不会这样，不知道为什么?

to 老吴：
好像不太对吧？我说的关于ttable的误解是指在client/server模式下....
就算对离线数据库的操作有问题，也不影响我的结论呀？ )
并且，对于本地数据库本来就是ttable的强项，不存在这个问题。
正因为如此，与你说的相反，我这里用ttable对离线数据库(74M)
insert/update/delete都是一瞬间啊，不知你所指何事？

只见鸡蛋右手在空中有力地一挥，做出了大会结论：
“总之，目前全国上下形式一片大好。但是，我们不可以忘记。。。”
“用TTABLE来做本地数据库，是一个良好地选择。是社会发展地必然趋势。
但是，在C/S，三层上用TTABLE，只能说对C/S，三层模式的基本概念还没
有搞清楚。对阶级敌人的面目还不清楚。这是我们工人阶级要警惕地。。。”
（省略了50000字。。。。。。。。。。。。）
呵呵
温： 您老的是什么机器啊？ 我这里用TTABLE打开数据库，起码要5分钟。：（

这个问题好象李维的“分布式多层应用”那几本书里有提到的，
大概是系统篇里面吧。我好久不看了，忘了。不好意思。
（不知道吴剑明可不可以作证小猪的记性一向很差的，所以我真的不是故意忘记的）
哪位手上有书的大下帮忙翻翻吧（我不保证一定能找到哦:） ).

我可以做证明，小猪的记性差到天上没有，地上无双。前无古人，后无来者。。。。

我认为TTable的确得到了优化，特别是d5里（d4我几乎不用，呵呵）
不过，我始终认为，TTable的优化，是建立在BDE/IDAPI级别上的。
而且这样的优化，即使在C/S开发中，也是很有效率的。

呵呵，我保持个人意见。但愿意看见大虾给出说服我的理由。

to 吴剑明:
你没有权利保留意见，你只有权利保持沉默... ^_^
在操作速度问题上，你所说的“起码要5分钟”仅仅是一个事实的陈述，而不是你的意见。
而这个事实肯定建立在你的配置或者参数有错误的基础之上，
因此它所产生的一切结论也都无一例外是错的。
不信你可以问在座任何一位，如果有人还有人使用ttable需要5分钟打开数据库，
我就......我就懒得理你们了@$%#$^%$#
关于C/S方面，前面CJ的意见与我的“误解说”基本算是一致的，如果两个人
用实践经验还说服不了你，我也没觉得自己有什么损失
关于三层的问题，不知道你有没有看过老左帖的那段IRC聊天，
我个人根本认为现在的这些三层技术就是胡扯，毫无意义，因此不关心，也不发表意见。
不过就逻辑的角度而言，你所说的“三层上用TTABLE，只能说对C/S，三层模式的基本概念还没有搞清楚”
显然站不住脚，因为即使用ttable,也是放在provider那一层，也就是中间层上，
和qeury乃至于ADO没什么区别，与三层模式的概念和应用毫无冲突，不知道诸位以为如何。
附：我的环境：
1. BDE 的MSACCESS driver，DAO3.5(因为BDE只支持到这个版本)
则打开/增/删/改均一瞬间完成（74M的离线数据库）
2. BDE的ODBC+MS Access的ODBC driver，打开/增加/修改一条记录，
瞬间完成；删除一条记录时间慢的难以忍受，经过sql monitor跟踪，
发现删除后出现了fetch所有记录的现象，估计为ODBC driver太差或
逻辑与BDE不协调所致。
ps:只有使用ADOquery/ADOtable，在指定client cursor的时候，才会出现你所说的那种情况，
我不记得BDE是否有指定client cursor的地方了，好像是没有。
因此，如果你想试验，请新增一个BDE alias,然后new 一个 project，
然后放一个ttable，如果这样还是5分钟才能打开数据库，你的CPU风扇是不是该修一下了？ ^_^
还有，就是不要一相情愿地给letters表加索引，如果你加了，请把索引删掉，你会发现...

不争就不争。嘿嘿。
》》而这个事实肯定建立在你的配置或者参数有错误的基础之上，
这个我可不承认噢。呵呵，BDE有多少参数可用啊？还会“配错”？
哦，说了不争的，怎么又争了。：）
BTW：温兄写完了“钦此”后，还会高喊“谢恩呐”么？ ^_^

我说呀，你们的思维方式多多少少都有点问题，就是不相信实践检验的才唯一正确。
我可以承认我的BDE配置错误，行了吧？我承认我的机器不知道什么地方有毛病，可以了么？
但是在我的机器上用ttable操作74M的access数据库都是一瞬间完成，
换句话说，ttable是可以（注意，可以）由于BDE的配置“错误”或者“机器出毛病”而运作如飞的。
既然如此，说明ttable具有这个能力，因此也就不可能因为其内部代码的问题而导致不具备这个能力。
因此，你对ttable的一切偏见，还有什么存在的依据呢？所剩下的不仅仅是应该找出这毛病和错误在什么地方么？
然后把BDE配置改错，把电脑搞出毛病，以后就这么用，不是挺好么？ *_~~~~~
再说了，我有说是BDE错误么？你的jet没升级，用的ODBC，delphi没patch...
等等原因多了，总之一条，我这里可以快，就没有理由说它不能快，这是个能不能的问题，
不是个是不是的问题。从逻辑上讲，你无论重复多少次“5分钟”的经历，都不能说明任何问题。

还等什么？谢恩吧？？？？