Other Persistence Options 

Object-Relational Persistence - Object Services

Despite all the convenience and optimization possibilities of internal tables, there are cases where you will want to resort to alternatives: Internal tables represent a break in the object-oriented program paradigm. If you strictly adhere to it, your business objects will correspond to objects of your program, while the attributes will correspond to elements of the structure of the relevant business object.

Sometimes you will want to use object-oriented programming throughout. In these cases, it would be inconvenient if you were forced to use classic programming in the methods themselves – that is, store your objects at the end by means of classic programming. It would be preferable if data and methods encapsulated in an object could also be stored together – that is, store the object along with the information as to which class it belongs to. In this way, when an object is loaded from the database, the methods of its class are also made available. A different program could then continue working with the object in the state in which it was stored by another program.

For this purpose, ABAP provides the Object Services, whose role is comparable to that of JDO in Java. The ABAP Object Services form a layer between the ABAP program and the database, which ensures that the ABAP objects are stored on the database under a unique identity and can also be reloaded. You can also run queries, which correspond to selects in SQL, for objects in the database and get references to a set of objects that matches your search criteria. If you create a persistent object in a program and that object already exists in the database, it initially has the status of the data in the database. Changes to the object are only written back to the database if directly requested.

Do not use your own mechanisms to make objects persistent, but use the system services instead. The option of serializing the objects yourself and storing them on the database in byte buffers is only to be used when you want to store a small amount of data for a short period during program execution. With regard to access, search, and selection possibilities, the restrictions resulting from these self-serialized objects mean that this option is not useful for long-term storage or larger amounts of data.

Proprietary Addressing of Databases – Native SQL

With Native SQL you can use database-specific SQL statements in an ABAP program. In this way, you can include database tables that are not managed by the ABAP Dictionary and thus address datasets that were created independently of SAP NW AS ABAP. You start a Native SQL statement with EXEC SQL and close it with ENDEXEC.

Native SQL allows you to execute (nearly) all statements available through the SQL programming interface (usually known as SQL Call Interface or similar) for executing SQL program code directly (using EXEC IMMEDIATE or a similar command).

Since a Native SQL statement largely bypasses the database interface, you do not have access to some services that would be available with Open SQL: No table logging takes place, nor is there any synchronization with the database buffer on the application server. For this reason, you should, wherever possible, use Open SQL to change database tables declared in the ABAP Dictionary.

To ensure consistent behavior of transactions, you should not use any statements to control transaction processing (COMMIT, ROLLBACK, ...) with Native SQL.