基本的なルール：
- 物理テーブル定義を変更した場合、これを操作可能な状態にしなければいけません。また、変更された物理テーブルにアクセスするテーブルに対する OAM はすべて再コンパイルの必要があります。(「OAM とは」を参照)
次のような例を考えてみましょう。
- テーブルにはそれぞれ OAM がある。
- テーブル A の OAM には、テーブル A のレコードを更新するファンクションがある。
- テーブル B のOAMにも、テーブル B のレコードを更新するファンクションがある。
- テーブル B の OAM には、テーブル A を読み込んで処理する妥当性規則がある。
ここでテーブル A の物理テーブル定義を変更 (列の追加/削除/属性変更など) した場合、テーブル A およびそれをもとにしたインデックス、OAM を生成し直さなければなりません。
しかしこのとき、テーブル B の OAM を生成し直す必要はあるでしょうか。
テーブル B の妥当性規則は、テーブル A も参照するようになっています。社員テーブル (テーブル B) に新しい社員データを追加したとき、その部門コードは DEPTAB テーブル (テーブル A) に登録されているものでなければなりません。したがって PSLMST テーブル (テーブル B) の OAM は、DEPTAB (テーブル B) テーブルを開き、テーブルを検索して妥当性検査を行う必要があります。これは、部門コードがDEPTABテーブルにあるからです。この検査は、DEPTAB テーブルの OAM を呼び出して行うわけではありません。したがって、PSLMST テーブルの OAM も再コンパイルしなければ、実行時に IBM i レベルのチェック・エラーが発生します(このエラーについては『IBM Database Guidelines』を参照)。
データ間の関係モデルを検討すれば、変更による影響範囲を把握する助けになります。妥当性規則の中に変更したテーブルを参照する記述がないか、という点も確認してください。
バッチ制御を使っている場合もOAMの再コンパイルが必要です。
次のトピックも参照してください。