オラクルのレコードカウントの制御(改訂版)

Question

プログラム初心者です。 
オラクル(11g)で、10個のPCで10人が、あるテーブルのデータを更新していく、システムを作成(VB2005)しています。 

画面は2パターンです。
・データ一覧表示画面
・上記からデータを選択し、編集する用の画面

例として下記のようなデータがあります。 

テーブルC 日付順 番号はユニーク 

日付_番号_ステータス__レコードカウント(Rc) 
1/3____1_____Q________0 
1/5____2_____R________1 
1/6____5_____G________2 (Rc=2) 
1/7____7_____P________3 (Rc=3) 
1/20__ 9_____R________4 
2/1___10_____U________5 


動作の流れ

1.まず、この全データをSQLで読込みます。 
SELECT * FROM テーブルC ORDER BY 日付 ASC
これが一覧表示画面(VB2005のグリッドビュー等)に表示されます。

2.A氏が例えば1/6のレコードを編集したいとします。
そこで、1/6(日付)の列をマウスで選択。このとき列番号(レコードカウント)は2になります。
編集画面フォームに、同じSQL(SELECT * FROM テーブルC ORDER BY 日付 ASC)
と、列番号(レコードカウント)2を、引渡しします。

3.編集画面で、引き渡されたSQLを実行し、そのデータを全てDatatblに格納します。
そのデータの3つめ(レコードカウント2)を参照します。
datatabl.Rows(2).Item("ステータス") 
データは参照後、ある条件によりステータスが変わります。
ステータスが、"Z"になった場合、そのレコードは、テーブルAに移動されます。

4.編集後は、他のテーブルに移動する場合でも、テーブルCがそのまま更新される場合でも、
自動的に次の列のレコードに移行し編集を行う。
今回は例として、1/6のレコードのステータスが"Z"になって
A氏は次に1/7(Rc3)のデータを編集作業に入ります。

5. 4.を実行するため、また同じSQLを実行。
SQL実行後、レコードカウントを次に移行すればいいのですが(Rc=2に1を加え、Rc=3とする)、 
Rc=3を見ても、1/20のデータが抽出されて しまいます。 (1/6のレコードが移動してなくなってしまった場合)


また、他の例として、上記と同様に、A氏が1/6のデータを編集中に、他の人が1/3,1/5のデータを編集移動
してしまった場合、レコードカウントがぐちゃぐちゃになってしまいます。

こうした多くの人がデータを編集、更新・移動する場合のテーブルを、日付順に作業させていく場合は、どのような制御 
(またはオラクルの機能)をすれば、可能なのかご指導頂ければ助かります。

jamshid6 · Accepted Answer

とりあえず、なんとかなったようでよかったです。
新しく質問立てて頂いていいかと思います。
（なにぶん、今は仕事ではOracleを使っていませんので、細かいところをすぐ試すわけにはいかないです。もっと早く回答できる人もいるでしょう）
ちなみに、文字列の大小はコードで比較されますが、ASCIIでもUNICODEでも'8'<'A'だと思いますよ。
番号がVARCHAR2で常に10桁(10文字)入っているなら、TO_CHARを使わずにそのまま結合してはだめだったのかな、と思いました。

jamshid6 · Answer

クエリはOracleが手元にない状態で書いたものだったので、ちょっとひやっとしましたが、構文としては正しかったようです。

念のため、11gで確認しましたので、実テーブルに即した内容に書き換えたものを。。

SELECT * FROM T_JOB
WHERE (TO_CHAR(DAY,'yyyyMMdd') || NO) IN
(SELECT MIN(TO_CHAR(DAY,'yyyyMMdd') || NO) FROM T_JOB
WHERE (TO_CHAR(DAY,'yyyyMMdd') || NO)>
(SELECT TO_CHAR(DAY,'yyyyMMdd') || NO FROM T_JOB WHERE NO='<oldNo>'))

日付も一緒にパラメータにできるようなので、以下の方がわかりやすければ。。
1) SELECT * FROM T_JOB
WHERE (TO_CHAR(DAY,'yyyyMMdd') || NO) IN
(SELECT MIN(TO_CHAR(DAY,'yyyyMMdd') || NO) FROM T_JOB
WHERE (TO_CHAR(DAY,'yyyyMMdd') || NO)>'<yyyyMMdd+No>')

