0

Microsoft 同期フレームワークを使用して、SQL Server 2008 R2 サーバーと多数の SQL Server CE クライアントの間でデータを同期する .NET アプリケーションがあります。

最初の同期はサーバー上のデータを正常にダウンロードしますが、同期ログは、ダウンロードが完了したばかりの変更されていないデータのアップロードを実行することを示しています。これにより、初期同期時間が大幅に延長されます。

以下の SQL CE ログから抽出します (これは、テーブルの 1 つの最初の同期です)。

***** Client Provider Commit Transaction ****
Connecting to database: Data\Database.sdf
**** Client Provider Begin Transaction ****
----- Client Applying Changes from Server for Group "Staff" -----
----- Applying Deletes for Table Staff-----
Deletes Applied: 0
--- End Applying Deletes for Table Staff-----
----- Applying Upserts for Table Staff-----
----- Applying Inserts for Table Staff-----
Inserts Applied: 1
----- Applying Updates for Table Staff-----
Updates Applied: 0
--- End Applying Upserts for Table Staff---
Staff: Set ReceivedAnchor value: 1832
--- End Client Applying Changes from Server for Group "Staff" ---

これは、変更がサーバーに誤ってアップロードされた場合のログです。つまり、何も変更されていないのに更新済みとしてフラグが立てられます。

SELECT ut.* FROM    (select ut0.* from [Staff] as ut0 where      (ut0.__sysTrackingContext <>
@CNTX OR ut0.__sysTrackingContext IS NULL)      AND ut0.__sysChangeTxBsn >= @LBSN    ) as ut  
LEFT OUTER JOIN   (select txcs0.* from __sysTxCommitSequence as txcs0) as txcsInsert  ON 
ut.__sysInsertTxBsn = txcsInsert.__sysTxBsn  LEFT OUTER JOIN   (select txcs0.* from     
__sysTxCommitSequence as txcs0) as txcsUpdate  ON ut.__sysChangeTxBsn = txcsUpdate.__sysTxBsn 
WHERE    COALESCE(txcsUpdate.__sysTxCsn, ut.__sysChangeTxBsn) > @LCSN AND COALESCE    
(txcsUpdate.__sysTxCsn, ut.__sysChangeTxBsn) <= @ECSN   AND   (COALESCE(txcsInsert.__sysTxCsn, 
ut.__sysInsertTxBsn) <= @LCSN OR    COALESCE(txcsInsert.__sysTxCsn, ut.__sysInsertTxBsn) IS NULL 
OR    ut.__sysInsertTxBsn IN (SELECT SyncBsn FROM __syncTransactions))
Parameter: @LCSN Value: 0
Parameter: @LBSN Value: 0
Parameter: @ECSN Value: 408
Parameter: @CNTX Value: 73c9795b-29e5-49c3-8a66-f99f667225d5
Update for row with PK: StaffId = 1

サーバー側では、追跡の現在のバージョンは最初の同期中に問題なく、ダウンロードされたレコードが新しいとクライアントが考えているため、ある時点で増加します。

これを引き起こしている可能性があることの 1 つは、SyncScope をセットアップするためにトラッキングが無効になってから有効になっていることです。これは、最初の同期の後に行われます。

役立つ情報を十分に提供できたかどうかはわかりません。もっと提供して幸せです。

どんな助けでも大歓迎です。ありがとう。

4

2 に答える 2

0

初期同期はどうしていますか？同期フレームワークを使用せずに実行している場合、または追跡が無効になっている場合、同期フレームワークは最初に何が同期されたかを認識しません。

于 2012-09-22T03:07:03.880 に答える
0

問題を解決しました（少なくとも実行可能な（理想的ではない）ソリューションで）。面白いデザインです。同期には 3 つのユニットが関与しています。サーバー、中央同期デバイス、およびエッジ デバイス。同期は次のように行われます。

  1. 中央デバイスはサーバーとの双方向同期を実行します
  2. エッジ デバイスは、中央デバイスへの双方向同期を実行します。

サーバーには 2008 R2 があり、中央デバイスとエッジ デバイスは SQL CE を実行しています。

中央の同期とエッジ デバイスはサーバーから初期データを取得しますが、その時点ではデータがどうなるかわかりません。アプリケーションが開始されると、その役割が決定されます。CE から CE への同期を可能にするために、セントラル デバイスとエッジ デバイスでトラッキングを無効にしてから再度有効にする必要があるため (上記のコメントで例外をスローしていたため、これを機能させる他の方法を見つけることができませんでした)、 CE から SQL 2008 への同期では、上記の問題が発生します。つまり、最初に同期されたデータがサーバーに再送信されます。これは、送信されたアンカーを手動で設定することで解決されましたが、CE データベース間で初期データが相互に送信され、サーバーに返送されるという副作用がありました。

同期フレームワークは、行を更新して挿入しようとしたときにこれを競合として認識しましたが、さまざまな方法で競合解決ルールを設定しようとしたにもかかわらず、問題を解決しませんでした。次に、中央デバイスから最新のデータを取得できるように、データベースがプロビジョニングされる前にエッジ デバイスのデータを消去しようとしました。これで問題は解決しました。前述のように、これは理想的ではありませんが、実行可能なソリューションです。

エッジ デバイスをワイプせずにこれを解決する方法について何か考えがある場合は、初期セットアップ中に最初にダウンロードされたすべてのデータをリロードする必要なく、エッジ デバイスの同期セットアップを行うことが有益であるため、高く評価されます。

乾杯。

于 2012-09-24T09:25:47.513 に答える