添加新列后执行UPDATE语句报错“Column name or number of supplied values does not match table definition”求助

Hey Joey，这种情况确实挺让人困惑的——明明你的UPDATE语句完全没碰那两个新列，怎么就突然报错了呢？我来分享几个实际工作里碰到过的类似问题的排查方向，你可以逐一试试：

• 先排查表上的触发器（Trigger）
  这是最常见的原因！很多时候我们会给业务表加自动同步、日志记录的触发器，比如当表有更新时，触发器会把数据插入到另一个历史表或者同步表里。如果你的CLAIMS表绑定了这类触发器，而触发器里的SQL逻辑还停留在旧表结构（比如INSERT语句用了固定的列列表，没包含新添加的DRAWING_FROM和VENUE_TYPE），就会触发这个列数不匹配的错误。
  你可以用这条SQL查一下表上的触发器：

  SELECT * FROM sys.triggers WHERE parent_id = OBJECT_ID('CLAIMS')
  

  如果找到触发器，点开看看里面的代码，是不是在INSERT/UPDATE操作里没适配新的表结构。

• 检查是否存在INSTEAD OF UPDATE触发器
  这种触发器会直接替代你写的UPDATE操作，完全接管数据更新的逻辑。如果触发器里的逻辑（比如构造的UPDATE语句或者关联的其他操作）没有跟上新列的添加，就会抛出这个错误。比如触发器里可能写了UPDATE SomeTable SET (...)但列数和实际表不匹配，或者插入数据到其他表时列数不对。

• 确认操作的是目标表，不是同名视图/同义词
  有没有可能你执行UPDATE时，实际操作的不是你修改过的那个CLAIMS表？比如数据库里有同名的视图或者同义词，指向的是另一个结构未更新的表？你可以用这条SQL确认：

  SELECT OBJECTPROPERTY(OBJECT_ID('CLAIMS'), 'IsTable')
  

  如果返回1说明是表，返回0的话可能是视图、同义词或者其他对象，这时候需要加上架构名（比如dbo.CLAIMS）来明确指定操作的表。

• 尝试清除查询缓存
  有时候数据库会缓存旧的表结构元数据，导致执行语句时用了过期的结构信息。你可以试试执行：

  DBCC FREEPROCCACHE
  

  清除查询缓存后再重新执行你的UPDATE语句，看是否能正常运行。

• 明确指定表的架构名
  试试把UPDATE语句改成带架构名的形式，比如：

  UPDATE dbo.CLAIMS SET LAST_UPDATED_DT = GETDATE() WHERE ID = 'id'
  

  有时候如果数据库里有多个架构，直接写表名可能会优先匹配到其他架构下的同名对象，导致结构不匹配。

如果排查完这些还是解决不了，可以告诉我你用的数据库类型（看起来像是SQL Server？因为你用了GETDATE()），以及触发器的排查结果，我再帮你进一步分析~

备注：内容来源于stack exchange，提问作者Joey