销售订单的一次提交失败了，前台显示保存未成功，后台却留下了一条待处理记录。业务人员再次提交，系统又提示重复。此时我们最想要的，似乎是一碗孟婆汤，让失败记录忘掉刚才发生的事，让订单重新活过来。
不过，得先弄清《仙剑奇侠传 1》里的道具效果。孟婆汤的游戏作用是让倒下的角色复活，并恢复一定体力，常见道具资料记载为恢复约一半体力。名字中的孟婆容易使人联想到失忆，但游戏机制的重点是复活，而不是让角色删除记忆。拿它类比企业系统时，更贴切的问题也不是 ABAP 有没有删除记忆的指令，而是一个失败、终止或被撤销的业务对象，能否在保留必要历史的前提下重新进入可处理状态。
ABAP 没有名叫孟婆汤的通用功能。它有几种作用范围完全不同的能力，未提交的修改可以回滚，运行时的临时数据可以清除，已经提交的业务对象可以通过业务规则重新激活，数据库在特定条件下也能够恢复到过去的时间点。它们看上去都带有「回到过去」的味道，实际处理的对象、代价和权限却相差很远。若把这些操作当成同一瓶药，轻则留下难查的重复数据，重则抹掉其他业务的正常交易。
先看最接近「倒下后还没彻底退场」的情形。ABAP 程序在一个事务中修改数据，尚未完成提交，就发现校验失败。我们可以用ROLLBACK WORK撤销当前事务中尚可回滚的数据库修改，以及相应的待提交工作。这里的「复活」是让系统回到这次提交之前的一致状态，允许业务修正输入并重试。它并没有把已完成的历史交易倒带，也不会替外部系统撤回已经收到的消息。
在经典 ABAP 中，SAP LUW和底层数据库事务的边界需要认真区分。一个业务操作可能跨越多个对话步骤，更新请求也可能在COMMIT WORK后
