2010-09-20 28 views
4

Je ne sais pas pourquoi cela ne fonctionne pas:SQL Server 2008 Mise à jour requête avec JOIN et clause Where dans le tableau joint

UPDATE 
    ust 
SET 
    ust.isUnsubscribedFromSystemEmails = 1 
FROM   
    UserSetting AS ust 
INNER JOIN 
    [User] ON ust.userID = [User].userID 
AND 
    [User].emailAddress IN (SELECT emailAddress FROM BadEmailAddresses) 

Je suis En clair, en essayant de définir le champ isUnsubscribed à désabonné où le userID dans le UserSetting table correspond à userID dans la table utilisateur et où emailAddress dans la table utilisateur n'est pas dans une liste d'e-mails d'une autre table. Je peux lancer un select sur la colonne isUnsubbed en utilisant à peu près la même syntaxe et ça marche bien? Merci!

P.S. J'ai regardé d'autres questions similaires ici et la syntaxe semble la même mais évidemment, il me manque quelque chose.

+0

pourquoi cela ne fonctionne pas? avez-vous un message d'erreur (si oui, quel est le message?) ou vous n'avez pas les résultats attendus (si oui, quels sont les résultats obtenus?)? –

+0

Désolé bonne question! Il n'analyse pas la requête .. – toddm

+0

hit entrer par erreur. La colonne ou l'expression 'isUnsubscribedFromSystemEmails' ne peut pas être mise à jour. Les colonnes existent et est accessible en écriture .. aucune autorisation n'est émise .. et puis je reçois d'autres choses et le message d'erreur est: nom d'objet invalide 'ust'. La table UserSetting existe définitivement! Sélectionner en utilisant la même jointure et where dans la clause donne des résultats corrects – toddm

Répondre

1

Bien que UPDATE ... de la syntaxe est essentielle dans certaines circonstances, je préfère utiliser les sous-requêtes chaque fois que possible. Est-ce que cela fait ce dont vous avez besoin?

UPDATE UserSetting 
SET isUnsubscribedFromSystemEmails = 1 
WHERE userID in (SELECT userID from [User] 
       WHERE emailAddress in (SELECT emailAddress FROM BadEmailAddresses)) 
+0

cela fonctionne. Merci! Par la suite met à jour l'ensemble deux fois si .. mais à ce stade, je m'en fous. Merci! – toddm

10

Oui, vous avez oublié quelque chose.

L'instruction set ne peut pas référencer l'alias sur le côté gauche de l'ensemble.

Essayez:

UPDATE 
    ust 
SET 
    isUnsubscribedFromSystemEmails = 1 
--select * 
FROM   
    UserSetting AS ust 
INNER JOIN 
    [User] ON ust.userID = [User].userID 
WHERE [User].emailAddress IN (SELECT emailAddress FROM BadEmailAddresses) 

J'ai ajouté en commentaire sélection de sorte que vous pouvez vérifier que vous aregetting résultats que vous vouliez définir.

+0

"Impossible d'analyser la requête texte" Nom d'objet incorrect 'ust' – toddm

+0

select * DE UserSetting AS INSCRIPTION ust INNER [utilisateur] = ON ust.userID [Utilisateur] .UserID ET [Utilisateur]. emailAddress IN (SELECT emailAddress FROM BadEmailAddresses) fonctionne très bien au fait! renvoie les résultats attendus ?? – toddm

+0

Si la sélection a bien fonctionné, je suis à perte. Pourquoi ne pas vous donner quelques exemples de données provenant des paramètres utilisateur, User et bademailaddresses et nous pouvons tester contre les données que vous attendez d'avoir. – HLGEM

0

Essayez ceci:

UPDATE UserSetting ust SET usr.isUnsubscribedFromSystemEmails = 1 
WHERE ust.emailAdress IN (select emailAddress from bademailAddresses); 
+0

J'ai essayé ceci ... pour un la colonne isUnsubbed est dans la table ust .. même avec ce changement, la requête n'analyse pas. – toddm

0

Essayez:

UPDATE 
    UserSetting 
SET 
    isUnsubscribedFromSystemEmails = 1 
FROM   
    UserSetting 
INNER JOIN 
    [User] ON UserSetting.userID = [User].userID 
AND 
    [User].emailAddress IN (SELECT emailAddress FROM BadEmailAddresses) 
+0

Cela définit tous les enregistrements dans UserSetting.isUnsubscribedFromSystemEmails sur true – toddm

+0

Ainsi, chaque courrier électronique d'un seul utilisateur est incorrect? – HLGEM

0

Note: Pour le compte rendu (en supposant que vous obtenez tout le reste au travail), vous pouvez aussi faire une jointure sur la table BadEmailAddresses.

Si vous rencontrez des problèmes de performances, vous pouvez indexer la colonne emailAddress dans les deux tables.

+2

En fait, un 'INNER JOIN' est moins performant qu'une sous-requête lorsque la sous-requête est concise comme celle de la question. Une extension plus appropriée à ceci serait de tourner '[User]' dans une vue qui a exécuté la sous-requête dans la clause 'WHERE'. –