3

次のような例外をキャッチできる場合: Violation of UNIQUE KEY constraint 'IX_Product'. Cannot insert duplicate key in object 'Product'. (2627).
課題は、インデックス名 IX_Product をメンバーとして解読する方法です (つまり、メッセージを部分文字列にしたくありません)。テーブルには複数の一意の制約が存在する可能性があり、より詳細な情報をユーザーに提供するためにどれを知る必要があります。SQL Server 固有ではないため、DbException としてキャッチすることをお勧めします。文字列を解析せずに例外から影響を受けるインデックスを取得する方法はありますか?

私が思いついた唯一の解決策は、ストアド プロシージャを使用してそこにエラーをトラップし、ストアド プロシージャからより詳細なメッセージを返すことです。しかし、これにはまだ問題があると思います。

4

5 に答える 5

5

次のいずれかを行う必要があります。

  1. 各挿入/更新ステートメントが例外をスローする可能性のある制約名を認識するように、クライアント コンポーネントをコーディングします。
  2. クライアントコードで使用したい方法で「解読可能」になるように、すべての制約の名前を変更するか、または...
  3. 挿入/更新を試行する前にストアド プロシージャ内のすべての制約をチェックし、チェックが失敗した場合は、挿入更新を試行して制約に例外を作成させる前に、プロシージャで独自のカスタム例外をスロー (発生) させます...
于 2008-12-29T16:26:17.827 に答える
2

ええと...おそらく何か明らかなことが欠けています...しかし、例外を解析するのではなく、バグを修正するためにあなたの時間をより有効に活用できないでしょうか?

于 2008-12-29T16:19:18.903 に答える
1

これは設計上の問題のように聞こえます。RDBMSはこれらのことを強制する必要がありますが、アプリケーションもこれらの制約を認識して構築する必要があります。アプリケーションが最初からトラップまたは防止すべき論理例外を RBDMS が処理することを期待するのは、非常に残酷なことです。データベース エンジンはデータ操作用であり、アプリケーションに例外をスローするためのものではありません。

于 2008-12-29T16:39:15.493 に答える
0

例外テキストを解析しません。（ここでアンドリューにエコーします...）

データの挿入/更新アクションで多くの落とし穴が予想される場合は、C# レイヤーでそれらをトラップする必要があります。ApplicationException から拡張して独自の例外を作成し、このような特定の制約を処理します。

ただし、これは、db を使用してステートメントを正常に実行できることを通知しなくても、これらの決定を行うことができるようにデータ モデルが配置されていることを前提としています。データ設計で、db エンジンを介して実行せずに制約に違反しているかどうかを判断できない場合は、データ設計に欠陥があります。

于 2008-12-29T16:55:56.987 に答える
0

例外オブジェクトとして取得したら、解析が最適なオプションです。ただし、実装としてそれを却下するのは簡単ではありません-グループを使用した正規表現は、状況に合わせて完璧にするのはそれほど難しくありません。

また、ストアド プロシージャでも同様の解決策 (解析) になる可能性があります。また、解析コードをデータベース サーバーにプッシュすることで、解析せずに正確な詳細を解決する機能をデータベースに強制することになります (データベース A では簡単かもしれませんが、データベース B と C では非常に困難です)。

于 2008-12-29T16:33:18.313 に答える