Discussion :

[emmr.rida]

Salut,
ça fait des jours que je cherche une solution pour remplir une colonne d'une table DevisList.TTC à partir du résultat d'une requête SELECT qui retourne plusieurs lignes. La solution que j'ai trouvé qui n'affiche pas un message d'erreur est la suivante mais ne fait rien car je reçois le message (0 lignes affectés)!

Code :

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

1
2
3
4
5
6
7
8
UPDATE DevisList
SET TTC = (
			SELECT SUM(Opération.Montant)
			FROM Devis, Opération, DevisLink
			WHERE Devis.ID = DevisLink.DevisID AND DevisLink.OpérationID = Opération.ID
			GROUP BY Devis.ID
)
WHERE DevisList.TTC = NULL

PS : Dans ma db j'ai une table Devis liée avec les Opération effectuées pour les clients à l'aide de recs d'une autre table DevisLink dont les champs (ID, DevisID et OpérationID).

Merci d'avance...

[SQLpro]

Que d'horreur dans ce code... Ou avez vous appris le SQL ? ... Avez vous appris à modéliser une base de données ???

Alors on commence :

1) les noms des objets SQL (table, colonne, procédures, vue, fonction, contraintes...) ne doivent comporter que des lettres sans accents ni caractères diacritiques ou des chiffres ou encore le blanc souligné. Tout autre caractères est formellement interdit. Néanmoins certains SGBDR permettent d'utiliser d'autres caractères au risque de rendre impossible l'interopérabilité aves les programmes clients. Exemple : table "Opération".
Lisez ce que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...age=partie1#L1

2) les jointures se font à l'aide de JOIN. Les jointures dans le WHERE sont une absurdité dont la syntaxe est obsolète depuis plus de 15 ans !
Lisez les articles que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/s...intures/#LII-B
http://blog.developpez.com/sqlpro?ti..._dans_le_from_
Voici comment devrait être récrite votre requête interne :

Code :

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

1
2
3
4
5
6
7
SELECT SUM(Opération.Montant)
FROM   Devis AS D
       INNER JOIN DevisLink AS DL
             ON D.ID = DL.DevisID
       INNER JOIN Operation AS O
             ON DL.OpérationID = On.ID
GROUP  BY D.ID

3) dans un système d'information, une information doit être référencée par un nom unique. Or dans votre table, l'information de clef de devis s'apelle ID dans la table devis et devis ID dans la table DevisLink, en effet ces colonnes sont censées contenir les même informations pour la mise en relation et devraient donc porter le même nom. Si vous aviez utilisé un outil de modélisation, ou encore que vous aviez pensé votre modèle au niveau conceptuel, cette faute stupide aurait été évitée. Ceci est d'autant plus navrant qu'il apparait que vous avez d'autres colonnes nommées ID dans d'autres tables et qui contiennent des données différentes !
Que se passera t-il le jour ou vous voudrez faire du NATURAL JOIN ??? Vous joindrez des carottes à des navets !

4) le prédicat :

WHERE DevisList.TTC = NULL

vous donnera toujours faux... Par principe un marqueur NULL ne peut être comparé. pouvez-vous comparer une couleur qui n'existe pas à une autre qui n'existe pas non plus ? Donc NULL = NULL donne toujours UNKNOWN et se comporte comme faux !
En revanche il existe des opérateurs spécialisés dans le traitement des marqueur NULL (NULL n'étant pas une valeur, mais justement l'ABSENCE DE VALEUR !).
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/null/

5) erreur d'affectation :
De plus ce prédicat WHERE, s'il marchait, fait en sorte que vous affectez à toutes les commandes dans lesquelles la colonne TTC est vide le même calcul, ce qui est absurde. il faut corréler la sous requête avec la table cible de l'ordre de mise à jour.

6) données calculées
En sus, il est totalement déconseillé de stocker les données calculées. Que ferez vous si une des données est modifiée ? Vous allez avoir stocké un calcul qui est faux !!!
Parmi les principes fondamentaux des SGBDR, la non redondance est la règle : l'information ne doit se situer qu'à un seul endroit dans la base et par conséquent, ne jamais stocker de données qui peuvent être calculées.
En revanche, si vous voulez "voir" votre calcul, rien de plus simple : il suffit de faire la requête et mieux, de l'encapsuler dans une vue (c'est fait pour cela les vues...).

Code :

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

1
2
3
4
5
6
7
8
9
CREATE VIEW V_Devis
AS
SELECT D.ID, SUM(Opération.Montant) AS TTC, ???
FROM   Devis AS D
       INNER JOIN DevisLink AS DL
             ON D.ID = DL.DevisID
       INNER JOIN Operation AS O
             ON DL.OpérationID = On.ID
GROUP  BY D.ID, ???

Ou ??? représente les autres colonnes de table Devis.

7) correction
enfin, si vous n'avez rien compris au SGBD relationnel et que vous voulez persister dans votre erreur, la requête correcte pour votre calcul redondant est la suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
UPDATE DevisList
SET TTC = SUM(O.Montant)
FROM   DevisList AS DLT
       INNER JOIN Devis AS D
             ON DLT.??? = D.???
       INNER JOIN DevisLink AS DL
             ON D.ID = DL.DevisID
       INNER JOIN Operation AS O
             ON DL.OpérationID = On.ID
GROUP  BY D.ID

Et comme pour couronner le tout, vous n'avez pas respecter la charte de postage de ce forum, il est impossible de vous fournir le code exact. Merci donc de la lire : http://www.developpez.net/forums/d96...vement-poster/
Et de la respecter intégralement pour vos futures demandes !

Je pense que vous avez besoin de vous former sur SQL et les concepts des bases de données relationnelles. Mes livres, comme mon site web, peuvent vous y aider...

A +