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

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

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

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

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


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

よろしくお願いします。

No.1 ベストアンサー 回答者： jamshid6 回答日時： 2008/07/22 12:33

誤解があるかな、と思うのは、

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

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

この回答への補足

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

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

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

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

よろしくお願いします。

補足日時：2008/07/22 19:01

No.2 回答者： jamshid6 回答日時： 2008/07/22 20:14

おおむね正しいです。

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

この回答への補足

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

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

補足日時：2008/07/23 17:27