Maj par trigger [Résolu]

[RSI06]

Bonjour à tous et d'avance merci à eux qui pourront m'aider.
Je vous explique mon problème :
J'ai 2 tables :
- 1 table T_Fournissseurs
- 1 table T_Factures

La table T_Fournisseurs a 1 colonne "nb_factures"

Ma question est simple : comment puis-je compter le nombre total de facture pour un fournisseur donné au moment de la validation d'une nouvelle facture dans la table T_Facture ?

J'a voulu faire un trigger AFTER sur la table T_Factures
Extrait du code :

Code :

1
2
SELECT count(*) INTO nCount FROM T_Facture WHERE id_fournisseur = :old.id_fournisseur;
UPDATE T_Fournisseur SET nb_facture = nCount WHERE id_fournisseur = :old.id_fournisseur;

Mais j'ai l'erreur oracle de la table en mutation car je veux lire la table T_Factures qui vient d'être mise à jour alors que mon trigger est de type AFTER.

Je ne comprend pas.

Connaissez-vous une meilleur solution ?

Merci

[orafrance]

une recherche sur le forum devrait t'apporter des éléments, un sujet a été l'objet d'un long débat pas plus tard que la semaine dernière

PS : le code du trigger serait nettement plus intéressant avec les balises ad hoc

[olive-andre]

Utilise une procédure ou une fonction (tu pourras utiliser cette derniere dans une requète) qui se chargera
1) de l'insertion dans la table T_FACTURE
2) de la mise à jour du compteur dans la table T_FOURNISSEUR.

Sinon, tu peux aussi utiliser une vue sur la table T_FOURNISSEUR de ce type

Code :

1
2
3
4
5
6
7
CREATE OR REPLACE VIEW V_FOURNISSEUR AS 
SELECT 
    id_fournisseur AS id_fournisseur,
    (SELECT count(*) 
        FROM T_FACTURE FA 
        WHERE FA.id_fournisseur = FO.id_fournisseur) AS nb_facture
FROM T_FOURNISSEUR FO ;

Elle marche

[RSI06]

Merci de ta réponse olive-andré mais l'insert se fait via le navigateur WEB.

La vue ne m'apportera rien car la colonne nb_facture est sujet à des calculs à d'autres moments.

Merci

L'idée de la procédure est intéressante
Je vais y travailler

[McM]

Il suffit de gérer tous les cas

Code :

1
2
3
4
5
6
7
8
9
10
11
IF INSERTING
THEN
	UPDATE T_Fournisseur SET nb_facture = NVL(nb_facture,0) + 1 WHERE id_fournisseur = :NEW.id_fournisseur;
ELSIF DELETING
THEN
	UPDATE T_Fournisseur SET nb_facture = NVL(nb_facture,0) - 1 WHERE id_fournisseur = :OLD.id_fournisseur;
ELSIF UPDATING AND :OLD.id_fournisseur <> :NEW.id_fournisseur
THEN
	UPDATE T_Fournisseur SET nb_facture = NVL(nb_facture,0) - 1 WHERE id_fournisseur = :OLD.id_fournisseur;
	UPDATE T_Fournisseur SET nb_facture = NVL(nb_facture,0) + 1 WHERE id_fournisseur = :NEW.id_fournisseur;
END IF;

Edit c'est un trigger BEFORE INSERT OR UPDATE OR DELETE FOR EACH ROW

[olive-andre]

je ne sais pas ce que tu entends par

Envoyé par RSI06

La vue ne m'apportera rien car la colonne nb_facture est sujet à des calculs à d'autres moments.

mais, pourquoi dans le code de ton trigger tu ne calcules juste pas

Code :

UPDATE T_Fournisseur SET nb_facture = nCount WHERE id_fournisseur = :old.id_fournisseur;

penses aussi à soustraire les factures que tu détruits, etc....

[olive-andre]

Désolé, MCM a tiré plus vite que moi ....

[McM]

[RSI06]

Envoyé par McM

Il suffit de gérer tous les cas

Code :

