同期フレームワークスコープのバージョン管理

Question

現在、Microsoft Sync Framework 2.1を使用して、クラウドソリューションとシッククライアントの間でデータを同期しています。同期はクライアントによって開始され、ダウンロードのみです。両端はSQL Serverを使用していますが、SqlSyncScopeProvisioningクラスを使用してスコープをプロビジョニングしています。クライアントが最新バージョンのソフトウェアを実行することは保証できませんが、クラウドの部分を完全に管理しており、これは常に最新の状態になります。

たとえば、新しい列を持つようにテーブルを変更した場合、元のスコープ（たとえば 'ScopeA_V1'）を保持できるように、スコープのバージョン管理を考慮しています。最初のスコープと同じデータが使用されますが、新しいカラム（たとえば 'ScopeA_V2'）も使用されます。これにより、古いバージョンのクライアントは、アップグレードされるまで同期を継続できます。

これを達成するために、データモデルの変更を特定の方法で設計して、列と表を追加し、削除しないようにし、すべての新しい列をNULL可能にする必要があります。理論的には、私のスコープの古いバージョンは新しいデータを同期していなくても機能し続けることができるはずです。

私はほとんどそこにいると思うが、私はつまずくブロックにぶつかった。既存のスコープの新しいバージョンをプロビジョニングすると、SelectChangesストアドプロシージャのバージョンが正しくコピーされていますが、スコープ固有のストアドプロシージャ（スコープ固有のものではありません。つまりtableA_update、tableA_deleteなど）はすべて更新されませんプロビジョニング担当者はそれらを既存のものとみなし、更新する必要はないと考えます。

関連するストアドプロシージャ（_update、_insertなど）を更新する方法はありますか。デフォルト値（null）を持つ新しい列の新しいパラメータを追加して、スコープの古いバージョンでそれらを使用できますか？

また、クライアントが新しいバージョンにアップグレードされたときに、ローがすでに同期されていても新しいカラムを再同期化しますか（新しいカラムにはnullがあります）。

これは完全に間違った方法ですか？スコープを古い​​バージョンと下位互換性を持たせる別の方法はありますか？

Answer 1

Sync Frameworkは、スキーマの変更に対応するためのスコープ定義の更新をサポートしていません。 SetCreateProceduresForAdditionalScopeDefaultで新しいスコープを作成すると、新しいスコープと新しい_selectchangesストアドプロシージャが作成されますが、他のすべてのストアドプロシージャ、トラッキングテーブル、トリガ、およびUDTが再利用されます。

私はここでスキーマの変更を収容するために変更する必要があるものにブログ投稿のシリーズを書いた：それにhttp://jtabadero.wordpress.com/2011/03/21/modifying-sync-framework-scope-definition-part-1-introduction/

以降のポストをプロビジョニングスクリプトをハックするいくつかの方法を示しています。

他の質問に答えるには、新しい列を追加するとその列または行が再同期化されますが、答えはいいえです。まず、変更トラッキングは行レベルにあります。次に、列を追加しても、同期する変更があるかどうかを示すトラッキングテーブルを更新するトリガは起動しません。