ＤＭ検索した後のデータはバインダーに保存しておきます。
実際にラベル印刷するまでの期間は１月程あきます。

その間、元データの更新は日常的に行っています。
ですから、実際に印刷作業に入る直前に保存しておいたバインダーに
最新データに更新しておかないと、クレームの元となります。

もう一度、最初から検索し直せばいいじゃないか？と思われるかも
しれませんが、検索結果のデータ件数が多いと手作業でデータ削除し
たり、プログラムで件数を絞りこんだりと複雑な工程があり、できない
のです。

ところが、このDM検索と最新情報更新の間に、さらにまた別の作業
工程が入ったことを忘れていました。

いろいろとプログラムでフラグをたてたりする作業のため、ダミー列
というのを作り、ここに情報を保管しているのですが、上記の作業で
必要な情報が消去されている可能性があることを指摘されました。

作業工程がどんどん変化していく（いかざるを得ない）のに、対応
していくということは、非常に大切なことですね。

今回、プログラムを見直して、３本のプログラムを修正しました。
動作確認してから、サーバーのプログラムを更新しようと思っていた
ところ、担当者からすぐに更新したいと言われました。
修正プログラムを持参していなかったので、あら困ったと思ったので
すが、どうしようと思ったら、３本も修正する必要がなく、
元の最新情報更新のプログラムにMPU/Tで定義表の作業を１行追加
するだけで、ＯＫだということ気が付きました。

追い込まれると「ひらめき」がでるものです。
久しぶりの「ひらめき」でした。

元山より

> 最新データに更新しておかないと、クレームの元となります。
>

ＤＭ検索作業のなかで、当社のＤＭは１通にして、とか、私以外
は不要とか、品質保証部宛で名前はいらないとかさまざまな要求が
あります。

「連絡したのに直っていないじゃないか！！」とかおしかりに
つながる事例なので、こういう処理はもっぱら「ＭＰＵの定義表」
で処理しています。

先日、ACCESSの担当者が、
「緊急に登録したいがどうしたらよいか？」と電話連絡がはいった
ので、ＭＴで入力してＰするようにと指示しました。

定義表のなかで条件式が似ているのを参考例にして、登録して
作業したら「所属」が「代表取締役」がそのままで、名前の列
が「担当者」になっている。「社長」なのにこれでは困ると
いう連絡が再度きました。


ACCESSの担当者は自分で知恵を絞ったようで、条件式に所属を
空白にするという条件を追加して対処していました。

単純に所属を空白にできないケースもあるのです。
大企業なので、これをしたらごみ箱いきです。
事例の会社は小さいところなので、所属を空白にという処理
で対応できると判断したようです。

条件式も細かく、ここらへんもACCESSだと、どういう処理に
なるのかという興味があるところです。

元山より