リビジョン管理による排他制御

　DBの排他制御を行ったとしても、Aさん,Bさん2人が同一レコードに同時にデータ修正すると、結果は後勝ちで先に行った修正は上書きされて無視されてしまいます。この不具合を解消するため、Ver7以降よりテーブルにProRevisionという長整数型のフィールドを設けて後勝ちを排除できるようにしました。
ProRevisionは、XCuteがReadReport時のデータ更新時にExcelの読み取り値とデータベースの値を比較し、等しいならレコードを更新するとともにProRevisionの値に１を加算します。２つの値が等しくないなら、下記のエラーを表示しデータベースへの書き出しを中止します。

ブラウザで実行している時には、HTML版が表示されます。


以下に、ＡさんとＢさんが同時に同一画面を開き、Ａさんがデータ更新した後に、Ｂさんが更新した場合の処理内容を図解します。

　なお、ProRevisionの画面の最初の値は空白とすると、内部で１となります。以降、内部的に+1をして正数の範囲を超えると1に戻されます。削除セルにDelを指定し削除処理をするとProRevisionは0にされ、もう一度Delが指定されるとレコードはデータベースから削除されます。
上記のような訳で、管理者以外に見せるレコードはProRevision>0で絞り込みを行ってください。

XCuteで実装する時の具体的な注意点は以下となります。

参照
　○DBの排他制御

ProRevisionとTransactionによる排他制御の違いと使い分け

　ProRevisionは、WEBのための排他制御で、先に書き込んだデータが失われ、後からのデータが残るのは、運用上好ましくないという考えです。Transactionによる排他制御は、テーブルやレコードを同時に2人が修正するとまずい結果になることを避ける制御です。

ProRevisionをうまく利用すればTransactionは使わなくて済む方法の紹介

　XCuteの処理は、必ずシーケンシャルに行われます。ProWeb.exeを使ったとしても、ProWeb.exeに２つの同じプロジェクト名を登録しない限り、処理が並行で進むことはありません。DBを参照系のプロジェクトは複数動作させても、DB更新系のプロジェクトは１つに限ることで、Transaction処理を使わなくてすみます。

参照
　○運用サーバについて