処理フロー： オンラインタスクでレコード後処理を通る条件
オンラインタスクでレコード後処理を通るケースについて考えてみました。
思い浮かぶ条件としては、こんな感じでしょうか。
・ユーザが何か入力した。
実データ、変数に関わらず、どの項目でもよいので「入力した」というのが条件になります。
また、値を変更しなくても「入力した」というのが重要です。
もともと「あ」と入っている項目に「あ」（同じ値）を入力しても、条件は満たされます。
また、ラジオボタンやコンボボックス、チェックボックスなどにマウスで入力したときも同じです。
いずれの場合も、レコード後処理を通ります。
・子タスクやサブプログラムで更新された。
直接入力をしなかったとしても、間接的な更新でレコード後処理を通るケースもあります。
子タスクから親タスクの項目が更新された場合、親タスクではレコード後処理を通ります。
（伝票入力のヘッダと明細の関係が代表的な例です。）
サブプログラムをコールして、そのパラメータが更新されるとレコード後処理を通ります。
（顧客や商品の選択プログラムなどが代表的な例です。）
・「止：No」の項目更新コマンドが実行された。
項目更新コマンドの中止パラメータと呼ばれるものです。
これが「No」ということは、この項目更新は中止できないということです。
従って、この項目更新コマンドが実行されると、必ずレコード後処理を通ることになります。
また、取消アクションも効かなくなります。
関連として「Q&A」の取消アクション（F2）が効かないことがあるも参照してください。
・強制レコード後処理。
タスク制御の「強制レコード後処理」を「Yes」にしたときです。
文字通りです。
個人的にはあまり好みではありません。
・「選択テーブル：Yes」で選択アクション。
タスク特性で「選択テーブル」を「Yes」にしたタスクで、
選択アクションが発生したときは、レコード後処理を通って、
その後、タスク後処理を通り、タスク終了します。
一覧表示して、データを選択するプログラムでよく使う方法です。
選択アクションは、デフォルトのキーボード割付では「Enter」です。
では、通りそうで通らないケースの代表例をひとつ。
・「止：Yes」の項目更新コマンドだけ。
レコード前処理やレコードメインで「止：Yes」の項目更新コマンドが実行されたとします。
そのときは、値が変更されたように見えますが、それだけではレコード後処理を通る条件にはなりません。
そのため、更新項目が実データの場合は、データベース内の値は更新されません。
勿論、入力など、他にレコード後処理を通る条件が重なれば、データベースへの書き込みは行われます。
あくまでも、これだけでは条件が成立していない、ということです。
以上のことから、レコード後処理を通る条件として、
「値が変更されたら」という覚え方は、あまり良くないと言えるでしょう。
値が変更されなくても入力すれば通るし、
項目更新コマンドで見かけ上の値が変更されても通らない場合もあるので。