Prévoir un Rollback dans une procédure

Alors je comprends très bien ce que veut dire mnitu mais peut être qu'une petite précision s'impose pour toi.

Crée la procédure sans gestion d'erreur, ni commit, ni rollback, côté oracle, puis soit tu catches l'erreur dans l'application web afin d'afficher un joli message d'erreur demandant par exemple de contacter l'administrateur et évidemment dans ce cas, afin de données des billes à l'administrateur, il faut logguer cette erreur, soit tu affiches directement l'erreur...évidemment on te demandera de catcher l'erreur.

Relis le lien vers asktom que j'avais proposé plus haut (enfin lis surout la réponse, le follow up):
http://asktom.oracle.com/pls/asktom/...83800346134509

Citation:

---

exception blocks should be coded for one of two things:

a) at the top level - the block of code that the client submits - in order to LOG the error, eg: client can submit:

begin p(....); exception when others then log_error( ...); RAISE; end;

and that should be at the TOP LEVEL only - not in every silly routine, just in the bit of code that calls your routine


b) when you EXPECT the error, eg:

begin
...
begin
select x into y from t where ...;
exception
when no_data_found then y := some_default;
end;
..........


and can recover from it (eg: it is NOT an error).

---

Et un peu plus loin :

Citation:

---

Todays top level procedure is tomorrows bottom of the stack - or second in a list of five.

It is up to the client to control transactions - only.

---

Et dans ton cas "the client" semble être l'application web.

Citation Tom Kyte

Citation:

---

By default all statements are ATOMIC, the procedure you call either entirely succeeds or entirely fails - UNLESS you

1) put a commit/rollback in there - then game over, the caller of your procedure must deal with the MESS you've left them in - which is an unknown database state (maybe they called 50 other routines before your code - it is UP TO THEM whether they should a) commit, b) rollback, c) retry some operation)

2) put a when others not followed by a raise - then the work that is partially done "stays" and the work never gotten to - is never gotten to. Again, an unknown database state.

---

Il est intéressant dans ce contexte d’examiner la situation suivante :

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 31 32 33 34 35

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 Connected as mni   SQL> SQL> DROP TABLE t1 2 /   Table dropped SQL> CREATE TABLE t1 (c varchar2(1)) 2 /   Table created SQL> begin 2 DBMS_ERRLOG.create_error_log (dml_table_name => 'T1'); 3 end; 4 /   PL/SQL procedure successfully completed SQL> begin 2 INSERT INTO t1 (c) VALUES ('a') log errors into err$_t1 reject limit unlimited; 3 INSERT INTO t1 (c) VALUES ('aa') log errors into err$_t1 reject limit unlimited; 4 end; 5 /   PL/SQL procedure successfully completed SQL> Select Count(*) 2 From t1 3 /   COUNT(*) ---------- 1   SQL>

---

Aie, aie :aie: je n'ai pas mis de gestionnaire d’exception explicite et pourtant « ma base est dans un état instable » :lol:. Mais, non comme d’habitude il faut juste nuancer un peu ces propos.

Ils sont bien tes exemples :ccool: merci.
C'est effectivement un effet de bord de log errors.

PS: je précise au posteur initial que quand je parlais de logguer l'erreur je ne pensais pas à log errors qui n'est pas très utile en OLTP mais plutôt utile dans des insertion/maj massives où l'on souhaite conserver le travail réussi malgré quelques echecs qui seront traités plus tard.

svp merci de m'expliquer le

Code:

---

le log_error( ...);

---

c'est une fonction prédefinie par oracle ou quoi au juste et qu'est ce qu'elle reçoit en paramétre ??

dml error logging in oracle 10g release 2

Citation:

---

Envoyé par mnitu

D'une manière générale ne fait pas de commit dans votre procédure.
Dans votre procédure si une erreur arrive rien n'est inséré dans la table donc faire rollback ne sert strictement à rien.

---

Bonjour, je prends la post en cours de route, je suis en train de creuser côté ROLLBACK & COMMIT, je suis sous ORA 11g.

Lorsque vous dites de ne pas commiter dans une procédure, je comprends les débordements possibles :

Code:

---

1 2 3 4 5 6 7

-- bloc anonyme BEGIN maProc1() -- ne contient pas de COMMIT, insert une ligne dans une table maProc2() -- contient un COMMIT et se comporte comme maProc1 => le COMMIT prend en compte les lignes inserées de maProc1 et maProc2 -- potentiel problème de COMMIT sur des événements non désirés END;

---

Si j'interprète bien, il est dangereux de commiter dans une procédure car elle peut prendre en compte les actions d'autres événements. Par contre si le COMMIT doit se faire à l'extérieur des procédures, dans un bloc plus global, comment gère-t'on les potentiels SAVEPOINT ou ROLLBACK intra-procédures si besoin ? Part-on du principe que c'est l'intégralité du résultat d'une procédure qui doit être commitée ou rollbackée ?

Si vous avez des exemples complets de la manière de gérer plusieurs procédures avec COMMIT et ROLLBACK je serais volontiers preneur.

Merci et bonne fin de journée,