TRIG_RETCで使用される戻りコードとその設定方法

TRIG_RETCで使用される戻りコードとその設定方法

トリガー・ファンクションが完了すると、必ずその完了状況について以下の3つの検査が行われます。

1.   戻りコードTRIG_RETCが"OK" (大文字)であるかどうか検査されます。"OK"でない場合、トリガーは失敗したものと見なされます。

2.   ファンクションの完了状況が検査されます。OKでない場合、トリガーは失敗したものと見なされます。ファンクションがABORTコマンドを実行するか、直前の画面が表示されることなくENDCHECKに到達するか、または無効な配列やサブストリング参照などを使用した場合などは、ファンクションにより「異常」の完了状況が与えられます。

3.   I5/OSの完了状況が検査されます。OKでない場合、トリガーは失敗したものと見なされます(トリガー・ファンクションが見つからなかった場合など)。

トリガー・ファンクションが失敗したものと見なされると、以下の表に従って、データベース操作を実行している実際の呼び出し元ファンクション(すなわち、SELECT、UPDATE、またはINSERTを実行しているファンクション)に戻りコードが発行されます。

この表に記載されていない値をTRIG_RETCで返さないでください。

また、呼び出し元RDML I/Oコマンドが基となるトリガーの存在を認識している状況で特別な「トラップ」または「処理」を実行するよう設定しないでください。

このような手法を使用すると、設計が非常に複雑になり、トリガー導入の目的全体(すなわち、機能の上層からは「見えなく」すること)が無駄になってしまいます。

I/O操作を実行するRDMLファンクションでは、(他の通常のRDMLファンクションのように) IO_ERRORやVAL_ERRORパラメータを使用しないことをお勧めします。

デフォルト値をそのまま使用し、標準のエラー処理によって問題が解決されるようにしてください。I/O操作の実行には、目的どおりに機能するかどうか関わらず、「バイナリー」手法を使用してください。うまく機能しない場合は、標準のエラー処理によって問題が解決されるようにしてください。

RDMLファンクション内に独自のI/Oエラー・トラップをコーディングすることは、そのトラップが非常に特化された性質のもの(作業ファイルの設定など)である場合を除き、お勧めしません。この推奨事項に従わないと、実装が過度に複雑になり、実質的に業務上の利点がまったく得られない上、開発および保守のコストが大幅に高くなります。

"OK"の応答は、操作が正常に完了したことを示します。

"ER"の応答は、I/O要求を発行したRDMLコマンドにIO_ERRORパラメータを設定します。

"VE"の応答は、I/O要求を発行したRDMLコマンドにVAL_ERRORパラメータを設定します。

"VE"の応答は、INSERT前、UPDATE前、およびDELETE前に対してのみ返されることに注意してください。

これにより、これらの位置のトリガーは、「拡張妥当性検査」のように機能することができます。

ただし、「拡張妥当性検査」として設定されたトリガーが、実際に特定のフィールドに対してエラー状態を示す「フラグ」を設定することはできません。

エラーが発生したことを示したり、エラー・メッセージの詳細を発行したりすることは可能ですが、通常の妥当性規則や通常の妥当性検査ファンクションと同じ方法で、エラーのある特定フィールドにフラグを設定することはできません(ファンクション・オプション*xxx_FIELD_VALIDATEを参照してください)。

ただし、トリガーとして定義された「拡張妥当性検査」には、通常の妥当性検査ファンクションにはない利点が1つあります。それは、挿入、削除、または更新対象になっているファイル・レコードのすべての値にアクセスできることです。一方、通常の妥当性検査ファンクションがアクセスできるのは、それに関連付けられている個々のフィールド値のみです。

「拡張妥当性検査」としてトリガーを使用すると、非常に強力な機能が提供されます。特に、UPDATE前の検査で利用可能な「前/後のイメージ」を考慮するときなど、非常に役立つことがあります。

ただし、以下の点に注意してください。

·         「拡張妥当性検査トリガー」は、非常に複雑な状況でのみ使用してください。この機能を使用する前に、必ず通常のディクショナリ機能を検討してください。

·         「拡張妥当性検査」タイプのトリガーを使用する場合は、1つのファイルに対して1つのみ使用し、すべての規則を内部にカプセル化してください。これにより、「妥当性検査」操作をサポートするトリガーは1つのみになります。

·         トリガー・ファンクションに「独立したモジュール性」を持たせてください。アクション・バー・ファンクションと同様に、以下の「」内に示すような特性を持たせてください。

·         「アクション」を1つのみ実行してください。

·         その前後に他のトリガーや仮想コード・ロジックが続くことを想定しないでください。

·         「スタンドアロン」で動作するようにしてください。

·         小型かつ堅固にしてください。アクションを実行するために呼び出されたトリガーが、1つのアクションの実行のみ、または失敗の理由を示すエラー・メッセージの発行のみを行うようにしてください。

·        Ýトリガー・ファンクション