Discussion :

[dcollart]

Bonjour,

dans le cadre de mon projet, je rencontre quelques petits problèmes dans la gestion des transactions.

Une de mes procedure contient un curseur qui fait appel à une autre procedure

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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
CREATE OR REPLACE procedure1(...)
AS
...
...
...
    TYPE c_cursor IS REF CURSOR; -- Création d'un type CURSOR
    cCurseur c_cursor;
...
...
...
BEGIN
...
...
...
    OPEN cCurseur FOR vRequete;
    LOOP
        FETCH cCurseur INTO vTruc;
        EXIT WHEN cCurseur %NOTFOUND;
 
        -- On appelle une autre procedure 
        GEST_HARPEGE.P6PR_modifAffectation procedure2(...);
        ...
        ...
        ...
 
    END LOOP;
    CLOSE cCurseur ;
 
    -- On valide les opérations en base de données
    COMMIT;
 
EXCEPTION
 
    WHEN OTHERS THEN
        -- Arrêt de la procédure à la suite d'une erreur ORACLE
        ROLLBACK;
 
END;
 
CREATE OR REPLACE procedure1(...)
AS
...
...
...
 
BEGIN
...
...
...
   -- Ici on réalise le traitement.
   -- Il n'y a pas de COMMIT. Le commit doit être réalisé par celui de la procedure1
...
...
...
EXCEPTION
 
    WHEN OTHERS THEN
        -- Arrêt de la procédure à la suite d'une erreur ORACLE
        ROLLBACK;
 
END;

Par le biais du curseur, la procedure1 apelle a plusieurs reprise le procedure2.
Dès qu'une anomalie apparaît dans la procedure2, il faut que la procedure1 s'arrête et qu'un ROLLBACK soit réalisé. En d'autres termes, on doit valider l'ensembles des opérations des procedure2 ou aucune.
Ce que je veux faire ne fonctionne pas. En effet si la procedure2 a été appelée 9 fois par la procedure1 et qu'une erreur se produit sur le 10ème appel, alors le traitement du 10ème appel subit un ROLLBACK (celui de la procedure2) mais les traitements des 9 autres sont validés dans la base de données.
Y-a-t-il un COMMIT implicite à la fin d'une procedure ? Ca me semblerait bizarre...
Est-ce que mon problème vient du fait que j'ai géré l'erreur dans le procedure2 par une EXCEPTION ?

Merci de votre aide et bonne journée.

[orafrance]

n'y aurait-il pas un PRAGMA AUTOMOUS TRANSACTION quelque part ? notamment dans la procédure 2 ?

Sinon, la procédure2 fait bien un RAISE EXCEPTION en cas de problème pour déclencher l'exception ?

[plaineR]

Pour moi le problème vient que vous gérez un bloc exception dans le procedure2
=> s'il y a erreur dans la procedure 2, l'exécution continue dans la procédure 1
=> il peut donc y avoir commit

[sygale]

Pour moi le problème vient que vous gérez un bloc exception dans le procedure2
=> s'il y a erreur dans la procedure 2, l'exécution continue dans la procédure 1
=> il peut donc y avoir commit

Oui je suis d'accord et pourquoi mettre en place une gestion d'erreur dans la procedure2 alors que tout peut être fait dans la procédure1 ?

Exemple avec ton code :

Code :

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

1
2
3
4
5
6
10 traitements/boucles
boucle1 : plantage = rollback de la procédure2 depuis le début de transaction !
mais le traitement continu
Boucle2,3,4,5,6,7,8,9,10 ok avec commit à la fin
ce qui donne : 9 traitement commité et le premier en erreur.
ta procédure2 ne trace pas l'indice de boulce du plantage, donc tu ne sais pas sur quel appel elle a plantée

Sinon un raise_application_error ne fait pas de commit implicite. Heureusement la galère sinon.

[Wurlitzer]

Les seuls COMMIT implicites que je connaisse sont ceux des instructions DDL (CREATE TABLE, etc). As tu vérifié si tu en avais quelques part dans ton code ?

[dcollart]

Merci à tous...

pour régler mon problème j'ai donc supprimer la gestion d'erreur dans la procedure2. Lorsque la procedure2 plante alors la procedure1 s'arrête maintenant. Il restait après ça une autre anomalie : Lorsque la procedure2 plantait, les commandes de la procedure1 était tout de même validées en base de données : le problème provenait d'un commit implicite réalisé pour l'execution d'une DDL (un DROP SEQUENCE suivi d'un CREATE SEQUENCE).

Merci encore et bonne journée.