需要帮助来设置使用除TIMESTAMPS以外的更改跟踪机制的自定义DBSyncProvider [英] Need Help in setting up custom DBSyncProvider that uses Change Tracking mechanism OTHER THAN TIMESTAMPS

问题描述

我希望Sync团队中的某位人员可以帮助我准确理解同步编排的工作方式，以便我可以使用不使用传统时间戳的同步应用程序作为检测"更改"的机制;从一个SQL Server
对等端同步到另一个...

I'm hoping someone on the Sync team can help me to understand exactly how the sync orchestration works so that I can get a sync app working that does NOT use the traditional timestamps as the mechanism to detect "changes" to sync from one SQL Server peer to another ...

我创建了一个点对点同步应用程序，它使用更改跟踪存储过程成功同步了2个SQL Server和支持代码由Sql Server简单提供程序生成。我使用自定义DBSyncProviders和自定义适配器
创建了我的自定义应用程序，并且只使用相同的表插入了由简单提供程序应用程序生成的SQL。一切正常。

I have created a peer-to-peer sync app that successfully syncs 2 SQL Servers using the change tracking stored procs and supporting code as is generated by the Sql Server simple provider. I created my custom app using custom DBSyncProviders and custom adapters and just plugged in the SQL that was generated by the simple provider app using the same tables. Everything works fine.

现在 - 我已经改变了代码，试图达到我真正前进的地步 - 这是为了消除基于TIMESTAMPS的变更跟踪。我基本上试图通过检测源版本字段是否与目标对等体上的相应字段不同
来尝试使同步过程正常工作。我使用Uniqueidentifier列来表示我的"版本"。

NOW - I have changed the code to try and get to the point where I am really heading - which is to eliminate change tracking BASED ON TIMESTAMPS. I basically am trying to get the sync process working simply by detecting if a Source version field is different than the corresponding field on the Destination peer. I am using Uniqueidentifier columns to represent my "versions".

这里没有枚举我所有的存储过程（希望没有必要），在SelectIncrementalChanges命令中，我简单选择特定版本的所有记录。我已经创建了一些审计表，我从更改跟踪
触发器和我的适配器命令的同步存储过程中写入，我验证当我调用sync（）方法时，SelectIncrementalChanges命令确实触发并选择我想要的行。但是，我不会在目标对等体上插入行。我的Insert
命令完全执行生成的存储过程为简单提供者应用程序执行的操作 - 如果新记录在基表的跟踪表中不存在，则它只是插入新记录。

