Discussion :

[ceuce]

Bonjour,

J'ai déjà pas mal cherché mais pas encore trouvé de solution!

J'ai une table Accueil qui est de cette forme

Code :

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

1
2
3
4
5
6
7
8
9
 
ID	Code_structure	Adresse
1	10	         1 chemin de Pierres
2	20	         36 rue des Alouettes
3	20	         36 rue des Alouettes
4	20	         36 rue des Alouettes
5	30	         15 avenue de Bel Air
6	30	         15 avenue de Bel Air
7	40	         2 rue André Albert

Ce que je souhaite faire c'est que lorsque l'utilisateur modifie une adresse, alors toutes les adresses dont le code_structure correspond à la ligne qui vient d'être modifiée soient mises à jour avec la nouvelle adresse
Par exemple pour l'enregistrement ID=5, l'adresse devient "15 rue de Bel Air". Je souhaiterai que mon trigger mette à jour l'enregistrement ID=6 (qui a le même code_structure) et automatiquement lui affecter au champ adresse la valeur "15 rue de Bel Air"

Alors oui je sais, ce n'est pas du tout correct modélisationnellement parlant
On devrait avoir une table Structure qui contient l'adresse, liée à la table Accueil qui elle même accueillerait le champ code_structure comme clé étrangère
Seulement voilà, vis à vis de l'outil qui exploite mes données et selon le rendu souhaité par les utilisateurs je n'ai pas vraiment le choix... alors pouvez-vous m'aidez quand même?

Mon trigger aurait cette forme là :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
CREATE OR REPLACE TRIGGER TRIG3 AFTER update of adresse ON Accueil for each row
declare
	pragma autonomous_transaction;
BEGIN
 
update Table
set adresse= :new.adresse where code_structure=:new.code_structure;
 
END ;
/

Seulement, et c'est logique, j'ai l'impression qu'il boucle, j'ai ce message là quand je fais un UPDATE sur mon champ adresse :

Code :

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

1
2
3
ORA-00060: détection d'interblocage pendant l'attente d'une ressource
ORA-06512: à "ENFANCE.TRIG3", ligne 5
ORA-04088: erreur lors d'exécution du déclencheur 'ENFANCE.TRIG3'

Ce qui serait logique puisque je mets à jour un champ qui déclenche lui même un trigger lorsqu'on le met à jour...
Je butte vraiment sur le problème depuis 2 jours!

Merci d'avance pour toutes pistes de reflexion ou de recherches que vous pourriez m'apporter!

[Scriuiw]

Le serpent qui se mord la queue !
Y a pas de solution propre (à mon avis) à ton problème car si tu UPDATE ta table cela active le déclencheur qui UPDATE ta même table et qui se ré-enclenche, etc...

Solution bis, stocké les mises à jour effectuées dans la journée et les répercuter via un traitement de nuit...

[Pomalaix]

Bien sûr que si il y a une solution propre, c'est de corriger le modèle, point final.

Par ailleurs, que vient faire ce PRAGMA AUTONOMOUS TRANSACTION ?
On ne corrige pas des erreurs de modélisation par des erreurs de logique transactionnelle !

[ceuce]

Merci à tous les 2 pour pour vos réponses

Je connais la solution propre qui est de corriger le modèle, mais comme je l'ai dit dans mon message initial je ne veux pas le corriger, c'est un vrai choix, car je ne peux pas me permettre d'avoir 2 tables dans ce cas trés précis de l'exploitation de mes données
Je sais trés bien que ce n'est pas correct, et je cherche à savoir s'il y a possibilité de trouver une solution qui réponde néanmoins à mon besoin, et qui permette de conserver l'intégrité de mes données

J'avais un problème de table mutante et trouvé une solution ici
http://www.astral-consultancy.co.uk/...doco.cgi?11470
C'est pourquoi j'ai un pragma autonomous_transaction...c'est en effet peut être une erreur, je ne maitrise pas cet aspect des triggers

[Pomalaix]

... je ne veux pas le corriger, c'est un vrai choix...

C'est pourquoi j'ai un pragma autonomous_transaction...c'est en effet peut être une erreur, je ne maitrise pas cet aspect des triggers

Je vais insister lourdement : ce n'est pas un vrai choix, c'est une stupidité.

