Navicat提交数据时触发器需用集合操作处理多行、用THROW报错确保界面提示、禁用服务端游标以防绕过、校验类触发器只检查不修改以避免死锁。
SQL Server触发器里怎么拿到Navicat提交的原始字段值
navicat本身不传特殊标识，触发器看到的就是inserted和deleted里的值——但关键在于：navicat默认用set nocount on，且批量操作可能一次提交多行。如果你在触发器里写select @val = column_name from inserted，遇到多行插入就会报错subquery returned more than 1 value。
- 必须用集合思维处理：
EXISTS、NOT EXISTS或游标（仅极少数需逐行逻辑时） - 避免
SELECT @var = col FROM INSERTED这种单值赋值写法 - Navicat执行“表数据编辑”时，每点一次保存可能发一条
UPDATE，也可能合并为BATCH，取决于设置里的Commit batch size，默认是1
触发器中校验失败该用RAISERROR还是THROW
SQL Server 2012+ 推荐用THROW，它能原样返回错误号、状态、消息，Navicat能直接捕获并弹窗提示；而RAISERROR在自定义错误号50000+时虽可用，但错误严重级别设低了（比如10）会被Navicat静默吞掉，设高了（16+）又可能中断整个事务批次。
- 用
THROW 50001, '姓名不能为空', 1;，Navicat会显示红字错误框 - 别用
RAISERROR('xxx', 10, 1)——这个级别下Navicat不报错也不回滚 - 如果必须兼容SQL Server 2008，才退回到
RAISERROR+WITH LOG，但Navicat日志里才能看到，界面无反馈
Navicat改数据时触发器不生效？检查这三个地方
不是触发器写错了，而是Navicat根本没让它跑起来。最常见的是：你建的是AFTER UPDATE，但它用UPDATE ... WHERE CURRENT OF游标方式更新（某些旧版Navicat在“编辑网格”里修改后点保存时会这样），这种语句绕过普通DML触发器。
- 打开Navicat“工具 → 选项 → 数据库 → 执行命令”，确认
Use server-side cursors是关闭状态 - 检查触发器是否被禁用：
SELECT is_disabled FROM sys.triggers WHERE name = 'tr_check_user' - 确认表上没同时存在
INSTEAD OF触发器——它会拦截并替代AFTER，导致你的校验逻辑完全不执行
用触发器做配置数据验证，为什么建议只查不改
触发器里执行UPDATE或INSERT（比如自动补默认值、格式化时间）看似方便，但在Navicat批量编辑场景下极易引发死锁或递归触发。例如你AFTER INSERT里再UPDATE本表，SQL Server默认允许递归，但Navicat的事务隔离级别（通常是READ COMMITTED）会让第二次更新等锁，卡住界面。
- 校验类触发器只做两件事：检查 +
THROW报错 - 默认值、转换逻辑移到应用层或
DEFAULT约束 / 计算列 - 真要改数据，用
INSTEAD OF触发器，但必须手动重写整个INSERT/UPDATE语句，不能依赖INSERTED直接转发
触发器不是万能钩子，尤其面对Navicat这种会动态切换语句模式的客户端，边界比想象中窄——它只保证“你写的SQL进了引擎”，不保证“Navicat点保存就一定走你预设的路径”。
