Utilisation d'un like dans une procédure

Version imprimable

Bonjour à tous,

Sous Oracle j'ai créé la procédure ci-dessous :

mais la partie LIKE est KO.

Seriez vous m'aider?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 delete pmvtsto where 1=1 and numfiche is null and pmvtsto.rdate >= '01/12/2017' and pmvtsto.rdate <= '01/02/2018' --and pmvtsto.rdate >= sysdate-2 and pmvtsto.arcode = ligneRec.arcode and libmvt like '%lignerec.focode%' ; End loop; Commit; End
Merci!!

je ne vous ai pas mis toute la procédure.
c'est fait.

Code:

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
create or replace procedure VILO_SUPP_MVT_PREVISION_CONSO 
is
begin
for ligneRec in 
( 
        select 
         distinct(pnomenof.arcode)
        ,focode 
        from pordrfab
        inner join pnomenof on pnomenof.OBCLEUNIK = pordrfab.OBCLEUNIK
        where 1=1
        and datemodif >= '01/12/2017'
        and datemodif <= '01/02/2018'
        and focode = '474739'
        and OBETAT = 6
        --and datemodif >= trunc(sysdate) -1
)
loop
delete pmvtsto 
where 1=1
and numfiche is null
and pmvtsto.rdate >= '01/12/2017'
and pmvtsto.rdate <= '01/02/2018'
--and pmvtsto.rdate >= sysdate-2
and pmvtsto.arcode = ligneRec.arcode
and libmvt like '%lignerec.focode%'
;
End loop;
Commit;
End VILO_SUPP_MVT_PREVISION_CONSO;

j'ai fait des recherches mais rien trouvé pour le moment....
la procédure fonctionne sans le LIKE...

Merci!

21/02/2019, 17h39
tatayo

Bonjour,
Que signifie "la partie LIKE est KO" ?
Quel est le problème exactement ?
"La procédure fonctionne sans le LIKE, mais pas avec." Mais encore ? Elle ne supprime rien, pas les bonnes lignes ?

Il nous faudrait un jeu d'essai, et une description précise du problème.

Tatayo.
21/02/2019, 17h48
Joe cache

Merci tatayo :)

Je n'ai pas d'erreur au moment de la compilation. quand je l’exécute elle ne me supprime pas ma ligne effectivement. (Proc en test sur base de test)

la procédure s’exécute correctement sans erreur.

j'ai testé ma procédure en supprimant le "like" en en faisant un test avec un update. et ça marche.

Merci
21/02/2019, 18h02
Scriuiw
Ajouter des traces à l'aide de DBMS_OUTPUT.PUT_LINE pour savoir si vos instructions impactent des lignes
Par exemple après le delete :
Code:

1 2 dbms_output.put_line('Nb lignes : '||SQL%ROWCOUNT);
Pour voir les traces, il faut qu'elles soient activées :
Code:

1 2 3 4 set serveroutput on OU set serveroutput on size 1000000
PS : Un COMMIT dans la procédure n'est pas nécessairement une bonne pratique
21/02/2019, 18h16
skuatamad
Vous traitez lignerec.focode comme une chaine de caractère, essayez comme ça :

Code:

and libmvt like '%'||lignerec.focode||'%'

PS : utilisez TO_DATE pour éviter une conversion implicite qui se base sur les paramètres de votre session,
Et attention aux heures, si vous voulez les données de la journée du 01/02, c'est plutôt :
Code:

1 2 and datemodif >= to_date('01/12/2017','dd/mm/yyyy') and datemodif < to_date('01/02/2018','dd/mm/yyyy') + 1
22/02/2019, 09h25
Joe cache

Merci Scriuiw et skuatamad pour votre aide c'est résolu :

and libmvt like '%'||lignerec.focode||'%'

Citation:

PS : Un COMMIT dans la procédure n'est pas nécessairement une bonne pratique

Il me semblait que c'était nécessaire? peux tu m'en dire plus?

Je regarde également pour les traces ça peut être bien pratique!!

Merci.

J'aurais encore une question.

Peux ton historiser les mouvements supprimés ?

il est nécessaire pour ça de créer un trigger de type :
Code:

1 2 3 4 5 6 CREATE TRIGGER `suppr` BEFORE delete ON `test` FOR EACH ROW BEGIN insert into `hist` (`id`,`lib`,`hist_date`,`hist_time`,`hist_user`,`hist_comm`) values (old.id, old.lib, current_date(), current_time(), user(), "delete"); END
Merci.

J'ai testé les traces, ça fonctionne, et il m'indique le nombre de ligne supprimée.

22/02/2019, 15h00
Scriuiw
En règle générale, il faut laisser l'appelant décider du COMMIT ou ROLLBACK car c'est lui qui est le mieux placé pour prononcer l'un ou l'autre.
D'autre part, les COMMIT intermédiaires exécutés implicitement dans des procédures peuvent valider à tort une partie du traitement alors que celui-ci termine en échec.

On se retrouve alors avec un première partie de traitement exécutée et validée mais une seconde partie en erreur.
Les données se trouve alors dans une situation bâtarde.

Par exemple l'enchaînement de procédure suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 BEGIN Pkg de traitement Appel Proc 1; Appel Proc 2; Appel Proc 3; COMMIT; Exception When Others then Trace(...); ROLLBACK; END Pkg
Si les trois procédures se terminent correctement alors on COMMIT sinon on intercepte l'erreur, on la trace et on fait ROLLBACK ce qui permet de revenir à l'état initiale au niveau des données.

Maintenant imagine que la procédure 1 contient un COMMIT et qu'on a l'exécution suivante :
Code:

1 2 3 4 5 6 7 8 9 10 11 Pkg de traitement Appel Proc 1 --> COMMIT Appel Proc 2 --> ERREUR Appel Proc 3 COMMIT; Exception When Others then Trace(...); ROLLBACK; End Pkg
Les modifications de la procédure 1 sont validées mais les données sensées être mises à jour par les proc 2 et 3 restent inchangées car le traitement est parti en exception et a fait un ROLLBACK

Tu te retrouves avec des données "à moitié" mises à jour.
- Comment tu rattrapes cela ?
- Comment tu relances ?
- Les données sont-elles toujours fonctionnellement consistantes et valides ?

Après ils existent des cas où il est nécessaire ou préférable d'avoir un COMMIT, notamment lorsque de gros volumes sont traités de façon ensembliste.
A voir si c'est ton cas.
22/02/2019, 19h45
tbc92

Pour éviter les apostrophes et les Pourcents qui peuvent vite devenir lourdingues, on peut aussi faire : where instr(libmvt , lignerec.focode) > 0 ( ou instrb ?)
Mais pédagogiquement, c'est bien de comprendre pourquoi la première syntaxe ne donnait pas le bon résultat, et pourquoi la proposition de skuatamad fonctionne.
25/02/2019, 11h29
Joe cache

Merci Scriuiw c'est clair!!;)