SAP OPEN SQL GENERAL documentation, setup help and example usage

ARTICLE

Open SQL - General

Scope of Open SQL
Open SQL defines the subset of ABAP statements that enable direct access to data from the central database of the current AS ABAP . The Open SQL statements form the DML part of SQL in ABAP, which is supported by all database systems.
We differentiate between:

Read accesses

Modifying accesses

Database Interface
The Open SQL statements are transformed to database-specific
SQL in the Open SQL interface of the database interface . They are then passed to the database system and executed there. Open SQL statements can be used exclusively to access database tables that are declared in the ABAP Dictionary. It is also possible to access these using views.
By default, the central database of the AS ABAP is accessed. It is also possible to access other databases using secondary database connections .

Database Access
Each Open SQL statement is synonymous with an access to the database. This applies in particular with SELECT statements that end in ENDSELECT . Data to be read and to be modified is transported in packages between the database server and the current application server. The size of the packages can be configured using profile parameters (for example, the default value for Oracle is 65 KB ). The number of characters that can be transported in one package depends on whether the system is a Unicode system or a non-Unicode system.
To improve performance when accessing the database, SAP buffering can be activated to avoid accessing the database directly each time.
The function SQL Trace of the Performance Trace tool (transaction ST05 ) can be used to analyze the SQL statements actually passed to the database by the database interface.

Note
If more than approximately 2^32 entries are addressed in a single database access, the behavior of the database is undefined.

Client Handling
Open SQL works with automatic
client handling that always accesses the current client. The current client is the content of the system field sy-mandt .
When client-specific database tables are accessed, the client identifier cannot be explicitly specified in WHERE conditions, or it is ignored if specified in work areas of modifying statements. Automatic client handling can be switched off using the addition CLIENT SPECIFIED .

Notes

The client data from an AS ABAP is depicted in closed units. No cross-client access to databases should take place in application programs. For this reason, the addition CLIENT SPECIFIED should never be used and no access to sy-mandt should take place.

True multitenancy , with which the system ensures that different tenants' application data is isolated from each other, is not supported by the

ABAP runtime environment in the current release.

LUW
When using the modifying statements ( INSERT , UPDATE ,
MODIFY , and DELETE ), it is important to keep data storage consistent. The LUW concept is designed for this purpose. In application programs of an AS ABAP , the implicit database LUW s are normally not sufficient for consistent data storage. Instead, explicit SAP LUWs need to be programmed, which normally contain multiple database LUWs (refer to the section on data consistency ).

Performance
More information: Performance Advice for
Open SQL .

Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved