1
この質問はIs a stored procedure call inside a SQL Server trigger implictly thread safe and atomic?に関連しているので、同じコードを再投稿するかどうかはわかりません。もしそうであれば、ここでの取り引きがあります。同じSQL Serverトリガ/ストアドプロシージャのトランザクションでSelectステートメントの分離レベル？
SQL Servertriggerは、現時点ではINSTEAD OF INSERTです。それはFooと呼ばれるtableにデータを挿入します。その後、トリガーはstored procedureを呼び出します。最後のレコードがfooに挿入selectsストアドプロシージャの一部：
-- New transaction in stored procedure
BEGIN TRANSACTION
...
DECLARE @FooID INT
SELECT
TOP 1 @FooID = ID
FROM
Foo
ORDER BY
ID DESC
...
END TRANSACTION
はのは（のは、簡略化のため2件のINSERT取引のT1とT2を呼びましょう）2つのINSERT文が同時に実行されているとしましょう。それは同時に2つのトリガーコールです。私の場合、トリガーとストアドプロシージャは両方ともatomicです。
しかし、SELECTステートメントのストアドプロシージャではisolationを心配する必要はありますか？最後に挿入されたレコードが正しく選択されることが保証されていますか？または、T1がT2レコードを選択し、その逆の状況に陥る可能性はありますか？
ありがとうございます。
'OUTPUT'節を使うように挿入物を書くのはなぜでしょうか？そしてそのトリガにローカルに' OUTPUT'から生成された最も高い 'ID'を決定し、その値を明示的にストアドプロシージャに渡しますか？ところで、あなたは*複数の行の挿入と更新が事であることを知っています、そしてトリガーはそのようなステートメントのために* once *呼ばれます、正しい？ –
ありがとうございます。私がこのようにしている理由の1つは、ストアドプロシージャがトリガや別のアプリケーションによって呼び出されるという点で汎用性があることです。ですから、私はちょっとwrite-once *アプローチをしたいと思っていました。そして、はい、私はマルチ行とトリガを認識しています。挿入されたデータはフォームからのもので、フォーム提出ごとに1つの挿入行になります。ありがとうございました。 – user3621633
しかし、現在のストアドプロシージャは* brittle *です。 「特定のテーブルの最近の歴史は、私が書かれたものであり、そこから進んでいるものと同じものだと思います」。それは本当に良いインターフェースですか？本質的には、「最新のID値」はすでにそのストアドプロシージャの隠しパラメータです。 –