データベースをデバッグしていますが、delete ステートメントでレプリケーションが失敗していることに気づきました。
ソース テーブルと宛先テーブルを確認すると、それらは同じです。そのため、誰かがソースから行を削除してから、元に戻しました。 (カスケード削除したくない手動データへの FK 参照のため、削除は失敗します。)
削除しようとしている行の PK を見つける方法はありますか?
(すべてのレプリケーション モニターは、delete ステートメントが失敗する原因となっている FK の名前を教えてくれます。)
いくつかの方法があります。簡単なことをお話しします（怠け者なので）。失敗したストアド プロシージャの実行について、サブスクライバーにトレースを配置します。sp_MSdel_table (ここで、table はテーブルの名前) のような名前のヒットを取得する必要があります。そのプロシージャへの引数は、削除しようとしているレコードの主キーになります。
2 番目の簡単な方法は、前の方法で識別された sproc を変更して、欠落している行に腹を立てないようにすることです (結局、行が削除されるだけなので、欠落しているという事実はそれほど大きな問題ではありません) 。他の非収束の問題があるかもしれませんが、少なくともコマンドが再び流れるようにすることができます。（編集：問題の理由に気づきました。参照整合性はパブリッシャーで処理する必要があるため、サブスクライバーで FK 制約を設定しないことをお勧めします。SQL がチェックする必要がない場合は、レプリケーションを高速化します。該当する挿入、更新、または削除を行うたびに)。
一番難しい方法は、レプリケーション モニターでエラーを確認し、トランザクション ID とシーケンス番号が指定されていることに注意することです。次に、ディストリビューション データベースで sproc を使用して、実行中のコマンドのテキストを取得します。
困難な 2 番目の方法は、tablediff.exe、RedGate の SQLCompare のようなもの、またはリンク サーバーを介した独自の結合を使用してテーブルを比較し、違いを示すことでした。上記の一度に 1 行ずつ作成する他の方法ではうまくいかない場合に備えて、これをバック ポケットに入れておきます。そのようなことに対する私のしきい値は約3です。YMMV。