Discussion :

[BTB36]

Bonjour
J'essaie de créer un trigger qui envoie un email lorsque le compteur atteint la valeur souhaiter
Ci joint le code

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
create or replace TRIGGER email
   AFTER UPDATE
   ON T_METER
   FOR EACH ROW
 
   DECLARE
   CURSOR NS
   IS
      SELECT EREQ_SERIAL_NUMBER, MDMT_DESCRIPTION
        FROM T_METER , T_EQUIPMENT
       WHERE PK_METER = MDMT_CUMULATIVE_UNITS
       AND ereq_code = MDMT_CODE;
 
   objet       VARCHAR2 (100 BYTE);
   MESSAGE     VARCHAR2 (500 BYTE);
   recipient   vest_tools.tablevarchar100;
BEGIN
 
   IF MDMT_CUMULATIVE_UNITS >= MDMT_NUMBER3
   THEN
      objet := 'Fin de vie de l'' Adapter'|| MDMT_CODE;
 
      FOR vie IN NS
      LOOP
         MESSAGE :=
               'L'' Adapter '
            || MDMT_DESCRIPTION
            || ' avec le numero de série '
            || EREQ_SERIAL_NUMBER
            || ' à attend son cycle de fin de vie ';
         MESSAGE :=
               MESSAGE
            || CHR (10)
            || ' ---- NE PAS REPONDRE ---'
            || CHR (10)
            || '---- Mail  envoyé automatiquement par Coswin  ----';

lors de l’exécution du tregger j'obtiens le message suivants:

Erreur(22,4): PL/SQL: Statement ignored
Erreur(22,7): PLS-00201: l'identificateur 'MDMT_CUMULATIVE_UNITS' doit être déclaré

[mnitu]

Le message semble assez clair: il connait pas que-est ce MDMT_CUMULATIVE_UNITS.

[BTB36]

Comment peux-je le déclarer ?

sachons que le champ MDMT_CUMULATIVE_UNITS est utilisable dans la table T_METER

[mnitu]

Il y a un tutoriel PL/SQL sur ce site.

[Ikebukuro]

Tu déclares un curseur mais tu ne l'utilises pas... où est le OPEN, le FETCH, le CLOSE?

Il faudrait dans ton SELECT mettre les colonnes MDMT_CUMULATIVE_UNITS et MDMT_NUMBER3 et les stocker dans deux variables.

En outre je te suggère fortement de préfixer tes variables par v_ pour une meilleure lisibilité, et, même mieux, v_var_ pour VARCHAR2.

Je crois aussi que le code
IF MDMT_CUMULATIVE_UNITS >= MDMT_NUMBER3
devrait être remplacé par
IF v_MDMT_CUMULATIVE_UNITS >= v_MDMT_NUMBER3

[mnitu]

...
En outre je te suggère fortement de préfixer tes variables par v_ pour une meilleure lisibilité, et, même mieux, v_var_ pour VARCHAR2.
...

C'est loin d'être un bon conseil.

[BTB36]

Tu déclares un curseur mais tu ne l'utilises pas... où est le OPEN, le FETCH, le CLOSE?

Si mes connaissance est juste la boucle FOR se chargeant de l'ouverture, de la lecture des lignes et de la fermeture?

[Ikebukuro]

C'est loin d'être un bon conseil.

Peux-tu détailler STP, cela m'intéresse beaucoup.

[mnitu]

L’idée de préfixer les variables avec des lettres indiquant leur type c’est-à-dire la notation hongroise à fait son chemin dans le langage c. Mais en PL/SQL la bonne pratique indique que les variables doivent être ancrées aux colonnes des tables référencées. De cette façon une éventuelle évolution des tables n’impliquerait pas l’évolution du code. Le langage PL/SQL est unique du ce point de vue et par conséquence les bonnes pratiques sont différentes.

La deuxième raison pour préfixer les variables est liée à leur utilisation en tant que variables de liaison dans les requêtes SQL. Lors de la compilation du code PL/SQL le compilateur essaie de résoudre les noms mais en commençant par passer le texte de la requête au moteur SQL. Seulement les noms non résolues par le moteur SQL sont par la suite analysés par le moteur PL/SQL
Cela a comme conséquence fâcheuse que le code ci-dessous s’exécute sans anomalie mais produit des résultats incorrects parce que la résolution des noms est faite complètement dans le moteur SQL. La faible connaissance du langage a amené des générations des programmeurs de résoudre ce problème en utilisant de soit disant « normes » de programmation qui stipulait que toutes les variables doivent être préfixées par des lettre de type « v_ » pour indiquer la variable et contourner ce problème. En analysant cette solution on s’aperçoit vite que cela pose une contrainte nouvelle mais cette fois ci sur la(es) table(s) ou la(es) vue(s) référencés par la requête. Maintenant il est nécessaire que la « norme » de nommage des colonnes indique : « il est interdit de nommer une colonne en la préfixant avec un v_ » ce qui est toute à fait inutile.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Declare
  deptno  emp.deptno%Type := 10;
begin
  For rEmp In (Select e.ename, e.deptno
                 from emp e
                where e.deptno = deptno -- veut dire variable PL/SQL auch!
                order by e.deptno
              )
  Loop
    dbms_output.put_line(rEmp.ename||' travaille dans le service numéro '||To_Char(rEmp.deptno));
  End Loop;
end;

En fait comme l’exemple suivant le montre il suffit de nommer le bloc PL/SQL et d’utiliser ce nom dans la référence de la variable pour que la requête s’exécuté correctement parce que cette fois ci la résolution du nom b.deptno ne peut plus se faire par le moteur SQL mais elle est renvoyé vers le moteur PL/SQL.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
<<b>>Declare
  deptno  emp.deptno%Type := 10;
begin
  For rEmp In (Select e.ename, e.deptno
                 from emp e
                where e.deptno = b.deptno -- variable PL/SQL OK!
                order by e.deptno
              )
  Loop
    dbms_output.put_line(rEmp.ename||' travaille dans le service numéro '||To_Char(rEmp.deptno));
  End Loop;
end;

En pratique ce ne sont pas des blocks PL/SQL mais des procédures et fonctions packagées qui sont exécutés par l’application et dans ce cas c’est le nom de ces procédures qui doivent être employées pour préfixer les variables. De cette façon le problème est résolu sans poser des contraintes ailleurs.
De plus à partir de la version 11 d’Oracle l’invalidation des objets lors de la modification des tables référencées a été modifiée pour une politique moins agressive. C’est-à-dire que si les procédures sont écrites de cette manière ils auront plus des chances de ne pas être invalidées d’une manière intempestive.
Il est intéressant aussi de remarquer que la programmation dans les autres langages n’implique pas cette problématique mais cela au prix d’un travail supplémentaire de programmation. Dans ce contexte il faut également souligner les extraordinaires efforts de simplification de la programmation faite par l’équipe en charge du langage PL/SQL chez Oracle.