TQuery.Prepare 和 TUpdateSQL 的弊端

Question

你用  TQuery  时是不是喜欢用  Prepare  呢？  
你用  TUpdateSQL  吗？  
那么你有没有发现它们的潜在危害呢？  
1。你用了  INSERT,UPDATE,DELETE  等  SQL  语句来做更新  
2。你用了  Prepare，并未使用  Unprepare  
3。你从未改变其  SQL  值  
 
有一天当你正在录入大量数据，而应用程序突然异常退出了（如停电了），那你会发现你辛辛苦苦输入了半天的数据全部丢失了。  
所以，Prepare  虽然可以改善效率，却带来了不可靠性。要用  Prepare，则要及时用  Unprepare。  
 
TUpdateSQL，内部也使用了  Prepare，Borland  却未告诉我们，所以如果用它做数据更新，你惨了。幸好还有解决办法：  
 UpdateSQL1.Apply(UpdateKind);  
 UpdateSQL1.Query[UpdateKind].Unprepare;  //  这样来保证数据真正写到数据库中  
 
抛砖引玉，请大家讨论。  

Answer 1

用TQuery 时一直喜欢用Prepare ，但没有用过Unprepare。

Answer 2

UpdateSQL1.Query[UpdateKind].Unprepare;一样不能保证写入，除非你的数据库支持同步写入，否则仍然不能保证是真正写入磁盘，可能是指写入到了磁盘缓存。

Answer 3

to pazee(耙子)：我在 Paradox 下用此方法解决了问题，老兄有什么高见呢？

Answer 4

据我所知 Prepare和Unprepare不是做你说的这些事情的。
但是，paradox 可以利用 BDE 的API DbiSaveChangesUses DBE；
在你的AfterPost 事件里面写  DbiSaveChange(DataSet.Handle);
这个可以保证强制写磁盘，但是他会影响性能，只能支持paradox和DBF。好一点的办法是采用类似NTFS这类强健的文件系统，NTFS自身就有事务机制，几乎不会发生类似FAT文件系统FAT混乱的文体。

Answer 5

只有 pazee(耙子) 老兄发表了看法，难道没有别的意见了吗？

Answer 6

现在的CSDN大不如前了，走了相当一部分高人，没落了……

Answer 7

呵呵 在下拙见 你的顾虑没有必要 delphi写程序时没保存断电都会丢，你说Unprepare 那何时调用呢，如果来不及调用就断电了呢？

Answer 8

可以在 UpdateSQL1.Apply(UpdateKind); 后立即调用UpdateSQL1.Query[UpdateKind].Unprepare; 如果还想提高效率，则可以在 Application 的 OnIdle 事件中进行。这样来保证数据丢失最少

Answer 9

UpdateSQL1.Apply(UpdateKind); 那何时调用呢，如果来不及调用就断电了呢？
用事务如何呢，要么全作 要么全不作。

Answer 10

何时调用 UpdateSQL1.Apply(UpdateKind); 我也不知道了，看需要而定吧。
我是说，在调用 UpdateSQL1.Apply(UpdateKind);之后，数据并没有安全地到数据库中，要保证安全，应当立即调用UpdateSQL1.Query[UpdateKind].Unprepare; 用事务是另一回事了，那是为了保证数据规则的正确性。我这里是说在大批量录入数据时，程序可能异常终止的情况下如何使工作不白做。

Answer 11

DBExpress 已经不再提供Prepare和Unprepare这些东西了，你怎么办？从Unprepare解决问题是不可能的，也是没意义的。
写磁盘的最终动作是操作系统完成的，难道你没遇到过即使你存盘了（比如word），死机或断电了，东西还一样丢失的情况，这通常是在FAT32下，因为虽然内容写入了磁盘，但是FAT表却没及时更新到磁盘，一样丢簇。