在应用程序里更新数据库

一，直接更新

如果是在屏幕程序里执行的数据库更新，你必须把所有的数据库更新动作绑在一起在一个屏幕（一般是最后一个屏幕）里进行处理。因为屏幕之间切换（分散在各个屏幕可能会造成数据的不一致性）时会触发隐式的数据提交动作，只有这样做才能保证数据库的改变符合all or nothing的原则。

 

如果是在应用程序中进行的数据库更新，程序要设置和解开锁。一般步骤：

1，锁定数据

2，读取数据

3，在数据库中更新数据

4，解开锁定的数据

 

虽然说程序退出的时候会自动解开程序设置的锁，但是对于更新数据库的程序，最好在程序中利用DEQUEUE_或者DEQUEUE_ALL来解锁。因为，数据库更新后，如果程序不自己解锁，用户又不退出程序，这些数据就会一直处于锁定状态，很可能会影响别人的操作。

 

二，利用延时的subroutine

屏幕程序里的数据库更新可以用特殊的subroutine PERFORM ON COMMIT来绑在一起，这些特殊的subroutine不会执行直到遇到下一个COMMIT WORK.这样的话，就可以在各个屏幕里来写不同的subroutine,在最后的屏幕里写COMMIT WORK,这样也保证这些subroutine里的数据库更新会在一个SAP LUW的结尾打包来执行。

 

每个用PERFORM ON COMMIT（POC）形式的subroutine在一个SAP LUW只会执行一次，但是你可以多次调用它，不会报错的。例如：

loop at itab.

     perform f1 on commit.

endloop.

这个例子中，f1虽然在一个LOOP中，但是只会执行一次。4.6版本以后的POC是不可以级联的，级联会触发RUNTIME ERROR。

 

COMMIT WORK语句会按调用这些POC的先后顺序执行这些subroutine，最后会触发一个DB COMMIT。如果执行的过程中有错误，可以通过A类型的MESSAGE，让这些POC的所有数据库更新都不会起作用。

 

需要注意的是，POC形式的subroutine是不可以有接口参数的，一般都是使用全局数据。

 

小结：

在应用程序中更新数据库的概念很直接，执行的也比较快。

但是用户必须等待直到改变完成；DIA PROCESS不会释放；没有错误日志；一些DB WORK PROCESS并行，比较差的数据库PERFORMANCE；LUW的处理和锁的使用都必须在程序中来实现，没有系统功能的支持。

鉴于以上优缺点，在程序中直接更新数据库一般用于单条数据更新或者对性能影响不大的情况下。