Database Changes from Within the Application program

If a transaction executes database updates from within the dialog program (direct or inline updates), all the database updates must be bundled into a single dialog step (usually the last). This bundling into a single dialog step is the only way to ensure that the database changes are processed using the "all or nothing” principle.

 

 

Direct Updates – Data Flow

If updates are executed from the dialog program, the data that you want to change must be saved as global program data until the database changes are made.

 

The changed data is written to the database with the content it had for the last dialog step.

 

 

Direct Updates – Locks

If the database is updated directly from within the program, then the program must set and release SAP locks itself.

 

Use the following specified sequence of steps for setting and releasing the locks:

1. Set locks of type “E” for your data.
2. Read data and display for change.
3. Change data in the database.
4. Release your locks.

Hint: Remember that the program must remove the locks by itself.

To release the locks, execute either the DEQUEUE_ module, which belongs to the lock object, or the general function module DEQUEUE_ALL, which removes all locks set by your program or leaves the program after the last database update.

 

 

Subroutines with Deferred Processing

Database updates from a dialog mode can be executed in bundled form by using the special subroutine technique PERFORM <subroutine> ON COMMIT.

 

The statement PERFORM <subroutine> ON COMMIT registers the specified subroutine for execution. This will not be executed until the next COMMIT WORK statement is reached.

 

If the database updates are “encapsulated” in the subroutines, they can be separated from the program logic and relocated to the end of the LUW (Logical Unit of Work) processing.

 

Each subroutine registered with the addition ON COMMIT is only executed once per SAP LUW.

 

Calls can be made more than once (no errors). The subroutine, however, is only executed once.

 

As of Application Server ABAP 4.6, nested PERFORM ON COMMIT calls trigger a runtime error.

 

 

PERFORM ON COMMIT – Error Handling

The COMMIT WORK statement carries out all subroutines that need to be executed, one after the other, and triggers a database commit.

 

If there is an error, the processing can be terminated from the respective subroutine with a type “A” dialog message and restored to the previous consistent database status.

 

 

PERFORM ON COMMIT – Data Flow

Subroutine calls using the addition ON COMMIT must not have any interface. Therefore, these special subroutines work only with global data objects. The values of that global data objects are used at the time of subroutine execution.

 

The PERFORM ON COMMIT technique is mainly used in the SAP update concept.

 

For further information, refer to the ABAP Editor keyword documentation for the term PERFORM.