| |
>利用状況としては、同一レコードをupdateする確立はかなり低く
>（担当者ごとに処理範囲が異なることが通常なので）、
まあ、「低いから対策なしで良い」ということはないので、
できれば更新モードでレコードセットを取る時は排他で処理されるように
考えた方が安全です。
私のところでは更新内容を全てSQLベースに編集してログファイルに書き出して
いるので、このログファイルを通常のテキストベースで
Lock WriteでOpenさせています。
ここからログファイルをCloseさせるまでの間にテーブルもUpdateさせるので
仮に同一レコードをUpdateさせても交錯しません。
但し、ログファイルのOpenで失敗が起きるので、
エラー処理でランダム値を使って100〜500ミリ秒をWaitさせて再試行しています。
Webシステムのようにレコードロックを行なわない場合は
運用アクションに合わせた時系列処理が重要です。
更新レコードが複数になる場合に、１つの更新セット中に他の更新が混ざるのを
防ぐ方法です。
>また１人につき、２，３分に一度、１作業
>（select数回＋updateまたはinsert１回程度）をするものなので、
>おそらくは大丈夫でしょうか。
実際の更新動作は一瞬なので問題はないと思います。
上のような対応まで行なえば更新で「取り合い」は起こりません。
(同時更新が起きると後側が一瞬待たされることになります。)
さらにADOで進めておけば、いざ「MDBでは無理」となった時、
本格的なネットワークDBへの移行も用意です。
|
|
inoue
- 05/12/15(木) 9:55 -
