sql server 禁止 update 计算列，因其值由表达式自动推导；正确做法是更新其依赖的基础列，如 total as price * qty，则应 set price 和 qty，而非 total。
SQL Server UPDATE 不能修改计算列
SQL Server 明确禁止对计算列（computed column）执行 UPDATE 操作——这不是配置问题，而是引擎层硬性限制。当你在 SET 子句中显式列出计算列名（如 SET TotalAmount = 100），哪怕该列是持久化（PERSISTED）的，也会直接报错：Msg 271, Level 16, State 1, Line X: The column "TotalAmount" cannot be modified because it is either a computed column or is the result of a UNION operator.
计算列值由定义表达式自动推导，无法手动赋值
计算列的值完全由其定义中的表达式实时生成（例如 AS Price * Quantity），数据库不会为其分配独立存储空间（除非标记为 PERSISTED），更不接受外部写入。即使你绕过语法检查强行“更新”，SQL Server 也不会执行赋值动作，而是直接拒绝语句解析。
- 试图用
UPDATE ... SET ComputedCol = 'xxx'—— 立即失败，不进入执行阶段 - 在
WHERE条件中引用计算列（如WHERE ComputedCol > 100）—— 完全合法，且能走索引（若已建索引） - 通过触发器或视图间接“影响”计算列值 —— 实际是更新其依赖的基础列，计算列随之自动重算
真正要改的是基础列，不是计算列本身
如果你发现业务逻辑“需要更新计算列”，说明理解有偏差：你真正该更新的是参与计算的源列。比如表定义为：
CREATE TABLE Orders (
Price DECIMAL(10,2),
Qty INT,
Total AS Price * Qty PERSISTED
);
那么想让 Total 变为 500，正确做法是：
-
UPDATE Orders SET Price = 100, Qty = 5 WHERE OrderID = 123（改源字段） - 而不是
UPDATE Orders SET Total = 500 WHERE OrderID = 123（语法非法）
如果源列被 NOT NULL 或约束挡住，需先确认约束是否允许该变更，而非尝试绕过计算列限制。
容易被忽略的隐式陷阱：视图或链接服务器场景
在通过视图更新、或使用四部分命名（Server.DB.Schema.Table）跨实例更新时，SQL Server 有时会把底层计算列表达式误判为不可更新列，即使原表结构允许。此时错误信息可能不明确，建议：
- 先在目标库本地执行相同
UPDATE，确认是否报错 - 检查视图定义是否含
UNION、聚合函数、子查询——这些会让整个视图变为只读 - 避免在链接服务器查询中对计算列做
SET引用，改用直接更新基表
计算列的设计初衷就是“只读派生”，所有试图把它当普通列操作的思路，都会撞上这个边界。
