sqlserver 中创建触发器execute master有啥作用

Posted 2023-05-07

参考技术A after等价于for，是事后触发。instead of则会取代原来的操作，例如在你的例子里，将不再执行插入操作，而是执行触发器里的操作。

execute as是用来定义模块的执行上下文
EXECUTE AS CALLER | SELF | OWNER | 'user_name'
其中CALLER指模块调用方，SELF指创建或更改模块的用户，OWNER指模块的当前所有者， ‘user_name’ 则是指定的用户。 参考技术B 触发器是一种特殊类型的存储过程，对特定事件作出相应。触发器有两种类型：数据定义语言(DDL)触发器和数据操纵语言(DML)触发器。
　　DDL触发器在用户以某些方式(CREATE、ALTER、DROP或相似的语句)对数据库结构进行修改时激活作出响应。一般来说，只会在对数据库结构的改变或历史进行极为严格的审计时才会用到DDL触发器。
　　DML触发器是一些附加在特定表或视图上的代码片段。与需要显式调用代码的存储过程不同，只要有附加触发器的时间在表中发生，触发器中的代码就会自动运行。实际上也不能显式地调用触发器-唯一的做法是在指定的表中执行所需的操作。
　　除了不能够显式地调用触发器，还可在存储过程中发现另外两个触发器所没有的内容：参数和返回码。
　　可将触发器附加到什么事件呢？因为在SQL中可以使用3类动作查询，所以就有3种类型的触发器，另外加上混合搭配这些时间并对时间定时激活的混合触发器类型。
INSERT触发器
DELETE触发器
UPDATE触发器
以后任意类型的混合
　　注意：
　　值得注意的是，有时即使执行的动作是前面这些类型中的一种，触发器也不会激活。问题在于进行的操作是否在记录的活动中。例如，DELETE语句是一个正常的记录活动，它会激活任何删除触发器，而TRUNCATE TABLE也有删除行的作用，但只是把表使用的空间释放而已-没有记录单个行删除操作，所以没有激活任何触发器。批量操作默认情况下不激活触发器，需要显式告知批量操作激活触发器。
　　创建触发器的语法：
　　CREATE TRIGGER <trigger name>
　　ON [ <schema name>. ]<table or view name>
　　[WITH ENCRYPTION | EXECUTE AS <CALLER | SELF | <user> > ]
　　 FOR | AFTER < [DELETE][,][INSERT][,][UPDATE] > | INSTEAD OF [WITH APPEND][NOT FOR REPLICATION]
　　AS
　　< <sql statements> | EXTERNAL NAME <assembly method specifier> >

　　ON子句用来之处触发器将要附加的表，以及在何时何种情况下激活这个触发器。
　　1、ON子句
　　这部分只是对创建触发器所针对的对象进行命名。记住，如果触发器的类型是AFTER触发器(使用FOR或AFTER来声明触发器)，那么ON子句的目标就必须是一个表-AFTER触发器不支持视图。
　　2、WITH ENCRYPTION选项
　　加密触发器。如果添加了这个选项，则可以确保没有人能够查看你的代码(甚至是你自己)。和视图与存储过程一样，使用WITH ENCRYPTION选项需要记住的是，每次在触发器上使用ALTER语句时都必须重新应用该选项，如果使用ALTER STATEMENT语句但不包含WITH ENCRYPTION选项，那么触发器就不再被加密。
　　3、FOR|AFTER子句与INSTEAD OF子句
　　除了要确定激活触发器(INSERT、UPDATE、DELETE)的查询类型以外，还要对触发器的激活时间做出选择。虽然人们经常考虑使用FOR触发器，但是也可以使用INSTEAD OF触发器。对着两个触发器的选择将会影响到是在修改数据之前还是之后进入触发器。FOR和AFTER的意义是一样的。
　　FOR|AFTER
　　FOR(或者AFTER)子句表明了期望触发器在何种动作类型下激活。当有INSERT、UPDATE或DELETE或三者混合操作时，都可以激活触发器。
　　FOR INSERT,DELETE
　　--或者是：
　　FOR UPDATE,INSERT
　　--或者是：
　　FOR DELETE

