Sync Framework 2.1でバッチ処理をカスタム変更トラッキングで使用する方法は？

Sync Framework 2.1では、バッチ処理ではサポートが組み込まれているように見えるので、一部のプロバイダではバッチサイズとスプールファイルの場所（およびその他の属性）について言及するだけで、バッチ処理が行われます。開発者は独自のバッチ処理ロジックを作成する必要はありません。Sync Framework 2.1でバッチ処理をカスタム変更トラッキングで使用する方法は？

ただし、これはSqlSyncProviderやDbSyncProviderなどのいくつかのプロバイダでのみ動作し、SQL Serverの変更の追跡に対応しているようです。カスタムチェンジトラッキングを可能にするClientSyncProviderやDBServerSyncProviderなどの初期のプロバイダでは、多くの機能拡張が行われていないようです。新しいバッチ処理機能をどのように使用して、カスタム変更追跡ロジックを引き続き使用できるかについての考え方はありますか？

私たちのカスタムロジックが非対称型データベース（ここでは、サーバーdbが複数占有されておらず、各クライアントdbがシングルテナントであるため）を組み込みチェンジトラッキングに移行するオプションはありません。

出典

2011-02-05 Roopesh Shenoy

私たちは最終的にlast_sync_anchorとnew_sync_anchorの間のギャップを500に制限するループ内でsynchronizeメソッドを実行する独自のカスタムバッチングソリューションを実装することにしましたとか、ぐらい。

これは理想的なものではなく（バイトサイズを制限要因として使用したMSの実装と比較して）、私たちのために機能し、変更の追跡と同期のカスタム実装に固執することができます。

出典

2011-02-21 13:14:12

こんにちはShenoyカスタムバッチ処理を実装する方法について説明できますか？ – Amalka

バッチサイズを使用してインクリメンタルspsへのパラメータを使用して処理しました。最後の同期アンカーと現在の時刻の間にすべての行を返す代わりに、spが返す100行後に100行の上限を設定し、そのテーブルの同期アンカーを最新の行のタイムスタンプに設定します取り出された。次に、次のバッチのためにsyncが再び呼び出されます。このように、ループ全体で同期が行われるのは、ループの最大数だけが選択されているためです。何らかの理由（ネットワークの大部分）の間に同期が停止すると、進行中の最後のバッチだけが失われます。 –

バッチ処理は、SqlSyncProviderによってのみサポートされています。 MemoryDataCacheSizeプロパティを設定することで、DbSyncProviderでバッチ処理をある程度制御することができます。しかし、悪いニュースは多くのオプションを持っていない以前のバージョンを使用している場合です...

出典

2011-02-21 05:44:52

複数のシングルテナントdbから単一のマルチテナントdbへの同期を持つカスタムロジックがあります。 SqlSyncProviderを使用して処理することはできません。既存のロジックを使用する必要があります。 –

Sync Framework 2.1でバッチ処理をカスタム変更トラッキングで使用する方法は？

答えて

関連する問題