2

SyncOrchestratorを使用するか、特にhttp://code.msdn.microsoft.com/windowsdesktop/Database-SyncSQL-Server-e97d1208を使用して、SQLServer2008を最大6つのSQLServer2008 Expressクライアント(私が信じるすべてのR2)と同期しています。わずかな変更を加えたベース。私の知る限り、これはすべての接続がピアまたはノードであることを意味します。

私は2つのスコープを持っています。1つはダウンロードのみで、もう1つはアップロードのみです。ダウンロード専用スコープにはID列が含まれています。これは主に、私がよくわからなかったため、クライアント側でPKとしてGuidsを導入することに頭を悩ませることができなかったためです。すべてのクライアントが約8程度のテーブルの正確なレプリカを持っている必要があり、これらのマシンはこのデータにまったく触れず、読み取るだけなので、まったく問題ではありません。

アップロード専用スコープはGuidを使用します。幸い、データベースのその部分を制御でき、同じIDシードを使用する10個のクライアントがサーバーに正しく同期できる方法はありません。どちらのスコープも、バルクインサートと9ヤード全体のデフォルトのプロビジョニングを使用しているため、これを台無しにするためにプロビジョニング側で何もしていないはずです。

私は最初にPerformPostRestoreFixupを使用せずにすべてをセットアップし、初期データベースはホストからの挿入ステートメントと手動で同期されました。これは問題ないように見えましたが、更新や削除は適用されていないようです。次に、VS2010データベースプロジェクトを使用してデータベースをスキーマのみに再構築し、同期したため、これは無視しても問題ありません(履歴の正確性と私の無能さを証明するためにのみ使用されます)。次に、ここで概説した手順(http://social.microsoft.com/Forums/br/syncdevdiscussions/thread/9ac6d1a1-1565-4b82-a8d8-3d4a9ff5d07b)を使用しました(同期、バックアップ、復元、performpostrestorefixupの呼び出し、xクライアントでの同期) )そして、これをすべて設定している開発ボックスで、更新と削除がうまく表示されました。これをxクライアントにデプロイすると、データベースのミラーが表示されないはずです。

最初の同期は文句を言い、すべてのレコードの同期を再試行します。これは予想されることだと思います。クライアントでのApplyChangeFailedイベント中に、DbConflictType.ErrorsOccurred以外のすべてをApplyAction.RetryWithForceWriteに設定しました。これは、変更をクライアントに強制するために行う必要があると当初考えていたため、問題の原因となる可能性があります。このシナリオではサーバーが常に勝ちたいのですが、トレース中は、一括挿入/更新呼び出し中に常に「ローカル勝ち」というフレーズが表示されます。再適用が行われる前にエラーが表示される可能性がありますが、確認するのは面倒です。

私が抱えていると思われる唯一の問題は、ダウンロード専用スコープにあります。最初のクライアントデータベースは現在約1週間前のものであり、performpostrestorefixupの手順を使用すると、今からそれまでに適用された更新が表示されません。SyncFxが最初の同期を開始するためにクライアント側の空白のデータベースをほぼ好むかのように、ApplyChangesFailedイベントが開始されることなく、すべての更新が正常に適用されるように見えます。

誰かがこれを以前に見たことがあるか、どこに行くべきか手がかりを持っているなら、私はそれを大いに感謝します。私の脳は、それが何が起こっているのかを判断しようと揚げてきました。私の最後の努力は、すべてのクライアントに空のデータベースを展開し、それらに同期を開始させることです。開発者側ではこれに問題はありませんが、他の1つのクライアントをテストして、それが何か違うことをするかどうかを確認することしかできません。それを除けば、この目的を完全に無効にする手動同期を実行し続ける以外に何をすべきかわかりません。PerformPostRestoreFixupで問題が完全に軽減されると思いましたが、それがあってもなくても同じ問題が発生しているようです。あるいは、必要なものを見ていません。

ありがとう

4

1 に答える 1

1

調査結果を報告してエントリを閉じたいと思いました。

以前に構成したクライアントデータベースを展開すると、次のログの形式でApplyChangeFailedイベントが発生することがよくあります。

"[05:30:41 PM]-ApplyChange Failed:TableName:、Stage:ApplyingInserts、ConflictType:LocalInsertRemoteInsert、Action:RetryWithForceWrite"

これは、すでに存在するデータを再挿入しようとしたときに予想されることです。これを変更する必要があったのは、RetryWithForceWrite中の更新ステートメントでしたが、送信された内容でデータが更新されていないことがわかりました。

完全に空白のデータベースで各クライアントを起動し、ローカルでプロビジョニングすると、これらのエラーはすべて解消されました。それは、すべてのクライアントが、それだけが設定する一意のIDを期待しているようです。また、x64ビルドとx86ビルドを使用していますが、結果に多少の影響があるか、まったく関係がない可能性があります。正確に何が起こったのかを判断できればいいのですが、疑わしい場合は、絶対零度から始めて同期でデータを入力するのが最も安全なオプションのようです。

于 2012-04-26T20:09:34.090 に答える