0

Microsoft Sync Framework 2.1に問題があり、障害が発生しています。簡単にするために、次の構造を持つ2つのテーブルConfigSetとConfigItemを同期しているとします。

|ConfigSet        |
|-----------------|
|ConfigSetID (PK) |
|ConfigItemID (FK)|


|ConfigItem       |
|-----------------|
|ConfigItemID (PK)|
|ConfigItem.Data  |

ConfigSetIDによって駆動される両方のフィルタリング句を使用しています：

ProvisionerObject.Tables["ConfigSet"].FilterParameters.Add(new SqlParameter("@ConfigSetID", SqlDbType.UniqueIdentifier));
ProvisionerObject.Tables["ConfigSet"].FilterClause = "[side].[ConfigSetID] = @ConfigSetID"

ProvisionerObject.Tables["ConfigItem"].FilterParameters.Add(new SqlParameter("@ConfigSetID", SqlDbType.UniqueIdentifier));
ProvisionerObject.Tables["ConfigItem"].FilterClause = "[side].[ConfigItemID] in (SELECT ConfigSet.ConfigItemID FROM ConfigSet WHERE ConfigSet.ConfigSetID = @ConfigSetID)"

次に、サーバー側で2つのConfigItemレコード「Item1」と「Item2」を作成し、「Item1」への外部キーを持つ1つのConfigSetレコード「Set1」を作成してから同期を実行すると、正常に機能します。クライアントは、ConfigItemから「Set1」レコードと「Item1」のみを取得します。

次に、サーバーの「Set1」を更新して「Item2」を指すようにすると、同期フレームワークはConfigSetの変更を検出しますが、レコード「Item2」はそうではないという外部キー制約をクライアントにスローします。存在。

ConfigItemを同期すると、技術的にはConfigItemに変更がないため、変更が検出されないように見えますが、これが初めて同期された場合、filter句はItem2を返します。

各テーブルが個別に同期されていることは理解していますが、そのテーブルに変更がない場合でも、「Item2」レコードを強制的に取得する方法はありますか？そしてさらに良いのは（フレームワークができることでこれに運を押し付けていると思いますが！）、これは技術的にクライアントによって同期/参照されなくなったため、クライアントの「Item1」を削除できればです。

4

1 に答える 1

0

残念ながら、同期フレームワークは、パーティションの再調整や範囲内外の行をサポートしていません。

シナリオで最も簡単な回避策は、item2 にダミーの更新を実行して、変更済みとしてマークすることです。ただし、これは、この変更がアイテム 2 を持つ他のクライアントにも送信されることを意味し、実際には何も変更されていないため、トランザクションが無駄になります。

範囲外になったクライアントの行については、それらをクライアントから削除し、ChangesSelected イベントで変更を傍受し、変更データセットから行を削除して、サーバーに伝播しないようにすることができます。または、単にクライアント テーブルをクリーンアップし、新しいフィルター値に基づいて再初期化することもできます。

于 2012-06-27T10:48:13.590 に答える