パススルークエリでのロックについて

質問

毎度お世話になっております。
SQLSERVER2000とACCESS2003を使用しています。

画面から抽出条件を入力し、画面表示ボタンを押すと
抽出条件をWHERE句にしたパススルークエリが実行され、
在庫、入庫予定、入庫実績、出荷実績を計算、
画面表示するプログラムを作りたいと考えています。

パススルークエリはSELECT文ですが、
サブクエリが多くあり、
FROM句にはたくさんのテーブルが入ります。

また、他端末で実績入力中でも
入力中の実績は反映されなくてもよいので、
実行、画面表示したいのです。

他の質問を検索して、
http://oshiete1.goo.ne.jp/qa3392465.html
SELECT文でもロックが発生することを知りました。
しかし、どのように対処するかは理解できませんでした。
ロックをおこすことなく他端末での実績入力も問題なく行われ、
画面表示もできるようにするにはどうすればよいのでしょうか

よろしくお願いします。

回答No.1

jamshid6 · ベストアンサー

誤解があるかな、と思うのは、
リンク先で話題になっているのは、OracleでFOR UPDATE句を付けてSELECTした場合であるということです。
FOR UPDATE句を付ければ、「更新前提に」SELECTしていることになるので更新ロック（に昇格可能なロック）がかかりますが、つけなければロックはかかりません。
SQL Serverの場合はテーブルヒントを付けないとこのようなSELECTはできないので、今回のパススルークエリに関しては「SELECTがロックしないようにする」というふうに考える必要はないと思います。

ただ、並行して行われている更新処理がレコードをロックした場合、SELECTは待ちがかかりますので、更新処理は極力短時間で行うようにする必要があると思います。
（分離レベルを変更してダーティリードすれば待ちませんが、さすがにお勧めしません）

補足

回答ありがとうございます。
今回もお世話になります。

回答いただいた内容について、また、ロックについて勉強しました。
テーブルヒント、分離レベルのところでかなり混乱していますが、
今の時点の私の理解を以下にまとめました。

パススルークエリをSQLSERVERで実行するときに共有ロックが
かかり、結果をACCESSに返すときにロックが外れる
（結果が画面に表示されるときにはもうロックが外れている）。
共有ロックは排他ロックをブロックするので、
SELECT文が実行されているとき、他端末での実績入力はWAITになる
（が、実行されている時間だけなのでとても短い時間になる）。
他端末が更新している場合はその排他ロックが外れるまでSELECT文はWAITになる（更新が完了するまでなのでわりと待たされる場合もある）。
どちらにしてもWAITになるだけなので、
SELECT文ではロックは起こらない。

このような理解にいたりましたが、正しいでしょうか。

よろしくお願いします。

回答No.2

jamshid6

おおむね正しいです。
（超厳密な議論までは必要ないでしょう）
補足するとしたら、
・トランザクション分離レベルについては、通常は下から２番目のREAD COMMITTEDになっていて、COMMITしていない更新はSELECTでは読み取らないけれども、COMMITされれば即反映するので、今SELECTしたものが次SELECTしたものと同じという保証はないこと
・OracleとSQL Serverとではロックのメカニズムは同じではないこと
くらい認識していればいいかと思います。

補足

回答ありがとうございます。
頭の中がすっきりしました。

補足いただいた内容についても勉強していきたいと思います。