2008-10-14 6 views
7

C'est ce que j'ai actuellement:Quelle est la syntaxe pour utiliser une instruction Select dans un déclencheur 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 a cette erreur: PL/SQL: ORA-00923: mot clé FROM pas trouvé où prévu

+0

À quelle ligne cette erreur est-elle signalée? –

+0

La première erreur de la séquence est sur la ligne 'WHERE PERSONID ...'. – Equistatic

+0

Mis à jour ma réponse, il y a quelque chose d'autre à votre exemple qui n'a pas été posté. Le code comme écrit fonctionne pour moi. –

Répondre

6

1) Il doit y avoir quelque chose d'autre à votre exemple parce que cela semble sûr de travailler pour moi

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) Vous voulez probablement déclarer V_EMPLID comme étant de type Person.PersonNum% TYPE afin que vous puissiez assurez-vous que le type de données est correct et que, si le type de données de la table change, vous n'avez pas besoin de modifier votre code.

3) Je suppose que vous savez que votre déclencheur ne peut pas interroger ou mettre à jour la table sur laquelle le déclencheur est défini (donc pas de requêtes ou d'insertions dans someTable).

+0

1) J'ai négligé de 'POUR CHAQUE RANGÉE' avec le premier montage, c'est comme ça que c'est configuré. Merci. – Equistatic

+0

Je l'ai réécrit sous cette forme et cela semble fonctionner. Cela peut avoir quelque chose à voir avec l'alignement, les caractères de tabulation dans le script ou la différence de séparation de ligne dans l'instruction into. Merci. – Equistatic

-2

Je ne voudrais pas utiliser un select statment dans un déclencheur déjà. Insérer dans la table plutôt que de sélectionner dans. Une fois que la table existe déjà select into ne fonctionne pas dans la plupart des bases de données.

1

Vous jouez avec Lava (pas seulement le feu) dans votre trigger. DBMS_OUTPUT dans un trigger est vraiment, vraiment mauvais. Vous pouvez souffler sur un débordement de tampon dans votre déclencheur et la transaction entière est tirée. Bonne chance pour suivre ça. Si vous devez effectuer un comportement semblable à la sortie vers la console, appelez une procédure AUTONOMOUS TRANSACTION qui écrit dans une table.

Les déclencheurs sont plutôt mauvais. Je les aimais, mais ils sont trop difficiles à retenir. Ils affectent souvent les données menant à des données MUTATING (effrayant et pas seulement parce que Halloween est proche).

Nous utilisons des déclencheurs pour modifier la valeur des colonnes comme .new: LAST_MODIFIED: = sysdate et .new: LAST_MODIFIED_BY: = user. C'est tout.

N'autorisez jamais un TRIGGER pour empêcher une transaction de se terminer. Trouver une autre option

+0

Le déclencheur final n'aura pas DBMS_OUTPUT – Equistatic

Questions connexes