Get Example source ABAP code based on a different SAP table
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 LUWs 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.
