您的问题的答案是Post,ApplyUpdates和Commit做了完全不同的事情,通常发生在数据库应用程序的不同位置(进程)和上下文中。
Post
和ApplyUpdates
都是真正的客户端操作,而Commit
是可能(或不)需要显式调用服务器端完成交易的SQL操作。
如果您考虑使用三层服务器,最容易理解这些差异。 SQLite有点古怪,因为它不是一个真正的Sql Server,它被设计用来响应不同进程在不同计算机上的调用(尽管它可以做为三层系统的后端)。
关于最简单的传统3层安排有一个中间层的Delphi服务器,位于Sql Server(例如MS Sql Server)和客户端(通常是客户机上运行的Delphi程序)之间。Borland/EMBA的传统技术来实现,这是DataSnap
。
客户层通常包含TClientDataSet
(或第三方等效),从通过在中间层服务器的特殊TDataSet的后裔后端SQL服务器接收数据。虽然获得数据f从Sql Server到中间层通常涉及Sql Server上的事务,一旦数据全部加载到客户端层中的CDS中,SQL Server上就没有待处理的事务(除非您竭尽全力保留一个在服务器上打开的事务,对服务器的其他用户不友好并占用服务器上的锁定资源,这是有限的)。
在CDS(或实际上任何TDataset后代)中编辑数据时,会将数据集置于dsEdit状态(请参阅TDataSetState的联机帮助)。所做的更改是临时的,这意味着它们可以在CDS中撤消,直到您调用.Post,它将它们保存到CDS的Data(对于TClientDataSet,对客户端数据的更改可以在调用后回滚事件。发布,只要.ApplyUpdates尚未被调用)。请记住,在客户端层的CDS上调用.Post时,Sql Server上没有挂起事务(或者至少不应该有)。
调用.Post确实而不是导致更改传播回对应的中间层数据集。要启动这个功能,您可以在客户端CDS上调用ApplyUpdates,该应用程序将中间层中的TDataSetProvider传递给CDS与中间层的面向服务器的数据集。它是DataSetProvider(或者更准确地说是一个与之关联的TSqlResolver),它生成实际发送给SQL服务器的SQL,以便将更改应用到SQL数据库。因此,在一个标准的DataSnap 3层设置中,您无法直接控制Commit是否被调用。
Commit
是由Sql Server执行的SQL操作,作为完成交易的两种可能方式之一(另一种是Rollback
)。使用MS Sql Server f.i.,可以将与服务器的连接配置为自动将收到的UPDATE
,INSERT
和DELETE
语句包装在隐式事务中。
您需要关注事务控制的程度取决于您正在使用的后端服务器以及您的应用程序在与其他服务器数据的并发性方面的要求。如果您对SLite处理事务感兴趣,请参阅您正在使用的DBcomponents或其源代码的文档。
一些用于处理真正SQL Server的Delphi组件库确实支持用于控制服务器端事务的公开设施,例如, Interbase的IBX版本。
顺便说一句,用德尔菲的术语来说,CachedUpdates
是来自长期过时的BDE的暂停,这是Borland在各种后端服务器的公用DB访问框架上的首次尝试。它继承了一些TDataSet后裔的实现,并且(令人遗憾的是,imo)在FireDAC-- EMBA最新的跨数据库产品中取得了一些成果。
您可能不需要在Delphi代码中调用Commit。服务器连接可以(默认配置为)将隐式事务中提交给服务器的更改包装起来。对于没有真正服务器的SQLite,只有一个Dll,它可能依赖于你正在使用的TDataSet-descendant组件 - 检查他们的文档或源代码。 – MartynA