Discussion :

[edmotets]

Mon problème à résoudre:
Table A:
colones a,b,c,d
Table B:
colones e,b,g,h

Résultats souhaités :
Table B:
colones e,f,g,h,d

Comme vous le constatez les deux tables ont pour commun la colonne b que je peux utiliser comme clef pour la jointure.

Le travail demandé c'est de "updater" la table B avec la colonne d de la table A. Compris d'une autre facon c'est d'ajouter la colonne d de la table A a la table B.

Bien évidement j'ai commencé par créer la colonne "d" sur la table B, maintenant il me reste à insérer les éléments de "d" de la table A dans la colonne d de la table B.

J'ai essayé d'ecrire ceci :

Code :

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

1
2
3
4
5
6
7
update ...dbo.B
set B.d = (
              select 
                     d
               from ...dbo.A 
               where A.b=B.b
            )

J'obtiens l'erreur suivante :

Msg 512, Level 16, State 1, Line 1
Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression.
The statement has been terminated.

En fait l'erreur retournée était prévisible car je pense bien que j'essaie d’insérer le résultat de mon select (plusieurs lignes retournées) dans une seule ligne ce qui n'est pas possible.
Dois-je utiliser un curseur ? Ou bien existe il une methode sans curseur. Si oui priere d’écrire l'esquisse de la procédure que se soit avec ou sans curseur.

Je vous serai reconnaissant de recevoir de l'aide car mon stage en dépend.

Merci bien.

[fsmrel]

Bonjour edmotets,


Essayez d’être rigoureux. Dans sa 2e version, l’en-tête de votre table B est doté d’une colonne f dont on se demande ce qu’elle vient faire là. Plus important, définissez précisément les clés primaires de vos tables. Si la table B doit comporter le même nombre de lignes avant et après update, alors la colonne b utilisée pour la jointure devrait être clé.

Pour voir à quoi ressemblera le contenu de la table B, créez une table C ayant la même structure d'en-tête (e, b, g, h, d) et valorisée en exécutant la requête :

Code SQL :

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

1
2
3
INSERT INTO C (e, b, g, h, d) 
       SELECT B.e, B.g, B.g, B.h, A.d
       FROM   B JOIN A ON B.b = A.b ;

Maintenant, un DISTINCT pourra peut-être vous aider :

Code SQL :

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

1
2
3
INSERT INTO C (e, b, g, h, d) 
       SELECT DISTINCT B.e, B.g, B.g, B.h, A.d
       FROM   B JOIN A ON B.b = A.b ;

Même chose en ce qui concerne votre UPDATE (s’il survit en l’état) quand le résultat de l’insert sera conforme à ce que vous attendez :

Code SQL :

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

1
2
3
4
UPDATE B
       SET d = (SELECT DISTINCT d 
               FROM   A
               WHERE  A.b = B.b) ;

Et surtout, définissez très précisément les clés primaires de vos tables.

[edmotets]

fsmrel, merci de me repondre.
Je vous mettrai au courant du resultat apres implementation.

edmotets

[elsuket]

Bonjour,

Typiquement l'UPDATE aurait pu s'écrire :

Code :

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

1
2
3
4
5
UPDATE		dbo.B
SET		d = A.d
FROM		dbo.B AS B
INNER JOIN	dbo.A AS A
			ON A.b = B.b

Cela étant s'il existe plusieurs valeurs de d pour le même b, vous êtes obligé d'utiliser la clause DISTINCT, qui, rappelons-le, n'est pas ensembliste.
D'autre part le DISTINCT ne vous garantit en rien que les valeurs de b retournées pour un d sont uniques au sein de ce "groupe".

Dois-je utiliser un curseur ? Ou bien existe il une methode sans curseur. Si oui priere d’écrire l'esquisse de la procédure que se soit avec ou sans curseur.

Par pitié, bannissez les curseurs !
D'autre part il n'y a aucunement besoin de curseurs dans votre cas, ni lorsque la base de données est proprement modélisée, et que le modèle répond au problème à résoudre.

@++

[fsmrel]

Bonsoir,

s'il existe plusieurs valeurs de d pour le même b, vous êtes obligé d'utiliser la clause DISTINCT, qui, rappelons-le, n'est pas ensembliste.

Le rôle de DISTINCT n’est pas « d’être » ensembliste, mais de pallier le laxisme de SQL qui permet — hélas ! — d’opérer sur des sacs (bags) : en codant DISTINCT, nous demandons au coupable SQL de bien vouloir éliminer les doublons, ce qui nous permet au moins de manipuler des ensembles plutôt que de la dynamite.

[elsuket]

Bonjour fmsrel,

Je ne comprend pas pourquoi tu dis que SQL est laxiste en ce qui concerne le DISTINCT, même si j'ai compris l'erreur de mon expression.

Dans l'hypothèse où le modèle de données est correct et qu'il répond précisément au problème à résoudre, il n'est à mon sens pas nécessaire dans le cas qu'expose edmotets d'utiliser la clause DISTINCT.

Malheureusement je constante bien souvent que DISTINCT est utilisé à tors et à travers pour "palier" à des erreurs de conception ...

@++