Edit c'est un trigger BEFORE INSERT OR UPDATE OR DELETE FOR EACH ROW

Je vais tenter cette solution.
Je vous tiens au courant

[mnitu]

Je ne sais plus pourquoi mais il me semble qu’il faut ajouter aussi une contrainte sur la table facture. Mais j’ai du mal à me rappeler pourquoi

[Garuda]

Ma question est simple : comment puis-je compter le nombre total de facture pour un fournisseur donné au moment de la validation d'une nouvelle facture dans la table T_Facture ?

Si je puis me permettre, revenons à l'essentiel : est-ce besoin de stocker ce nombre ?
A voir pour les bidouilles à faire pour l'alimenter, on y fera Jamais confiance !!!
Et bonjour la dénormalisation.

Donc je rejoins olive_andre

Code :

1
2
 
Sinon, tu peux aussi utiliser une vue sur la TABLE T_FOURNISSEUR de ce type

Moi, dans ces cas la, je fais une fonction (relire les papiers de TOM KYTE et STEVE FEURSTEIN) !!!
Si j'en ai besoin dans un select, pas de pb ! Et le compteur est toujours à jour !

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
CREATE OR REPLACE FUNCTION nb_facture (p_four IN id_fournisseur%TYPE)
   RETURN NUMBER
IS
   n   NUMBER;
BEGIN
   SELECT COUNT (*)
     INTO n
     FROM t_facture
    WHERE id_fournisseur = p_four;
 
   RETURN NVL (n, 0);
END nb_facture;

Code :

SELECT id_fournisseur,nom_fournisseur,nb_factures(cod_four) FROM t_fournisseur

[McM]

Oui, mais bonjour le nb de lectures logiques dans certains cas.

[orafrance]

surtout une fonction dans une requête, c'est pas génial

[mnitu]

Envoyé par Garuda

Si je puis me permettre, revenons à l'essentiel : est-ce besoin de stocker ce nombre ?
A voir pour les bidouilles à faire pour l'alimenter, on y fera Jamais confiance !!!
Et bonjour la dénormalisation.

Donc je rejoins olive_andre

Code :

Moi, dans ces cas la, je fais une fonction (relire les papiers de TOM KYTE et STEVE FEURSTEIN) !!!
...

Bonjour,

Il est possible que l’application imposé le stockage du cumul. Moi je n’appel pas ça dénormalisation.
En plus Tom Kyte ne dit ce que vous dite . Il recommande l’utilisation d’une vue matérialisée avec le paramètre QUERY_REWRITE, mise en place du CBO de telle façon que la requête qui calcul le cumul sur la table de base se exécute en fait sur la vue matérialisé.

[RSI06]

La solution de MCM fonctionne parfaitement
Merci à tous

[McM]

Yeeesss...

[mnitu]

Sauf que j’arrive à obtenir ce message

Code :

1
2
3
4
5
6
7
8
 
SQL> UPDATE t_factures SET id_fournisseur = 1 WHERE id = 2;
UPDATE t_factures SET id_fournisseur = 1 WHERE id = 2
       *
ERREUR à la ligne 1 :
ORA-00060: Détection d'interblocage pendant l'attente d'une ressource
ORA-06512: à "MNI.BIUD", ligne 11
ORA-04088: erreur lors d'exécution du déclencheur 'MNI.BIUD'

et Oracle (Oracle 9i Database Concepts) dit que j’ai mal programmé

Avoid Deadlocks
Multitable deadlocks can usually be avoided if transactions accessing the same tables lock those tables in the same order, either through implicit or explicit locks. For example, all application developers might follow the rule that when both a master and detail table are updated, the master table is locked first and then the detail table. If such rules are properly designed and then followed in all applications, deadlocks are very unlikely to occur.
When you know you will require a sequence of locks for one transaction, consider acquiring the most exclusive (least compatible) lock first.

[olive-andre]

Envoyé par McM

Yeeesss...

--
je mets un -- car je n'ai pas été aussi précis que toi !
Oliv.