SQL*Plus commit on exit

[Wurlitzer]

Par défaut, lorsque l'on quitte SQL*Plus par un exit. Il fait un commit implicite. J'ai un lointain souvenir qui me dit qu'il est possible de remplacer ce commit par un rollback (ce qui peu etre sympa pour eviter des erreurs sur une base de prod).

Est ce que quelqu'un a une idée de comment cela se fait ?

Merci,

[pifor]

Code :

1
2
 
EXIT ROLLBACK;

Je crois qu'on peut seulement forcer un ROLLBACK en cas d'erreur avec:

Code :

1
2
 
WHENEVER SQLERROR EXIT ROLLBACK;

[orafrance]

je crains que non... ce n'est pas possible

pifor -> en effet

[Wurlitzer]

Code :

1
2
 
EXIT ROLLBACK

permet de faire volontairement un rollback. Moi, je cherche a éviter de faire involontairement un COMMIT en tapant EXIT par erreur (par un malheureux reflexe trop rapide).

Je suis quasiment sur que c'est possible mais impossible de remettre la main dessus. Je vais rechercher dans mes archives.....

[jlucch]

Pour info, un petit récapitulatif qui peut être utile :

Oracle part du principe qu'une transaction (update, insert, delete) sera 99% du temps commitée.

Il y a très peu de cas où le rollback se fait automatiquement

Liste des cas où l'on "commit" automatiquement :
Imaginons une table test avec 1 enregistrement :

Code :

1
2
3
 
DELETE FROM test;
1 lignes supprimée

Si vous lancez à la suite de cela , l'uns des ordres suivants, alors vous "commitez" la ou les transaction(s) effectuée(s) précédement :

Code :

1
2
3
4
5
6
7
8
9
10
11
connect XX/XX@BASE
disconnect
exit;
quit;
Alter XXX,
Create XXX
Drop XXX
Rename XXX
Truncate XXX
et évidement : commit;

Cas ou l'on Rollback :

Code :

1
2
3
4
5
6
 
CTRL ALT DEL
Rollback
Fermer la fenêtre par l'intermediaire de la croix
RESET
ON/OFF

NB : Taper "exit" dans une session sqlplus n'a pas le même comportement que "tuer" la session par l'intermédiaire de la croix ...

Exit = commit + fermeture sqlplus
Croix = rollback + fermeture sqlplus


Cas des PL/SQL :

Lorsque vous réalisez des traitements en PL/SQL, faire très attention aux traitements d'erreur :
Cas de commit automatique :

Code :

Code :

1
2
3
Whenever sqlerror exit ===> le traitement sort sans erreur, et les transactions sont commitées !!!!!
 
Whenever sqlerror exit failure ===> le traitement sort en erreur mais commit !!!!!

Cas de rollback :

Code :

Code :

1
2
Whenever sqlerror rollback ===> le traitement rollback 
Whenever sqlerror exit failure rollback; ===> le traitement rollback et sort en erreur.

Enfin, il est certaines fois utile de vérifier le paramètre : autocommit de sqlplus :
pour cela saisir l'ordre suivant une fois connecté :

Code :

1
2
 
SHOW autocommit;

Si ce paramètre est positionné à : "ON", alors tout ordre de mise à jour dans la session sera commité unitairement et automatiquement (rollback inéfficace ...)

S'il est à "OFF" (position par défaut), alors cela laisse le choix de saisir "commit;" pour valider ou "rollback;" pour annuler.

En résumé et pour finir :
Le mécanisme de sécurité et d’intégrité basique d’Oracle fait qu’une transaction est automatiquement annulée en cas de défaillance :
soit du poste client,
soit du serveur,
soit du réseau.
(CTRL + ALT + DEL du PC client par exemple).
[/FONT]

[laurentschneider]

Code :

SET exitcommit off

[Vincent Rogier]

Envoyé par jlucch

Oracle part du principe qu'une transaction (update, insert, delete) sera 99% du temps commitée.
Il y a très peu de cas où le rollback se fait automatiquement

Hum... Les concepteurs de SQL*PLUS oui... Pas "Oracle"

Il n'existe aucun commit implicite par défaut au niveau de la base de données lors de la deconnexion.

Si SQL*Plus commit, c'est qu'ils committent volontairement par défaut dans le code de C de SQL*PLUS lors de la déconnexion.

[pifor]

Envoyé par laurentschneider

Code :

SET exitcommit off

Oui mais seulement à partir de la 11.2:
http://download.oracle.com/docs/cd/E...w.htm#BGGBBGFI

soit seulement depuis un peu plus de 3 mois sur Windows et 10 mois sur Linux.