2

更新トリガーにネストされた更新ステートメントがあります。

CREATE TRIGGER "BAD_RECURSIVE_TRIGGER" 
    AFTER UPDATE ON "MYTABLE"
    REFERENCING  NEW AS NEW_ROW
    FOR EACH ROW
WHEN (NEW_ROW.ORDER IS NOT NULL)
BEGIN ATOMIC
    IF <SOMECONDITION> THEN
    UPDATE "MYTABLE" SET ORDER=ORDER+1 // This "update" fires the recursion.
    WHERE <OTHERCONDITION>
END IF;
END;

トリガーの再帰的な実行を防ぎたいのですが、これは DB2 (v9.7) 上にあります。SQL Server および ORACLE データベースについて同様の質問を見てきました。

PostgreSQL で再帰トリガーを防止する

データベース トリガーの再帰を防ぐにはどうすればよいですか?

しかし、DB2 でこれを防ぐ方法が見つかりません。DB2 での再帰的なトリガー呼び出しを防ぐ方法はありますか?

4

2 に答える 2

0

特定の「グループ」内の他のすべてのエントリを（最終的に）並べ替える必要があるため、このようなものに整数型の列を使用することは望ましくありません。

エントリの再配置を許可する場合は、代わりにフローティングタイプを使用してください。これにより、目的のエントリを変更するだけで順序を変更できます。
これらの行に沿ったステートメントで：

UPDATE Example SET ordering = (((SELECT COALESCE(ordering, FLOAT_MAX_VALUE)
                                FROM Example 
                                WHERE id = @entry_above_insertion_point)
                               -
                               (SELECT COALESCE(ordering, FLOAT_MIN_VALUE)
                                FROM Example 
                                WHERE id = @entry_below_insertion_point))
                               / 2)
                              + (SELECT COALESCE(ordering, FLOAT_MIN_VALUE)
                                   FROM Example 
                                   WHERE id = @entry_below_insertion_point)
WHERE id = @entry

これにより、エントリが現在の2つのエントリの中間に配置されます。浮動小数点の動作方法により、値を0から開始する必要があります。データを正規化する必要があるかどうかは疑わしいです。

于 2012-12-15T01:09:01.793 に答える
0

更新前にトリガーを作成しない..。

于 2012-12-13T06:18:52.883 に答える