Verrouiller une table [Résolu]

[LinuxUser]

Bonsoir,
J'ai un peu de mal à utiliser LOCK surtout que je comprnd pas trop les différents mode.
Je souhaiterais verrouiller la table pour qu'on puisse encore insérer,eventuellement mettre à jour mais pas supprimer.

Code :

1
2
 
LOCK TABLE <nomTable> ???

Merci.

[Michel SALAIS]

Malheureusement, ce n'est pas possible toutes les verrous traitent INSERT, UPDATE et DELETE de la même façon ...

Quel est le besoin?

[LinuxUser]

J'ai fais un TRiGGER qui archive une commande supprimée, je souhaite que cette commande ne puisse être supprimée de la table d'archivage.

[Michel SALAIS]

Donc le besoin d'empêcher la suppression de lignes dans cette table est plutôt permanent ...

Ceci peut être atteint en utilisant un trigger (delete) qui renvoie une erreur non capturée par le trigger lui même. L'effet du trigger dans ce cas est d'annuler la suppression

[LinuxUser]

Envoyé par Michel SALAIS

utilisant un trigger (delete) qui renvoie une erreur non capturée par le trigger lui même. L'effet du trigger dans ce cas est d'annuler la suppression

Je n'ai pas compris, surtout le passage "une erreur non capturée par le trigger lui même".
Peux tu m'expliquer s'il te plais.

[Michel SALAIS]

En gros le core du trigger devrait ressembler à ça

Code :

1
2
3
4
5
 
...
BEGIN
  reaise_application_error(-20001, 'Suppression impossible dans la table');
END;

Le trigger provoque une erreur en par conséquent l'instruction à l'origine de son déclenchement sera annulée.
La capture éventuelle des erreurs par un bloc PL/SQL se fait si le bloc contient la section EXCEPTION.

[LinuxUser]

Donc il faut que je fasse un TRIGGER dans lequel je lève une exception?

Code :

1
2
3
4
5
6
7
 
CREATE OR REPLACE TRIGGER AFTER DELETE ON ArchiveCommande
FOR EACH ROW
BEGIN
  raise_application_error(-20001, 'Suppression impossible dans la table');
END;
/

Que signifie le -20001 ?

[Michel SALAIS]

Ah!
J'ai oublié de signaler que les erreurs que nous pouvons soulever avec raise_application_error sont obligatoirement dans l'intervalle -20999 .. -20000. Oracle ne produit aucune erreur interne ayant un code dans cet intervalle. C'est au développeur de bien gérer les erreurs en question.

Le trigger n'a pas besoin de se déclencher pour chaque ligne ==> enlever la ligne 'FOR EACH ROW". Puis dans ce cas je préfère un trigger BEFORE.

[LinuxUser]

Merci beaucoup, donc on obtient cela

Code :

1
2
3
4
5
6
 
CREATE OR REPLACE TRIGGER verrou BEFORE DELETE ON HistoriqueF
BEGIN
  raise_application_error(-20001, 'Suppression impossible dans la table');
END;
/

Qu'en penses_tu?

[Michel SALAIS]

Oui c'est bien ça ...

[LinuxUser]

Merci beaucoup, mais désolé d'insister, est-ce que -20001 correspond à une erreur particulière?

[Michel SALAIS]

Je constate que je n'étais pas claire dans ma réponse sur ce point. La réponse est non. N'importe quelle erreur dans l'intervalle -20999 .. -20000 peut être utilisée et c'est au développement d'organiser l'utilisation de ces erreurs. Le moteur Oracle ne produit aucune erreur dans cet intervalle.

Afin d'avoir plus d'informations sur le traitement des erreurs, tu peux regarder ici

[Michel SALAIS]

Il y a aussi une autre possibilité qui consiste à ne pas donner le droit de supprimer dans la table aux utilisateurs de l'application mais cette solution qui est plus simple est moins blindée dans la mesure où certains utilisateurs privilégiés pourraient supprimer des lignes de cette table ...

[LinuxUser]

Je vais devoir créer des rôles et donner tel ou tel droit, c'est cela ?

[pifor]

Voir aussi la FAQ à ce sujet ou éventuellement passer à Oracle 11 et utiliser la fonctionnalité de table en lecture seule.