Les transactions autonomes ont 2 effets majeurs, liés au fait qu'elles sont... autonomes :
- elles ne peuvent pas voir les modifications faites par la transaction principale, qui par définition n'est pas encore validée
- elles doivent intégrer un COMMIT ou un ROLLBACK indépendant de la transaction principale (c'est un COMMIT que vous mettriez).

Si votre mécanique en transaction autonome avait la malchance de fonctionner, et que vous annuliez la modification principale de la ligne 5 par un ROLLBACK, la modification de la ligne 6 effectuée par le déclencheur serait quand même validée. Bonjour la cohérence !

Il est tout à fait normal que vous ayez une erreur ORA-04091 dans ce contexte.
Comme vous êtes en version 11g, vous pouvez la traiter proprement grâce au mécanisme des déclencheurs composés.
http://salem-houali.developpez.com/t...ledatabase11g/

[ceuce]

Le pragma autonomous_transaction est sans doute une stupidité puisque je ne le maîtrise pas... donc vous avez certainement raison

Mais pour la modélisation j'assume complétement, j'ai l'habitude des modèles de données et c'est la première fois que je me retrouve confrontée à cette situation: l'outil utilisé ne traite pas correctement les tables liées sur les fiches d'informations, du moins pas comme le souhaite l'utilisateur. Voilà pourquoi mm si c'est complétement incorrect j'adapte mon modèle à l'outil (et non pas l'inverse) car le plus important reste l'utilisateur final. A condition que derrière je continue à assurer l'intégrité des données.
Je vais évidemment faire remonter ce besoin, qui pourrait se représenter, à l'éditeur de notre outil, mais il n'est pas dit que ce soit pris en compte, ni bientôt, ni même un jour...

En attendant je vous remercie pour votre piste concernant les déclencheurs LMD, je vais m'y pencher sérieusement et reviendrai par ici pour faire un point sur mon sujet

Bonne soirée

[SQLpro]

Le serpent qui se mord la queue !
Y a pas de solution propre (à mon avis) à ton problème car si tu UPDATE ta table cela active le déclencheur qui UPDATE ta même table et qui se ré-enclenche, etc...

Solution bis, stocké les mises à jour effectuées dans la journée et les répercuter via un traitement de nuit...

Cela fait partie des limites propres à Oracle (et du célèbre message d'erreur de la "table mutante..." ) ... Sur un bon SGBDR comme SQL Server, il est parfaitement permis de mettre à jour à nouveau la table cible d'un UPDATE. Les conditions de réentrance étant définies :

• au niveau de la récursivité pure, par le paramètre SET RECURSIVE_TRIGGERS dans la base
• au niveau du bouclage (triggers imbriqués), par le paramètre NESTED TRIGGERS dans l'étendue des objets du serveur, car dans ce dernier cas rien n'empêche de faire du "pingpong" entre deux tables de différentes bases d'un même serveur; En effet, contrairement à Oracle, SQL Server est multibase et naturellement optimisé pour ce faire.

A +

[pachot]

Sur un bon SGBDR comme SQL Server

Ce n'est pas une question de 'bon' ou de 'pas bon', mais une conséquence du fait de lire des données consistantes sans vérouiller les tables (MVCC).

[SQLpro]

Ce n'est pas une question de 'bon' ou de 'pas bon', mais une conséquence du fait de lire des données consistantes sans vérouiller les tables (MVCC).

Il est dommage de constater que Oracle en est resté au verrouillage optimiste seulement, alors que SQL Server permet les deux !
C'est pourquoi je parlais de Bon SGBDR, c'est à dire un SGBDR qui sait faire ce que la norme SQL impose (verrouillage pessimiste - ce n'est pas le cas d'Oracle si je ne m'abuse...) et en sus du verrouillage optimise...

Et sous SQL Server, MVCC ou pas, le comportement est le même en ce qui concerne la possibilité d'UPDATE de la table cible dans le trigger ! Donc cette double limitation est plus que navrante chez Oracle...

A +

[ceuce]

Le rendu souhaité n'a rien à voir avec les tables. Pour le rendu il existe des objets appelés vues et d'autres appelées procécures stockées... Peut être feriez vous bien de vous tenir au courant des nouveautés datant des normes SQL de 1983/1992 !

Bien entendu je confirme les propos de Pomalaix. C'est parfaitement imbécile de persévérer dans ce genre d'erreur de modélisation alors que la solution est évidente, simplissime et performante !

Merci à tous de vos réponses qui sont intéressantes, mais merci également à vous de ne pas être trop désagréables concernant mes lacunes, c'est aussi pour ça que je suis sur ce forum...
Effectivement je ne suis pas aussi spécialiste que vous, mais je suis prête à apprendre de tous bons conseils que je pourrai recevoir. Je note donc tout ça et vais voir si mon outil permet l'exploitation de vues

Ceuce

[SQLpro]

...Alors oui je sais, ce n'est pas du tout correct modélisationnellement parlant
On devrait avoir une table Structure qui contient l'adresse, liée à la table Accueil qui elle même accueillerait le champ code_structure comme clé étrangère
Seulement voilà, vis à vis de l'outil qui exploite mes données et selon le rendu souhaité par les utilisateurs je n'ai pas vraiment le choix... alors pouvez-vous m'aidez quand même?

Le rendu souhaité n'a rien à voir avec les tables. Pour le rendu il existe des objets appelés vues et d'autres appelées procécures stockées... Peut être feriez vous bien de vous tenir au courant des nouveautés datant des normes SQL de 1983/1992 !

Bien entendu je confirme les propos de Pomalaix. C'est parfaitement imbécile de persévérer dans ce genre d'erreur de modélisation alors que la solution est évidente, simplissime et performante !

A +