SQL Server：更新大号时发出警报。行数
今天我搞砸了公司网站上最重要的表格。我忘记在更新语句后添加 where 子句，并且所有用户的登录名都已更改。大约13,000。
SQL Server 或 SQL Server Management Studio 中是否有一种方法可以在更新或删除（例如超过 10 行）时发出警报？
Today I f*ed up the most important table on my company's website. I forgot to add the where clause after an update statement and the login for all the users were changed. About 13,000 to be aprrox.
Is there a way in SQL Server or SQL Server Management Studio to give an alert if an update or delete is made for say, more than 10 rows?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一种稍有不同的方法，但如果您希望收到关于您正在使用生产服务器这一事实的提醒，SSMS 工具Pack（SSMS 的免费插件）有一个名为“窗口连接着色”的漂亮功能。
您将使用的每个 SQL Server 与一种颜色相关联，并且每个查询窗口的顶部都有一个相应的彩色条。我所有的生产服务器都是红色的；开发者是绿色的；和测试/分期是橙色的。当我需要小心时，这对我来说总是很明显。
此外，默认情况下，每个新查询窗口都会使用
BEGIN TRAN/ROLLBACK语句打开，因此您记得首先测试可能具有破坏性的查询。注意我对该软件没有商业兴趣，但我发现它非常有用。
This is a slightly different approach, but if you want to be alerted to the fact that you're using a production server, SSMS Tools Pack (a free add-in for SSMS) has a nifty feature called Window Connection Colouring.
You associate each SQL Server you use with a colour, and each query window has a corresponding coloured bar at the top. All my production servers are red; dev are green; and test/staging are orange. It's always quite apparent to me when I need to be careful.
Also, by default, every new query window opens with a
BEGIN TRAN/ROLLBACKstatement so you remember to test potentially damaging queries first.Note I have no commercial interest in the software, but I have found it very useful.
您可以添加一个更新触发器，当插入的表的行数超过 X 时，该触发器会失败，但稍后如果您确实想要进行更改，则需要禁用/重新启用触发器（不难，但很烦人 - 这我想这就是你所追求的）。
但是，是的，如果您手动执行操作，则它们应该处于开始传输/回滚事务中，并在最后进行选择以验证您在做什么，并且只有在您对此感到满意之后才提交它。 （我们可能都可以告诉你至少一个案例，我们认为我们对此感到满意，但仍然错误地犯了 - 哈哈）。
You could add an on update trigger that fails when the inserted table has above X number of rows, though then later if you really did want to make the change you'll need to disable/renable the trigger (not hard, but annoying - which is what you're after, I suppose).
But yes, if you're doing things manually they should be in a begin tran / rollback transaction with a select at the end to verify what you were doing, and only after you're happy with it then commit it. (We can probably all tell you of at least one case where we thought we were happy with it and still committed it incorrectly, though - haha).