周末结算结束后，财务团队发现一批尚未付款的供应商发票使用了旧的风险分类。受影响的单据分布在多个公司代码，数量可能达到数万条。业务希望在下一个付款周期开始前完成修正，但已经付款、正在审批以及被人工锁定的单据都不能碰。这类任务很像《仙剑奇侠传》中赵灵儿的地裂天崩。它面对的不是单个目标，而是一片区域。真正困难的地方也不是让地面震动，而是确定震动范围，让该改变的地方一起改变，让范围之外的业务保持完整。**ABAP 没有名为地裂天崩的语法或框架功能。**与这招最接近的，是面向一批业务对象执行有条件的变更，并把筛选、校验、事务、日志和恢复组织成一次受控操作。在经典 ABAP、SAP BTP 的 ABAP 环境以及 SAP HANA 上，这件事有不同的实现路径。选择哪一条，取决于数据属于谁、业务规则在哪里执行，以及一次失败应当影响多大范围。地裂天崩的「地」，可以理解为满足条件的业务数据集合。它的「裂」，是状态或字段发生变化。它的「天崩」，则提醒我们注意波及面。一条没有经过充分约束的批量语句，确实可能在极短时间内修改大量记录，但运行得快并不等于业务结果正确。SAP HANA 的UPDATE语句如果缺少WHERE条件，作用范围就是目标表中的全部记录。对业务表而言，这样的威力没有任何值得欣赏的地方。拿前面的发票场景来说，我们不能只写「把风险分类改为新值」。范围至少要回答几个问题。哪些公司代码属于本次修正，发票的创建日期落在哪个区间，当前风险分类必须是什么，付款状态是否仍允许修改，审批中的记录如何处理。如果预估有三万条，实际筛选出了三十万条，程序应该在变更发生前停下来，而不是把超出的二十七万条当成意外收获。这里有一层很重要的区分。数据库表记录