2008-10-14 22 views
7

Esto es lo que tengo actualmente:¿Cuál es la sintaxis para usar una instrucción Select dentro de un Trigger PL/SQL?

CREATE OR REPLACE TRIGGER MYTRIGGER 
AFTER INSERT ON SOMETABLE 
FOR EACH ROW  

DECLARE 
v_emplid varchar2(10);  

BEGIN 
SELECT 
    personnum into v_emplid 
FROM PERSON 
WHERE PERSONID = :new.EMPLOYEEID; 

dbms_output.put(v_emplid); 

/* INSERT INTO SOMEOTHERTABLE USING v_emplid and some of the other values from the trigger table*/ 

END MYTRIGGER;  

DBA_ERRORS tiene este error: PL/SQL: ORA-00923: DE palabra clave no se encuentra donde se esperaba

+0

¿En qué línea se ha informado de este error? –

+0

El primer error en la secuencia se encuentra en la línea 'WHERE PERSONID ...'. – Equistatic

+0

Actualizado mi respuesta, hay algo más en su ejemplo que no se ha publicado. El código tal como está escrito funciona para mí. –

Respuesta

6

1) Debe haber algo más a su ejemplo, porque seguro que parece que funciona para mí

SQL> create table someTable(employeeid number); 

Table created. 

SQL> create table person(personid number, personnum varchar2(10)); 

Table created. 

SQL> ed 
Wrote file afiedt.buf 

    1 CREATE OR REPLACE TRIGGER MYTRIGGER 
    2 AFTER INSERT ON SOMETABLE 
    3 FOR EACH ROW 
    4 DECLARE 
    5 v_emplid varchar2(10); 
    6 BEGIN 
    7 SELECT personnum 
    8  into v_emplid 
    9  FROM PERSON 
10 WHERE PERSONID = :new.EMPLOYEEID; 
11 dbms_output.put(v_emplid); 
12 /* INSERT INTO SOMEOTHERTABLE USING v_emplid and some of the other values 
from the trigger table*/ 
13* END MYTRIGGER; 
14/

Trigger created. 

SQL> insert into person values(1, '123'); 

1 row created. 

SQL> insert into sometable values(1); 

1 row created. 

2) Es posible que desee declarar V_EMPLID como del tipo Person.PersonNum% TIPO, para que pueda asegúrese de que el tipo de datos sea correcto y de que si el tipo de datos de la tabla cambia no necesitará cambiar su código.

3) Supongo que sabe que su desencadenante no puede consultar o actualizar la tabla en la que se define el desencadenador (por lo tanto, no consultas o inserta en alguna tabla).

+0

1) Olvidé "POR CADA FILA" en la primera edición, así es como está configurada. Gracias. – Equistatic

+0

Lo reescribí de esta forma y parece funcionar. Puede haber tenido algo que ver con la alineación, los caracteres de tabulación en el guión o la diferencia en la separación de línea en la declaración into. Gracias. – Equistatic

-2

yo no usaría un selecto DECLARACIÓN en un disparador nunca. Insertar en la mesa en lugar de seleccionar. Una vez que la tabla ya existe, select into no funciona en la mayoría de las bases de datos.

1

Estás jugando con Lava (no solo fuego) en tu gatillo. DBMS_OUTPUT en un disparador es realmente, muy malo. Puede explotar en un desbordamiento de búfer en su desencadenante y se toma la transacción completa. Buena suerte rastreando eso. Si debe realizar un comportamiento de salida a consola, invoque un procedimiento AUTONOMOUS TRANSACTION que escriba en una tabla.

Los disparadores son bastante malvados. Me gustaban, pero son demasiado difíciles de recordar. Afectan los datos que a menudo conducen a datos MUTANTES (miedo y no solo porque Halloween está cerca).

Utilizamos activadores para cambiar el valor de columnas como .new: LAST_MODIFIED: = sysdate y .new: LAST_MODIFIED_BY: = usuario. Eso es.

Nunca permita que un GATILLO evite que se complete una transacción. Encuentra otra opción

+0

El desencadenador final no tendrá DBMS_OUTPUT – Equistatic

Cuestiones relacionadas