SQL Server 2008 在连接表中使用 Join 和Where 子句更新查询
不知道为什么这不起作用:
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)
用简单的英语来说,我试图将 isUnsubscribed
字段设置为取消订阅,其中 UserSetting
表中的 userID
等于用户表中的userID
,并且用户表中的emailAddress
不在另一个表的电子邮件列表中。我可以使用几乎相同的语法在 isUnsubbed 列上运行选择,并且它工作正常吗?谢谢!
PS 我在这里查看了其他类似的问题,语法看起来相同,但显然我遗漏了一些东西。
Not sure why this is not working:
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)
In plain English, I am trying to set the isUnsubscribed
field to unsubscribed where the userID
in the UserSetting
table equals the userID
in the user table and where the emailAddress
in the user table is not in a list of emails from another table. I can run a select on the isUnsubbed column using pretty much the same syntax and it works fine? thanks!
P.S. I've looked at other similar questions here and the syntax appears the same but obviously I'm missing something.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
是的,你忽略了一些事情。
set 语句不能引用集合左侧的别名。
尝试:
我添加了注释掉的选择,以便您可以检查是否获得了您想要的结果集。
Yep you've overlooked something.
The set statement cannot reference the alias on the left side of the set.
Try:
I added the commented out select so you can check to see that you aregetting results set you wanted.
尽管 UPDATE...FROM 语法在某些情况下至关重要,但我更喜欢尽可能使用子查询。这能满足您的需要吗?
Although the UPDATE...FROM syntax is essential in some circumstances, I prefer to use subqueries whenever possible. Does this do what you need?
试试这个:
Try this :
尝试:
Try:
注意:仅供记录(假设其他一切都正常工作),您还可以在
BadEmailAddresses
表上执行内部联接。如果您遇到任何性能问题,那么您可能需要为两个表中的
emailAddress
列建立索引。Note: Just for the record (assuming you get everything else to work), you could also do an inner join on the
BadEmailAddresses
table.If you have any performance problems, then you might want to index the
emailAddress
column in both tables.