2) SELECT * FROM
(SELECT DAY,NO FROM T_JOB
WHERE (TO_CHAR(DAY,'yyyyMMdd') || NO)>'<yyyyMMdd+No>'
ORDER BY DAY,NO)
WHERE ROWNUM=1

ちなみに、クエリの解釈は書かれた内容であっていますよ。

jamshid6 · Answer

そうですか。ユニークなのは番号だけでしたか。
それであれば、本来は番号だけをキーにし、番号順に処理することにして、次の番号を検索しにいくのがシンプルですが、拝見する限りは日付順に処理したそうですね。
であれば、日付＋番号順に処理することとし、次のレコードは
(1)日付が同じで番号が前回編集番号より大きいか、日付が前回編集番号のレコードの日付よりも大きいものを日付・番号順で取り出してROWNUM=1で１件だけ取る
(2)SELECT 番号 FROM テーブルC
WHERE (TO_CHAR([日付],'yyyyMMdd') || [番号]) IN
(select MIN((TO_CHAR([日付],'yyyyMMdd') || [番号])) FROM テーブルC
 WHERE (TO_CHAR([日付],'yyyyMMdd') || [番号])
> (SELECT (TO_CHAR([日付],'yyyyMMdd') || [番号]) FROM テーブルC WHERE [番号]=前回編集した番号))
などの方法になるでしょう。

排他制御の仕組みは１つ入れればいいと思います。DBの質問なのにアプリケーションロックをすすめるのもどうかとは思いましたが、DBロックにする場合は慎重に検討してください。

jamshid6 · Answer

悲観的ですか。。アプローチを２つ紹介しますので、ニーズに合う方を考えてみてください。
1)データベースによるロック
トランザクションモードでSELECT文に FOR UPDATE NOWAIT句をつければ、更新ロックがかけられ、そのレコードは解放(COMMIT/ROLLBACK)されるまでは他の人が更新することはできなくなります。すでに他の人が更新ロックを取得していれば、エラーになります。
・選択したデータに対しては確実に他の人の更新を阻止できます。
・他人の状況は刻々と変わりますので、選択できるかどうかはSELECT FOR UPDATEの結果を見ないとわかりません。
・更新してもしなくても確実に解放するようにします
・誰かがデータを選択したまま放置した場合、そのデータはずーっと誰も更新できない状態になります。
2)アプリケーションによるロック
データに更新者を収録するフィールドを設け、選択した場合はこのフィールドをまず更新しにいく方法です。更新できればデータ編集の権利を得たことになります。
・一覧を読み込んだ時点で今誰が作業中かを表示させられます。
　一覧更新ボタンをつけるなど割り切れば、読み込んだときに作業中のものはDBをつつかなくても「選択不可」とできます。
・次に編集するレコードを取得するのがDBロックよりも簡単です。
・まず一度更新しにいくので、手間がかかります。またうまくやらないと不整合（編集していないのに編集中）が生じるリスクはあります。
・更新してもしなくても、編集終了時には更新者をクリアする必要があります。

jamshid6 · Answer

全部はコメントしきれませんが、毎回読み込むたびに変わる可能性のあるもの（＝Rc)をパラメータとして渡そうとしているところをまず改めてみてはどうでしょうか。
「番号はユニーク」と書いてありますし、日付もユニークならば、番号または日付をパラメータにすべきです。編集を行う行が特定されれば、編集画面ではそのデータだけを読み込めばいいわけです。
更新後の次の行を自動的に割り出したければ、その時点で存在する次の日付のデータの番号を求めて、その番号のものを読み込めばよいです。
SELECT 番号 FROM テーブルC
WHERE 日付 IN 
    (SELECT MIN(日付) FROM テーブルC
     WHERE 日付>[今編集した日付])

なお、今回の情報だけではどこまでロックを掛けたいのか判断できませんでした。一覧に読み込んだものが選択できることを保証するのか、選択したものを更新できることを保証するのか、更新の競合も許すのかで対応は変わってくるはずです。

オラクルのレコードカウントの制御(改訂版)

とりあえず、なんとかなったようでよかったです。

クエリはOracleが手元にない状態で書いたものだったので、ちょっとひやっとしましたが、構文としては正しかったようです。

そうですか。

この回答への補足

悲観的ですか。

全部はコメントしきれませんが、毎回読み込むたびに変わる可能性のあるもの（＝Rc)をパラメータとして渡そうとしているところをまず改めてみてはどうでしょうか。

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング