ABAP objects and the Object Services are part of a hybrid world in which object-oriented and classical applications as well as mixed forms containing both programming styles can exist side by side. The interaction between classical and object-oriented update techniques is discussed below.

In a classical application, statements that change the database normally are programmed in update modules. These changes are registered during program execution and the change is triggered with the COMMIT WORK statement.

If you access the services of the Object Services in a classical application, that is if you are working with a persistent objet or if you started an object-oriented transaction, an implicit top-level transaction is automatically created and started in compatibility mode the first time the services are accessed. All explicit accesses to the Persistence and Transaction Service are embedded in this implicit top-level transaction.

If COMMIT WORK is triggered in a classical application, the top-level transaction is also ended and the Transaction Service starts updating all the persistent objects that were changed up to this time. The persistent objects are updated as in classical applications. Similarly, all changes to persistent objects within the top-level transaction are cancelled by a classical ROLLBACK WORK.

In particular, the changes that were confirmed in object-oriented subtransactions with method END are made, whereas changes that were cancelled with UNDO are not affected. It could therefore be advisable to work with object-oriented (sub) transactions in classical applications as well in order to have access to an easy-to-use COMMIT/ROLLBACK mechanism.

Object-oriented transaction mode is set for object-oriented transactions. The top-level transaction is the first transaction to be started explicitly.

Within a program in object-oriented mode, classical components that use and register classical update modules might be called. This is possible as long as none of the classical components trigger the COMMIT WORK statement, since this would result in a runtime error in an object-oriented transaction.

An update is triggered by the implicit COMMIT WORK at the end of the object-oriented top-level transaction. If another object-oriented transaction is started in a called classical component, it is automatically the subtransaction of the top-level transaction and is also updated when it ends and before the persistent objects.