0

tblapplication と tblapplicationhistory の 2 つのテーブルがあります。tblapplicationhistory は、アプリケーション テーブル内のアプリケーションのステータスに対して行われたすべての変更のアーカイブです。アプリケーション テーブル内の学生は、多くのアプリケーションを持つことができます。

申請ステータスが「内定承諾」になると、ステータスIDが7に設定され、申請テーブルと申請履歴テーブルの両方に反映されます。この時点で、特定の学生の他のすべての申請ステータスは、8、「オファー拒否」に設定されている必要があります。

create or replace
TRIGGER trg_declineapplications AFTER UPDATE ON tblapplicationhistory FOR EACH ROW

BEGIN
   IF :NEW.statusid_fk_nn = 7 THEN
      UPDATE tblapplication
      SET statusid_fk_nn = 8
      WHERE studentrecordnumber_fk_nn = ( SELECT studentrecordnumber_fk_nn
                                          FROM tblapplication
                                          WHERE applicationid_pk_nn = :NEW.applicationid_fk_nn
                                        )
      AND applicationid_pk_nn != :NEW.applicationid_fk_nn;
   END IF;
END;

トリガーはエラーなしでコンパイルされ、トリガーは SQL エラーを返さずにアクティブ化されますが、アプリケーション テーブル内のどの行に対しても計算を実行しません。その場合、トリガーのロジックにエラーがあるはずですが、それはわかりません。

私の考えでは、tblapplicationhistory の更新された行に statusID 7 が含まれている場合、application テーブルで更新が実行され、承認されたアプリケーション以外の同じ学生に属するすべてのアプリケーションの statusID が 8 に設定されます。

必要に応じて、より多くの情報を提供できます。

テーブル定義:

tblapplication:
applicationid_pk_nn
studentrecordnumber_fk_nn
jobid_fk_nn
statusid_fk_nn

tblapplicationhistory:
applicationid_fk_nn
statusid_fk_nn
datechanged_nn
applicationhistoryid_pk_nn

tblapplication では、主キーは applicationid_pk_nn で、他のすべてのフィールドは外部キーです。

tblapplicationhistory では、applicationhistoryid_pk_nn が主キーです。statusid_fk_nn は、applicationid_fk_nn を持つ tblapplication から取得されます。

4

1 に答える 1

1

トリガー メソッドはあまり堅牢ではないようです。

レコードを更新してアプリケーションの承認/拒否を設定する場合は、次のようにします。

 update my_table
 set    status_id = case my_table.application_id
                      when application_id_for_accepted_offer then 7
                      else 8
                    end
 where  student_id = student_id_to_update;
于 2012-12-05T12:32:08.563 に答える