　　1、INSERT触发器
　　当有人向表中插入新的一行时，被标记为FOR INSERT的触发器的代码就会执行。对于插入的每一行来说，SQL Server会创建一个新行的副本并把该副本插入到一个特殊的表中，该表只在触发器的作用域内存在,该表被称为Inserted表。特别需要注意的是，Inserted表只在触发器激活时存在。在触发器开启之前或完成之后，都要认为该表示不存在的。
　　2、DELETE触发器
　　它和INSERT触发器的工作方式相同，只是Inserted表示空的(毕竟是进行删除而非插入，所以对于Inserted表示没有记录)。相反，每个被删除的记录的副本将会插入到另一个表中，该表称为Deleted表，和Inserted表类似，该表只存在于触发器激活的时间内。
　　3、UPDATE触发器
　　除了有一点改变以外，UPDATE触发器和前面的触发器是很类似的。对表中现有的记录进行修改时，都会激活被声明FOR UPDATE的触发器的代码。唯一的改变是没有UPDATE表。SQL Server认为每一行好像删除了现有记录，并插入了全新的记录。声明为FOR UPDATE的触发器并不是只包含一个表，而是两个特殊的表，称为Inserted表和Deleted表。当然，这两个表的行数是完全相同。
　　4、WITH APPEND选项
　　WITH APPEND选项并不常用，老实讲，用到它的可能性很小；WITH APPEND选项只能应用于6.5兼容模式中。
　　如果已经声明了一个称为trgCheck的触发器在更新和插入时强制执行数据完整性，那么就不能创建另一个触发器来进行级联更新。一旦创建了更新(或插入、删除)触发器，那么就不能创建另一个同一动作类型的触发器。为解决这个问题，WITH APPEND子句显式地告诉SQL Server，即使在表上已经有了这种类型的触发器，还可以添加一个新的触发器。当有合适的触发动作(INSERT、UPDATE、DELETE)发生时，会同时激活两个触发器。
　　5、NOT FOR REPLICATION选项
　　如果添加了该选项，会稍微地改变关于何时激活触发器的规则。在适当的位置使用这个选项，无论与复制相关的任务何时修改表，都不会激活触发器。通常，当修改了原始表，并且不会再进行修改的时候会激活触发器(进行内务处理或级联等操作)。
　　6、AS子句
　　和在存储过程中的使用完全相同，这正是触发器的实质所在。AS关键字告诉SQL Server，代码将要启动。

附上出处链接：http://www.cnblogs.com/kissdodog/p/3173421.html

确定用户在 SQL Server 中创建的对象

【中文标题】确定用户在 SQL Server 中创建的对象

【英文标题】：Determine what user created objects in SQL Server

【发布时间】：2009-08-10 16:45:20

【问题描述】：

我现在正在尝试检查我们的开发数据库并清理一些旧的测试过程/表。是否可以确定用户在 SQL Server 2005 数据库中创建的对象？如果是这样，我将如何查找这些信息？

编辑：只是想澄清有问题的对象已经存在。设置审计和触发器可能对我没有多大好处。我想我主要是在寻找一种使用系统表/视图来获取信息的方法。

【参考方案1】：

如果对象是最近创建的，您可以在 SQL Server Management Studio 中查看“架构更改历史记录”报告，该报告“提供了默认跟踪记录的数据库中所有已提交 DDL 语句执行的历史记录”：

然后您可以搜索对象的创建语句。在显示的所有信息中，有执行DDL语句的登录名。

【参考方案2】：

答案是“不，你可能不能”。

虽然其中有些东西可能会说明谁创建了给定对象，但它们背后有很多“如果”。快速（不一定是完整的）审查：

sys.objects（因此 sys.tables、sys.procedures、sys.views 等）具有列 principal_id。该值是与数据库用户列表相关的外键，而该列表又可以与 SQL（实例）登录列表连接。 （所有这些信息都可以在进一步的系统视图中找到。）

但是。

在此处快速检查我们的设置并粗略查看 BOL 表明该值仅在“与架构所有者不同”时才设置（即不为空）。在我们的开发系统中，我们有 dbo + 其他两个模式，所有内容都显示为 NULL。这可能是因为每个人都在这些数据库中拥有 dbo 权限。

这是使用 NT 身份验证。 SQL 身份验证的工作方式可能大致相同。另外，每个人都有并使用唯一的登录名，还是共享的？如果您有员工流动率并且域（或 SQL）登录被丢弃，那么数据可能不存在或可能不完整。

您可以查看此数据（从 sys.objects 中选择 *），但如果 principal_id 为空，您可能不走运。

【参考方案3】：

如果每个用户都有自己的 SQL Server 登录名，您可以试试这个

select 
    so.name, su.name, so.crdate 
from 
    sysobjects so 
join 
    sysusers su on so.uid = su.uid  
order by 
    so.crdate

【讨论】：

但看起来so.uid确实是非导入dbs的SchemaId：msdn.microsoft.com/en-us/library/ms177596.aspx

对我来说，它给了我角色名称而不是实际用户。 @Guillermo Gutiérrez 的报告给出了实际的用户名。

【参考方案4】：

如果需要小而具体的机制，可以搜索DLL Triggersinfo。