uniPaaS V1 Plius、メモリWF、タスク後処理で１件進む
バッチタスクのメインソースにメモリＷＦを指定。
９件レコードがあり、
データビューで、明細行 １行目～８行目で範囲指定しているのに
そのタスクのタスク後処理で、明細行の値が１行次のレコードの値である
９行目を表してました。
ロジックミスではないと思います。
uniPaaS V1 Plus 1.9g2 PT6 開発版です。
もしかするとそのような不具合がuniPaaS V1 Plus にあったのかと思い
PT7のヘルプを見てみましたが見当たりませんでした。
もうサポートも終わってますし、プログラム改修で対処しました。
そもそもタスク後処理で、自分のタスクのメインソースの値を見ては
いけないんでしたかね？
-
nkmtさん、
> そもそもタスク後処理で、自分のタスクのメインソースの値を見ては
> いけないんでしたかね？見てはいけないわけではないのですが、「見るべきではない」といったところなのでしょうかね。
タスク後処理ではポインタが次のレコードに行っている可能性がありますね。
-
tandaさん ありがとうございます。
> 見てはいけないわけではないのですが、「見るべきではない」といったところなのでしょうかね。
そうなんですね。まだまだMagicをわかりきっていない自分です。
そのタスクのメインソースは改造前はSQL Serverで問題ないロジックだったのですが
今回、そのタスクのメインソースをメモリWFへ変更しました。
バグ修正に２時間かかってしまいました。
でも直って良かったです。SQL Serverの場合は、WHEREでしっかり範囲指定をして余計なレコードを取得しない。
メモリWFやActianの場合は、次レコードまでGETしている。
といった推測をしますが、
とにかくタスク後で、自タスクのメインソースの値を取得するのは
No Goodと理解して今後気を付けたいと思います。
とまあ恥ずかしい投稿かもしれないですね。 -
nkmtさん、
絶対に見てはいけないということでしたら、F8の構文チェックで引っかかるはずですね。
-
なるほどですね。
タスク後でメインソースの値を見るのは要注意と心得たいと思います。
そういえばMagic Optimizerでは、
・タスク前でカラム項目を使用しています の警告があったと思いますが
・タスク後でカラム項目を使用しています の警告は無かったかもです。 -
nkmtさん、
タスク前ではレコードをロードしてないですから見えないのは当然ですが、タスク後ではトランザクションキャッシュをわざわざクリアすることもないからなのだと思います。
-
トランザクションの終了は必ず「タスク後の後」で行われますからね。
サインインしてコメントを残してください。
コメント
6件のコメント