求助：Update语句抵达SQL Server但未更新bit类型RowStatus且无报错

这种情况我之前碰到过好几次，结合你描述的细节——语句能抵达SQL Server、插入操作正常、用主键定位更新bit类型字段，咱们一步步拆解可能的问题和排查方向：

1. 先手动验证捕获到的Update语句 #

既然SQL Profiler已经抓到了完整的Update语句，直接复制到SSMS里，把参数替换成应用实际传递的值执行，重点看两个结果：

• 是否返回**(0 行受影响)**？如果是这样，大概率是主键值不匹配——虽然你说用PK定位，但可能存在隐性问题：比如应用传递的PK是字符串类型（比如"123"），而数据库PK是int，看似能隐式转换，但如果PK值是带前导零的字符串？或者数据库是大小写敏感的排序规则，PK为字符串类型时应用传的大小写和库里的不一致？
• 执行时有没有触发隐藏的错误？比如表上存在触发器？如果触发器里的逻辑悄悄回滚了更新（比如用了ROLLBACK但没抛出异常），或者触发器本身执行出错但被TRY...CATCH吞了，都会导致更新没生效，还不返回错误。

2. 检查事务与锁的状态 #

• 应用代码里是不是开启了事务，但没提交？比如执行Update后，因为分支逻辑问题走了Rollback，或者事务超时自动回滚了？可以用SQL Server的sys.dm_tran_active_transactions视图查看当前活跃事务，或者用sp_who2看看有没有阻塞的进程。
• 目标行是不是被其他会话锁定了？如果有其他进程持有该行的排他锁，你的Update会一直等待，要是应用没设置超时时间，就会一直挂着，看起来像没执行，也不会返回异常。

3. 确认RowStatus字段的约束与参数传递 #

• 虽然是bit类型，有没有检查约束？比如是否设置了CHECK (RowStatus IN (0,1))？不过你是从1改到0，理论上符合，但还是确认下约束有没有意外限制。
• 应用端的参数是不是真的传对了？比如会不会代码里把RowStatus设成了NULL而不是0？或者参数根本没绑定到SQL语句里？有些ORM框架如果参数赋值错误，会导致Update语句里的字段值不对，甚至静默忽略更新。

4. 排查应用端的异常处理与代码逻辑 #

• 检查应用的异常捕获：是不是用了try...catch但catch块里啥都没做？比如只吞了异常不输出日志，导致看起来没返回异常，但实际SQL Server已经抛出错误了。
• 确认Update方法的逻辑：有没有可能代码里把更新值写反了（比如设成1而不是0）？或者执行Update后没调用提交事务的方法？

5. 查看SQL Server错误日志 #

有些时候，SQL Server执行语句的错误不会直接返回给应用，但会记录在错误日志里。你可以去SQL Server的“管理”→“SQL Server日志”里看看，有没有和这个Update相关的错误，比如权限问题（虽然插入正常，但也不排除Update权限被单独限制的情况）。

举个实际操作的例子：如果Profiler抓到的语句是：

UPDATE Customer SET RowStatus = 0 WHERE CustomerID = @CustID

你把@CustID换成应用传递的实际值（比如1001），在SSMS里执行。如果执行后显示“(1 行受影响)”，那问题肯定在应用端的事务或代码逻辑；如果是“(0 行受影响)”，那就是PK值不匹配的问题，得去查应用传递的PK和数据库里的实际值是否一致。

内容的提问来源于stack exchange，提问作者perpetual_noob