wcf - セルフ トラッキング エンティティのデバッグ - オブジェクトのキー値が ObjectStateManager の別のオブジェクトと競合するため、AcceptChanges 例外が発生する

Question

セルフ トラッキング エンティティへの変更を保存するときに例外が発生します。

AcceptChanges cannot continue because the object's key values conflict with another object in the ObjectStateManager. Make sure that the key values are unique before calling AcceptChanges.

この問題は、次のような他の質問で対処されていると思います:自己追跡エンティティ - オブジェクトのキー値が ObjectStateManager の別のオブジェクトと競合するため、AcceptChanges を続行できません

私の質問は、開発と本番の両方でこの問題をデバッグする最良の方法は何ですか. 例外を引き起こしているエンティティまたはエンティティ タイプの詳細をキャッチ/アクセスできる追加情報はありますか。

そうでない場合、別のオブジェクトを参照する重複キーを探してオブジェクト グラフをトラバースするために何かを書く必要がありますか? もしそうなら、誰もこれを経験していますか？

詳細情報:

私のシナリオは次のとおりです。クライアントは、他のエンティティへのさまざまな FK を持つすべてのエンティティのコレクションを含む WCF サービスを介してエンティティを取得します。これらの FK リレーションシップはすべて linq クエリに含まれているため、完全なオブジェクト グラフが得られます。

クライアントのビューは、パフォーマンスのためにルックアップ テーブルなどの静的データ用に以前にフェッチされたエンティティを使用します。User への FK を持つ Customer オブジェクトがある場合、これはサービスから取得されたときにロードされます。Order などの別のエンティティをオブジェクト グラフに追加し、Customer オブジェクトと同じ Id を持つこのオブジェクトに User プロパティを設定しますが、エンティティは別の時点で取得されたため、別の ObjectContext を使用します (つまり、オブジェクトは同じ ID ですが、オブジェクトの同じインスタンスではありません) このエラーが発生します。

他の質問へのリンクは、これを回避する方法を示していますが、エラーを追跡できるように、問題を引き起こしているエンティティに関する詳細情報を探しています。

Answer 1

私はこの問題に頭を悩ませていました。最終的に、問題の原因は、ReSharper ヒントをリッスンしてコンテキスト プロバイダーを静的にしたことが原因であることがわかりました。それは他のさまざまな変更で発生したため、それが原因であると確認することは考えていませんでした。しかし、私の場合、それが問題でした。

Answer 2

これは通常、以前にエンティティをロードするために使用されたコンテキストを使用しようとした場合に発生AcceptChangesします - 変更を受け入れるために新しい空のコンテキストを使用します。AcceptChangesSTE からのエンティティが既にコンテキストにロードされている場合は使用できません。これは、現在の STE 実装の制限です (ただし、テンプレートを書き直せばおそらく削除できます)。

私が知っているように、この種の問題には詳細な例外はありません。STE をデバッグするには、生成されたコードを確認します。STE コード全体が利用可能であるため、変更トラッカーを参照してエンティティを検索できますが、簡単ではありません。

クライアントで重複を定義することさえ可能かどうかは実際にはわかりませんが、そうであるとしましょう。クライアント コードを制御できる場合、最善の方法はクライアント コードを診断することです。ログを追加して、重複の理由を見つけます。次に、サービスの問題を修正するよりもクライアントの問題を修正する方が簡単であるため、重複を削除します。クライアントを制御できない場合は、クライアントに渡されたデータが正しくないことが問題であり、クライアントの開発者に修正を依頼してください。