RDA 冲突检测和报告
Microsoft SQL Server 2005 Compact Edition (SQL Server Compact Edition) 中的远程数据访问 (RDA) 可以为推送操作中无法在运行 SQL Server 的计算机上进行更新的行提供有限的冲突报告机制。
.gif) 重要事项： |
|---|
| RDA 中冲突的行被严格定义为由于从 SQL Server Compact Edition 推送到 SQL Server 表时发生错误而导致失败的插入、更新或删除操作。不同用户对数据所做的更改，只要不引起错误，就不会被认为是冲突。 |
尽管 RDA 不像复制那样提供特定的冲突解决程序，但 SQL Server Compact Edition 也可提供一个错误表来捕获所有冲突行。您可以在 Pull 方法中指定错误表。推送过程中发生的任何错误都将记录到此错误表中。通过使用错误表，您可以开发应用程序来管理冲突的检测与报告。
对推送到服务器的 SQL Server Compact Edition 数据库所做的更改将按其接收顺序进行应用。这将对 SQL Server 表进行更新，以反映最后一个用户所做的更改。
在 RDA 中，当某行无法从 SQL Server Compact Edition 推送到 SQL Server 时，将发生冲突。RDA 仅支持行级跟踪。因此，取决于 Push 方法中所选择的选项，有些行会成功，而另一些行则会失败。若要跟踪 RDA 中的冲突，请在 Pull 方法中指定 TRACKINGON 或 TRACKINGON_INDEXES。
使用 RDA 跟踪的表时，通过在传播数据时正确筛选表并使用稳定的网络连接，可以避免冲突和错误。
RDA 冲突是如何发生的
由于以下原因，对行所做的更改将无法在服务器上应用：
- RDA 可以专门对设备上跟踪表中已更改的每一行的插入、更新和删除操作进行跟踪。因此，如果客户端插入的行与服务器上在同一表中插入的行具有相同的主键值，则由于已经插入了该行，客户端的推送操作将会因错误而失败。
- 如果数据尚未针对各个用户进行正确分区，则当一位用户试图更新行时，另一位用户可能删除此行。
- 如果上一次推送操作中断，也可能无法将行推送到服务器，并产生错误。例如，假定用户开始将数据推送到服务器，其中包含插入操作，在推送过程中，网络连接中断。客户端将显示消息，告知由于网络连接中断而推送失败。但是，实际上在服务器上已经应用了更改。当客户端重新获取网络连接，并且用户试图再次推送相同数据时，由于在上一次推送操作中已经插入了一些行，这些行将无法应用。在这种情况下，应用程序应忽略错误表中因第二次推送存在重复的主键而失败的所有错误。
错误表
通过返回并在 SQL Server Compact Edition 数据库的错误表中存储错误和失败的行，RDA 可以跟踪数据冲突（即由于错误而无法在服务器上应用的行）。您将在 Pull 方法中定义此表。此后，如果在推送操作中出现错误，就会将错误存储到错误表中。
使用 Push 方法时，如果由于错误（例如重复的主键）而导致无法向服务器应用行，将引用最初在 Pull 方法中定义的错误表名称来解决行错误。Pull 方法的 ErrorTableName 属性指定用于存储推送错误的表的名称。错误表将立即创建，但最初不包含行。只有在 Pull 方法中指定了 TRACKINGON 或 TRACKINGON_INDEXES 的情况下，才可指定 ErrorTableName。
如果由于在 Push 方法中无法应用行而导致错误，则 SQL Server Compact Edition 将在表中为所发生的每个错误插入一条记录。除了基表中的所有列之外，还将添加另外三列以标识错误发生的原因和时间。s_ErrorDate 列指定错误发生的日期和时间。s_OLEDBErrorNumber 列指定向服务器应用行时所发生错误的 HResult。s_OLEDBErrorString 列是对错误的字符串说明。Push 方法完成后，如果在将行应用到服务器时出现错误，系统就会向应用程序报告警告（SSCE_WRN_RDAERRORROWSRETURNED，值 28800），应用程序可以检查错误表以确定错误原因。
维护错误表
删除 RDA 跟踪的表时，将自动删除所关联的错误表，即使错误表中仍然存在行。由于存在冲突的行无法在服务器上应用，因此开发人员必须解决认为有冲突的行。
有时可能需要刷新设备上的数据以正确解决以前向服务器推送数据时所发生的错误。建议您缓存错误表中的数据，以确保在删除跟踪的表时不会造成数据丢失。您也可以请求刷新后的数据并放到与原来跟踪的表不同名的另一个表中。
在数据推送后解决错误
在错误表中与失败的行一起存储的错误说明了该行在服务器上插入、更新或删除失败的原因。取决于错误类型的不同，有时了解服务器上数据的当前状态会非常重要。必须生成应用程序来处理这种情况，因为删除跟踪的表时也将删除错误表。
错误与非批处理事务
在非批处理事务（使用 Push 方法时启用 BATCHINGOFF 选项）中，将在行级别上检测冲突。冲突的行将被返回到应用程序并存储在指定的错误表中。例如，如果应用程序试图将无效的行推送到 SQL Server，则将该行返回此应用程序，并与指示冲突的错误消息一起存储在错误表中。
将冲突的行返回到错误表之后，将从原始表中删除该行。由于表未保留其原始状态，因此解决发生的冲突时会稍微有些困难。您必须将应用程序设计为允许用户更正冲突的数据。这样做可能会涉及到从服务器重新请求表以正确地解决问题。
删除设备上的表时也将删除错误表。您必须将错误表中的行缓存到某个临时位置，或者从服务器中请求数据并放到其他表中。由于存在冲突的行已从 SQL Server Compact Edition 数据库的表中移出，因此应使用正确的服务器数据重新刷新此表，这一点很重要。如果失败的行原来更新过，为确保在后续的推送操作中成功，必须再次更新同一行。如果已更新行，但却在服务器上删除了该行，则必须将该行重新添加到表中，然后重新推送，这时才会插入成功。
错误与批处理事务
RDA 还支持批处理推送（使用 Push 方法时启用 BATCHINGON 选项）。批处理推送要求在所有行都成功的情况下才进行完全推送。如果有一行失败，将不会执行完全推送事务，也不会更新任何数据。冲突的行将被复制到错误表中。这是首选项，因为其解决冲突的机制要稍微容易一些。与非批处理推送不同，基于 Microsoft Windows CE 的原始数据库将保持不变。您必须将应用程序设计为允许用户更正冲突的数据，并将其合并回基于 Windows CE 的原始数据库中。由于原来的行保持不变，因此，取决于错误类型的不同，可能并不需要立即重新请求服务器数据来确定行的正确解决方案。例如，如果行因为完整性冲突而失败，则可以更新设备上的行，并调用 Push 方法尝试将数据推送到服务器。由于在复制冲突的行之前会自动清除错误表，因此此选项还可以减轻维护任务。表中将只有上一次推送操作中出现的冲突。