ファイルメーカーは複数のパソコンから1つのファイルを共有して使うことが簡単に出来てしまう、とってもすばらしいソフトのひとつだと思います。しかしその機能を過信してのん気に設計が出来ないのもファイルメーカーなのです。 原因不明な(つーか、思いつかなかった)理由でデータ値がずれていて、緊急でメンテナンスに迫られた事ありませんでしたか? 今回は、在庫の管理や金額の締め関係など、スクリプトによる一括更新処理をしてみよう、または現在している、と言う方にぜひ考慮していただきたいお題です。 基本的にはバッチ処理は、バッチ処理用マシン以外でデータベースに接続しているユーザがいないときにやっちゃいましょう、という前提で走らせるわけですが、もし万が一アクセスしているユーザがいた場合はいったい、どうなるのでしょうか?
クライアントはたまたま仕事が立て込んでおり、深夜在庫更新のバッチが走る時間まで出庫数をちんたら編集してやがります。今回例のバッチ内容は、在庫数から出庫数を引いた数値を、バッチ後在庫数に転記するものです。 この状態の時バッチが走るといったい・・・!? まあ、スクリプトステップにエラー処理ON入れてるから大丈夫!なんて思い込んでいる人、超ヤバいっす!! まずは素人さんの例 (左はバッチ実行ファイル、右はそれにキックされる在庫.fp5側のスクリプト)
これはまったく排他処理というものを考えた事がなかった、しろーとプログラマーがごく自然にやってしまう失態です。 こちらは職人さんの例。エラーが起きた時のレコードの場所やタイムスタンプをエラーログとして残しています。
では職人用バッチを走らせてみましょう。その結果は・・・ あ、結果は同じです。使用中のレコードは処理されないだけです。しかし、エラーがあった事に気付くと気がつかないとでは雲泥の差でしょう。
で、下ですよ。職人のバッチはメンテナンスもきちんと考えて実行時にスクリプトを一時停止にし、キャンセルされなければ3秒後に実行される。キャンセルされればエラーログをじっくり見れるモードになるという事です!
いかがですか?この事例では処理出来なかったレコードIDを拾っているので、長期間ほったらかしにすることは出来ませんが、その後の対策(時間差2度目のバッチ・最悪何時に作業していた人がわかる)など、よりデータの信頼性を高める事が可能になるわけです。 MENU |