Discussion :

[blackwizard]

bonjour

lors d'un insert, je souhaite appeler une procedure dans le trigger
et passer la ligne insérée en argument de la procedure

la table ttest (id int, lib varchar, name varchar);

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
CREATE OR REPLACE PROCEDURE p (r IN ttest%ROWTYPE)
IS
BEGIN
   DBMS_OUTPUT.put_line (r.lib);
END;
/
 
CREATE OR REPLACE TRIGGER SUN.ttest_insert
   AFTER INSERT
   ON ttest
   REFERENCING NEW AS NEW
   FOR EACH ROW
BEGIN
   /*DBMS_OUTPUT.put_line (:NEW.lib);*/
   p (:NEW);
END;
/
/

dans le cas présent, le trigger ne compile pas :

PLS-00049: variable de lien erronée 'NEW'

donc, y a t il moyen de lasser le :new entier en param, et non tous les attribut un par un (:new.id, :new.lib, :new.name) ???? (si oui comment?)

l'exemple est bien entendu très simplifié, on résound le problème en collant le code de la procedure dans le trigger,
mais j'utilise des procedures notamment pour mutualiser un peu de code, et que ça fait plus propre

merci
++

[plaineR]

Non ce n'est pas possible.

[orafrance]

quel est l'objectif ?

[blackwizard]

quel est l'objectif ?

l'objectif en version simplifiée: pour chaque ligne que j'insert(update,delete) dans la table T1, je veux que le trigger l'insert(update,delete) dans la table T2

j'aurai passé simplement la clé primaire, mais il y avais le problème de la table mutante (ora-04091).
et accessoierment, ça fait gagner un requête

[orafrance]

alors regarde plutôt du coté des vues matérialisées

[blackwizard]

ok, d'après ce que j'ai pu comprendre des MATERIALIZED VIEW, la vue remplacerait ma 2e table
il faut alors que je précise mon problème: je travaille sur une appli qui souffre de ses défauts de conception
vu qu'on est en prod, la solution passe par des étapes intermédiaires.

au départ il y avait une table Poject comme suit :
table Project (id, name, desc,.... facility, specifications)

puis ils ont décidé que pour un projet, on pouvait avoir jusqu'à 3 facilities,
et au lieu de créer un table d'association project-facility, ils ont ajouté des colonnes dans la table project:
table Project (id, name, desc,.... facility1, specifications1, facility2, specifications2, facility3, specifications3)

et là, moi j'ai créé la table project-facility
table project-facility(projectId, facilityId, orderId, specifications)
remplie avec les colonnes correpondant de la table project

en Prod, on remplit toujours dans la table project, mais avec des triggers je synchronise avec project-facility

A terme les colonnes de project sauteront, et on remplira directement project-facility

voilà
++

[blackwizard]

Non ce n'est pas possible.

ça a le mérite d'être clair

n'y aurait il pas de solutions détournées ?

- le type de :new est bien ttest%ROWTYPE ?
dans ce cas y aurait il moyen avec une sorte de boucle, de copier tous les atribut de new dans un nouvel objet de type ttest%ROWTYPE que je passerais en param à ma procedure ?

[Pomalaix]

ça a le mérite d'être clair

n'y aurait il pas de solutions détournées ?

- le type de :new est bien ttest%ROWTYPE ?
dans ce cas y aurait il moyen avec une sorte de boucle, de copier tous les atribut de new dans un nouvel objet de type ttest%ROWTYPE que je passerais en param à ma procedure ?

Feuerstein propose une procédure qui facilite la vie pour créer des déclencheurs permettant de passer en paramètre l'équivalent du :NEW.*
Mais ça reste du statique, dépendant de la table concernée.
http://examples.oreilly.com/oraclep3.../genTrigRec.sp

[blackwizard]

Feuerstein propose une procédure qui facilite la vie pour créer des déclencheurs permettant de passer en paramètre l'équivalent du :NEW.*
Mais ça reste du statique, dépendant de la table concernée.
http://examples.oreilly.com/oraclep3.../genTrigRec.sp

finalement la solution est bien de dupliquer les attribut 1 par 1, mais
merci, ça évite de taper des km de text, et il n'y a ps de risque de faute de frappe