Especificar el esquema principal del gatillo en el cuerpo del gatillo

Question

En DB2 para el sistema IBM I Creo este disparador para grabar en MYLOGTABLE Cada operación de inserción realizada en 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;

El DBMS almacena el cuerpo del gatillo con MYSCHEMA.MYLOGTABLE codificado.

Ahora imagine que copiamos todo el esquema como un nuevo esquema NEWSCHEMA. Cuando inserto un registro en NEWSCHEMA.MYCHECKEDTABLE Se agregará un registro de registro a MYSCHEMA.MYLOGTABLE en vez de NEWSCHEMA.MYLOGTABLE, es decir, en el esquema donde el gatillo y su mesa viven. ¡Esto es causa de grandes problemas! También porque muchos usuarios pueden copiar el esquema sin mi control ...

Asi que, ¿Hay alguna forma de especificar, en el cuerpo del gatillo, el esquema donde vive el gatillo? De esta manera, escribiremos el registro de registro en el correcto MYLOGTABLE. Algo como PARENT SCHEMA... o hay un solución alterna? ¡Muchas gracias!

Answer 1

Lamentablemente me di cuenta de que el esquema donde vive un desencadenante no se puede detectar Desde el cuerpo del gatillo interior.

Pero hay algunas soluciones (gracias a @Krmilligan también):

• Quitar la autoridad del usuario para ejecutar CPYLIB y hacer que usen una utilidad.
• Cree un agente de fondo en el sistema que se ejecute peridiócicamente en busca de desencadenantes que están fuera de sincronización.
• Por comando CPYLIB Establecer el valor predeterminado para TRG opción *NO. De esta manera, los desencadenantes nunca se copiarán, excepto si el usuario lo especifica explícitamente.

Elijo el último porque es el más simple, incluso si puede haber contextos donde se requiere una copia de activación. En tales casos tomaría la primera solución.

Answer 2

Los desencadenantes externos definidos en un HLL tienen acceso a un búfer de activación que incluye el nombre de la biblioteca de la tabla que disparó el gatillo. Esto podría usarse para calificar la referencia al MYLOGTABLE.

Consulte el Capítulo 11.2 "Estructura del programa de activación" del IBM Redbook Procedimientos almacenados, desencadenantes y funciones definidas por el usuario en DB2 Universal Database for Iseries para más información.

Alternativamente, es posible que pueda usar el CURRENT SCHEMA registro especial o el GET DESCRIPTOR Declaración para averiguar dónde se encuentran actualmente el disparador y/o la tabla.