有两张表:
用一个report测试,表1是直接online update,表2在update function module里update,由于有了SET UPDATE TASK LOCAL的keyword,使得function module ZINSERT_TABLE2 也在当前work process内执行。
data: ls_jerry1 type ZJERRYTABLE1,
ls_jerry2 type ZJERRYTABLE2.
ls_jerry1-client = sy-mandt.
ls_jerry1-inumber = 'i042416'.
ls_jerry1-name = 'WANGJER'.
insert ZJERRYTABLE1 FROM ls_jerry1.
CALL FUNCTION 'ZINSERT_TABLE2' IN UPDATE TASK.
SET UPDATE TASK LOCAL.
COMMIT WORK AND WAIT.
function module内只是一个很简单的assert语句用于模拟update function module出错的情况:
F8执行report,收到期望中的update function module执行出错的提示:
但是SE16 里table1里检查table1 已经有一条entry成功插入了:
再来模拟table1 update不成功,但是table2 update成功的scenario. 将update function module改成update table2:
report 仍然保持不变,这样table1的update会由于duplicate key而失败。
report执行完之后,table1仍然只有1条数据,但是table2已经insert成功了。
究其原因,在这个例子里,table1和table2的update并不是放在同一个SAP LUW里的。这行ABAP OPEN SQL insert 语句(insert ZJERRYTABLE1 FROM ls_jerry1.), 什么时候会真正地把数据写到database server里?当遇到显式的database commit( COMMIT WORK ), 或者隐式的database 操作时,表1的操作就会立即写到database里,而与表2无关。 关于这两种不同的database commit方式,可以查看ABAP help: