Jet OLEDB:事务提交模式和Jet OLEDB:用户提交同步有什么区别？

虽然Jet/OLEDB参数都比较有据可查我无法理解这两个连接参数之间的区别：

第一个：

Jet OLEDB：事务提交模式(DBPROP_JETOLEDB_TXNCOMMITMODE)

指示Jet是否写入数据 同步或异步磁盘 当事务提交时。

第二个：

Jet OLEDB：用户提交同步(DBPROP_JETOLEDB_USERCOMMITSYNC)

指示是否进行了更改 交易中进行的写入被写入 同步或异步模式。

有什么不同？什么时候用哪个？

这很长，所以这是简短的答案：

不要设置其中任何一个。这两个选项的默认设置可能是正确的。第一种是事务提交模式，控制Jet的隐式事务，并在显式事务之外应用，并设置为YES（异步）。第二个控制 Jet 在显式事务期间如何与其临时数据库交互，并设置为 NO（同步）。我想不出您想要在这里覆盖默认值的情况。但是，您可能需要显式设置它们，以防您在 Jet 数据库引擎设置已更改为默认值的环境中运行。

现在，长解释：

我翻遍了很多Jet相关的资源，看看能否找出这里的情况。这两个 OLEDB 常量似乎映射到顶级 DAO DBEngine 对象的 SetOptionEnum 的这两个成员上（详细信息here对于那些没有可用的 Access 帮助文件的人）：

  dbImplicitCommitSync 
  dbUserCommitSync 

这些选项用于在运行时针对任何特定连接覆盖 Jet 数据库引擎的默认注册表设置，或者永久更改注册表中存储的设置。如果您在注册表中查找 HLKM\Software\Microsoft\Jet\X.X\，您会发现在您正在使用的 Jet 版本的项下有一些项，其中两个是：

  ImplicitCommitSync
  UserCommitSync

Jet 3.5 数据库引擎程序员指南定义了以下内容：

• ImplicitCommitSync：值为 Yes 表示 Microsoft Jet 将等待提交完成。除 Yes 之外的值表示 Microsoft Jet 将异步执行提交。

• UserCommitSync：当设置值为“是”时，Microwsoft Jet 将等待提交完成。任何其他值都意味着 Microsoft Jet 将异步执行提交。

现在，这只是您已经说过的话的重述。令人沮丧的是，第一个默认值为 NO，而第二个默认值为 YES。如果他们确实控制着同一件事，你会期望它们具有相同的值，否则冲突的值将成为问题。

但关键实际上在于名称，它反映了 Jet 关于如何在事务内部和外部提交数据写入的历史。在 Jet 3.0 之前，Jet 默认在显式事务之外进行同步更新，但从 Jet 3.0 开始，引入了隐式事务，并且默认使用隐式事务（Jet 3.5 中有一些注意事项 - 见下文）。因此，这两个选项之一适用于事务外部提交 (dbImplicitCommitSync)，另一个选项适用于事务内部提交 (dbUserCommitSync)。我最终在《Jet Database Engine 程序员指南》（第 607-8 页）中找到了这些内容的详细解释：

用户提交同步UserCommitSynch 设置决定 所做的更改是否作为 显式事务...被写入 数据库在同步模式或异步模式。默认值...是 Yes，它指定 异步模式。它不是 建议您更改此值 因为在同步模式下，有 不保证该信息已被 在代码之前写入磁盘 继续执行下一个命令。

隐式提交同步默认情况下，当 执行添加操作， 删除或更新外部记录 显式事务、Microsoft Jet 自动执行内部 交易称为隐含的 交易暂时保存的 其内存缓存中的数据，然后 之后将数据作为块写入 磁盘。 ImplicitCommitSync 设置 确定是否进行更改 使用隐式事务是 同步写入数据库 模式或异步模式。默认 value...为 No，它指定 这些更改被写入 数据库采用异步模式；这 提供最佳性能。如果你 希望隐式交易成为 同步写入数据库 模式，将值...更改为是。如果 你改变了价值......你得到 与 Microsoft Jet 类似的行为 版本 2.x 及更早版本，当您 没有使用显式事务。 然而，这样做也会损害 性能相当大，所以它不是 建议您更改该值 这个设置。