Without enumerating all of my stored procs here (hoping that won't be necessary), in the SelectIncrementalChanges Command, I simple select all records for a specific Version. I have created some audit tables that I write into into from the change tracking triggers and the sync stored procs for my adapter commands, and I verified when I call my sync() method, the SelectIncrementalChanges command does indeed fire and select the rows I want. I DOESN'T, however, insert the rows on the destination peer. My Insert Command does exactly what the generated stored proc does for the simple provider app - it simply inserts the new record if it doesn't already exist in the tracking table for the base table.

 

我的真实问题是 - >在同步业务流程中究竟发生了什么，它与同步代理通信我的源对等端上存在的记录并插入到我的目标对等点上？

MY REAL QUESTION IS --> what exactly happens within the sync orchestration that communicates to the sync agent that the records that exist on my Source peer and to be inserted on my Destination peer?

 

显然我在这里缺少一些东西。我的SelectIncrementalChanges命令基本上选择了我的Source上的所有记录，而Destination目标对等体上的Insert存储过程只是插入记录（如果还没有跟踪表）（它不是）。
为什么不同步这些新记录？

There is obviously something I am missing here. My SelectIncrementalChanges command basically selects all records on my Source and the Insert stored proc on the Destination peer simply inserts the record if not already n the tracking table (which it isn't). Why doesn't it sync these new records?

 

我在每次测试运行之前删除并重新创建我的范围记录;我删除了Source对等体上的所有基表数据和跟踪表数据。但是当我测试时，它就不会同步。
我收到的错误是没有从SelectIncrementalChangesCommand的结果集中遗漏'sync_update_peer_key'。 我的猜测是，这与我的目标同行没有插入记录的原因有关。

I delete and recreate my scope record before each test run; I delete all of the base table data and tracking table data on my Source peer. But when I test, it just won't sync. I did get an error about not having the 'sync_update_peer_key' missing from the SelectIncrementalChangesCommand's result set.   My guess is that this has something to do with why the records are not inserted on my Destination peer.

我尝试将这些列添加到结果集中，例如：

I tried adding these columns to the result set, such as:

 

声明@ts时间戳

set @ts = @@ DBTS + 1

    

SELECT

    base.CustomerID

    ，base.CustomerName

    ，base.SalesPerson

    ，base.CustomerType

   

    ，0为sync_row_is_tombstone

    ，@ t as sync_row_timestamp

    ，@ t as sync_update_peer_timestamp

    ，null as sync_update_peer_key

    ，@ t as sync_create_peer_timestamp

    ，null as sync_create_peer_key

declare @ts timestamp
set @ts = @@DBTS+1
   
SELECT
    base.CustomerID
    , base.CustomerName
    , base.SalesPerson
    , base.CustomerType
   
    , 0 as sync_row_is_tombstone
    , @ts as sync_row_timestamp
    , @ts as sync_update_peer_timestamp
    , null as sync_update_peer_key
    , @ts as sync_create_peer_timestamp
    , null as sync_create_peer_key

 

我也试过为这些字段返回所有NULL，但我猜测vakues很重要，在某处比较，但我不知道逻辑。我承认我对所有时间戳和关键列都非常困惑，并且没有花时间
来完全理解它，因为我的目标是使用版本密钥而不是时间戳。

I also tried returning all NULLs as well for these fields, but I'm guessing the vakues are important and are being compared somewhere, but I don't know the logic. I admit I am very confused by all fo the timestamps and key columns and haven't taken the time to fully understand it since my goal is to use a version key instead of timestamps.

 

有人可以帮我弄清楚在同步编排中实际发生了什么逻辑，以根据命令的结果集实际应用新的插入和更新（或者存储过程）？ 我需要知道它是如何工作的（比较什么）
以便我可以成功地比较行版本而不是时间戳来确定是否应该与我的同伴同步一行。

Can someone please help me figure out what logic is actually happening within the sync orchestration to actually apply the new inserts and updates based on the result sets from the commands (or stored procs)?  I need to know how it works (what is compared) so that I can successfully compare row versions instead of timestamps to determine if a row should be synched with my peer.

 

谢谢，

Glenn

 

ps - 任何及时的帮助非常感谢...我正在绝望！

ps - any timely help GREATLY appreciated ... I am getting desperate!

 

 

推荐答案

您可能需要查看文档中的Enumerating Changes或访问
http://msdn.microsoft.com/en-us/library/bb902832(v=SQL.100).aspx

SelectIncrementalChangesCommand只是枚举自上次双方同步以来发生了哪些变化，但结果不一定发送给客户端。相反，将其与目的地的"知识"进行比较。如果它已经知道这些
的变化，因为它可能已经收到来自另一个同行的相同变化。

The SelectIncrementalChangesCommand simply enumerates what has changed since the last sync between the parties but the results is not necessarily sent to the client. Instead, this is compared to the destination's "knowledge" if it already knows about these changes as it may have received the same changes already from another peer.

例如，A和B同步来自C的行X1

e.g., A and B syncs row X1 from C

C更新X1

与C同步并获取更新的X1

A syncs with C and gets the updated X1

B与A同步并获取更新后的X1 C通过A

B syncs with A and gets the updated X1 of C via A

B与C和X1的同步被检测为自A和C最后同步以来发生了变化，但是B已经知道了这个变化，因为它已经从A得到它所以变化不是发送给B

B syncs with C and X1 is detected as changed since A and C last synched, but B already knows about the change since it got it already from A so the change is not sent to B

同样，afaik，对等密钥标识创建/更新该行的对等方。

also, afaik, the peer keys identifies the peer that created/updated the row.

hth

 

这篇关于需要帮助来设置使用除TIMESTAMPS以外的更改跟踪机制的自定义DBSyncProvider的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！