0

DB2 for IBM System iでは、以下でMYLOGTABLE行われるすべての挿入操作で記録するために、このトリガーを作成しますMYCHECKEDTABLE。

SET SCHEMA MYSCHEMA;

CREATE TRIGGER MYTRIGGER AFTER INSERT ON MYCHECKEDTABLE
REFERENCING NEW AS ROWREF
FOR EACH ROW BEGIN ATOMIC
     INSERT INTO MYLOGTABLE -- after creation becomes MYSCHEMA.MYLOGTABLE
         (MMACOD, OPTYPE, OPDATE)
     VALUES (ROWREF.ID, 'I', CURRENT TIMESTAMP);
END;

DBMSは、トリガー本体をMYSCHEMA.MYLOGTABLEハードコードされた状態で格納します。

ここで、スキーマ全体を新しいスキーマとしてコピーするとしますNEWSCHEMA。NEWSCHEMA.MYCHECKEDTABLEログにレコードを挿入すると、レコードはのMYSCHEMA.MYLOGTABLE代わりに追加されNEWSCHEMA.MYLOGTABLEます。つまり、トリガーとそのテーブルが存在するスキーマに追加されます。これが大きな問題の原因です!! また、多くのユーザーが私の制御なしでスキーマをコピーできるため...

では、トリガー本体で、トリガーが存在するスキーマを指定する方法はありますか？このようにして、ログレコードを正しいに書き込みますMYLOGTABLE。のようなものPARENT SCHEMA...または回避策はありますか？どうもありがとう！

4

2 に答える 2

1

HLL で定義された外部トリガーは、トリガーを起動したテーブルのライブラリ名を含むトリガー バッファーにアクセスできます。これは、への参照を修飾するために使用できますMYLOGTABLE。

詳しくは、IBM Redbook Stored Procedures, Triggers, and User-Defined Functions on DB2 Universal Database for iSeriesの11.2 章「Trigger program structure」を参照してください。

CURRENT SCHEMAあるいは、特殊レジスターまたはGET DESCRIPTORステートメントを使用して、トリガーおよび/またはテーブルが現在どこにあるかを見つけることができる場合があります。

于 2011-12-07T09:34:58.513 に答える
0

残念ながら、トリガーが存在するスキーマは、トリガーの本体内から検出できないことに気付きました。

しかし、いくつかの回避策があります ( @krmilliganにも感謝します):

  • ユーザーの実行権限を奪い、CPYLIBユーティリティを使用させます。
  • 同期していないトリガーを探して定期的に実行するバックグラウンド エージェントをシステム上に作成します。
  • コマンドのオプションCPYLIBのデフォルトを に設定しTRG*NOます。この方法では、ユーザーが明示的に指定しない限り、トリガーは決してコピーされません。

トリガーのコピーが必要なコンテキストがある場合でも、最後のものを選択します。これは最も単純なものだからです。そのような場合、私は最初の回避策を取ります。

于 2011-12-20T16:38:40.220 に答える