エラーメッセージの解析以外に、.NETのSQLからユニークなキーの例外をチェックするより洗練された方法があるのだろうか？今、私はSQLでsprocを呼び出し、.NETでtry catchブロックを使用しています。 try catchブロックでは、エラーメッセージを解析し、固有のキーエラーです。呼び出し元クラスにカスタムエラーのインスタンスをスローします。呼び出し元クラスに元の例外をスローします。これは私にとって非常に非効率的です。.NETでSQLのユニークキーの例外をキャッチ
SqlExceptionが検出された場合、「SqlError」オブジェクトの数を保持する「Errors」コレクションを列挙できるはずです。
SqlErrorには、「クラス」や「番号」などのプロパティがあります。一意なキー違反はclass = 14とnumber = 2601です。エラーを正確に見つけるためにそれらの番号を確認してください。
ものはあなたがSQL Management Studioでクエリを実行しようとすると、あなたが得る同じエラーコードです：
メッセージ2601、レベル14、状態1、行1
は に重複するキー行を挿入できませんオブジェクト..........
ステートメントが終了しました。
"Msg"はSqlErrorの "Number"プロパティに変換され、 "Level"は "Class"に変換されます。
このようにして、「一意制約違反」エラーを簡単かつ正確に特定できます。
マーク
明白な答え：挿入（または更新）する前にデータベースからその値をフェッチし、挿入を行う前にユーザーに通知してください。
代替回答：SP内の一意性をチェックし、SPからのエラーメッセージとして返すので、エラーを解析する必要はありません。彼らはすべて悪いです。
一意のIDが存在するかどうかを質問してみませんか？ それは例外を得るより良いです。
+1最初は例外を避けるためです。格納されているprocは存在をチェックし、キーがすでに存在する場合はよく知られた結果を返す必要があります。この場合、例外をスローせずに処理できます。これははるかに効率的です。 –
ストアドプロシージャをシリアライズ可能にしない限り、1秒あたりのトランザクション数が増加するため、並行性の問題に陥ることはありませんか？つまり、行が存在しないことを確認してから挿入するまでの間に、別のユーザーがすでに行を挿入しています。最初にチェックを行うオーバーヘッドは言及していません。 IMHO .NETのエラーを挿入して処理する方がはるかに優れています。 –
構文解析エラーメッセージは悪い考えです。たとえば、Ms SQLメッセージを使用している場合、（別の言語で）ローカライズすることができ、あなたが探している単語を見つけることができません。
Ms SQLを使用している場合は、Numberプロパティをチェックする必要があります。
これについて私を悩ますものは、SQL Serverは、エラーコードに関しては、両方とも2627を返すため、主キー違反と一意的な制約違反を区別しないという点です。ユニークなインデックス違反は2601を返しますが、 PKsまたはUCを使用します。UC違反からのPK違反をローカライゼーションに安全な方法で伝える方法に関する考えはありますか？ –
「番号」（クラスなし）のチェックで十分だと思います。 「クラス」は重大度のみを示すようです。 – slartidan