注意：不再需要使用 显式交易以改善 Microsoft Jet 的性能。 A 使用 Microsoft 的数据库应用程序 Jet 3.5 应该使用显式 仅在以下情况下进行交易 可能需要回滚 变化。 Micosoft Jet 现在可以 自动执行隐式 交易以提高绩效 每当添加、删除或更改时 记录。然而，隐含的 SQL DML 语句的事务 已在 Microsoft Jet 中删除 3.5...参见“删除SQL DML语句的隐式事务” 在本章后面。

该部分：

删除 SQL DML 语句的隐式事务即使所有工作都在微软 Jet 3.0 消除交易 为了获得更好的性能， 仍然放置 SQL DML 语句 在隐式事务中。在 Microsoft Jet 3.5、SQL DML 语句 没有被放置在隐式中 交易。这实质上 提高运行 SQL 时的性能 影响很多的 DML 语句 数据记录。

虽然这一变化提供了 显着的性能改进， 它还引入了一个变化 SQL DML 语句的行为。什么时候 使用 Microsoft Jet 3.0 及更早版本 使用隐式的版本 SQL DML 语句的事务， SQL DML 语句回滚（如果有） 声明的一部分不是 完全的。使用 Microsoft Jet 时 3.5、有可能有一些记录通过SQL DML提交 声明，而其他人则没有。一个 这方面的例子是当 Microsoft Jet 缓存已超出。这 将缓存中的数据写入磁盘 下一组记录是 修改并放入缓存中。 因此，如果连接是 终止，可能有些 的记录已保存到磁盘，但是 其他人则不然。这是一样的 使用 DAO 循环例程的行为 无需明确更新数据 Microsoft Jet 3.0 中的事务。如果 你想避免这种行为，你 需要添加显式交易 围绕SQL DML语句来定义 一套工作，你必须牺牲 性能增益。

还困惑吗？我当然是。

对我来说，关键点似乎是 dbUserCommitSync 似乎控制 Jet 写入用于暂存显式事务的临时数据库的方式，而 dbImplicitCommitSync 与 Jet 在显式事务之外使用其隐式事务的位置有关。换句话说，dbUserCommitSync 控制 BeginTrans/CommitTrans 循环内引擎的行为，而 dbImplicitCommitSync 控制 Jet 在显式事务之外的异步/同步方面的行为方式。

现在，关于“隐式事务的删除”部分：我的理解是，当您在事务外部循环记录集时，隐式事务适用于更新，但不再适用于事务外部的 SQL UPDATE 语句。按理说，提高逐行更新性能的优化会很好，但实际上对 SQL 批量更新没有太大帮助，因为 SQL 批量更新已经非常快了（相对而言）。

另请注意，事实上，可以通过两种方式执行此操作，这使得 DoCmd.RunSQL 能够进行不完整的更新。也就是说，如果使用 DoCmd.RunSQL 执行，则因 CurrentDB.Execute strSQL、dbFailOnError 失败的 SQL 命令可以运行完成。如果您关闭 DoCmd.SetWarnings，您不会收到错误报告，并且您没有机会回滚到初始状态（或者，如果您被告知错误并决定提交，无论如何） ）。

所以，我认为发生的事情是，通过 Access UI 执行的 SQL 默认情况下包装在事务中（这就是您获得确认提示的方式），但是如果您关闭提示并且出现错误，您将获得不完整的更新应用。这与 DBEngine 设置无关——这是 Access UI 执行 SQL 的方式问题（并且有一个选项可以关闭/打开它）。

这与 DAO 中的更新形成鲜明对比，从 Jet 3.0 开始，DAO 全部包含在隐式事务中，但从 Jet 3.5 开始，只有顺序更新包含在隐式事务中，而批处理 SQL 命令（INSERT/UPDATE/DELETE）则不然。

至少，这是我的阅读。

因此，关于您实际问题中的问题，在设置 OLEDB 连接时，您需要根据您正在做的事情为该连接设置 Jet DBEngine 的选项。在我看来，默认的 Jet DBEngine 设置是正确的，不应更改 - 您希望使用隐式事务进行编辑，在其中遍历记录集并一次更新一行（在显式事务之外） 。另一方面，您可以将整个事务包装在事务中并获得相同的结果，所以实际上，这仅适用于您正在遍历记录集并更新且未使用显式事务的情况，并且默认设置似乎对我来说非常正确。

在我看来，另一个设置 UserCommitSync 也是您绝对不想保留的设置，因为在我看来，它适用于 Jet 在显式事务期间与其临时数据库交互的方式。在我看来，将其设置为异步非常危险，因为您基本上不知道提交数据时操作的状态。