Ansicht
Dokumentation
ABAPMODIFY_SOURCE - MODIFY SOURCE
SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up Addresses (Business Address Services)This documentation is copyright by SAP AG.
MODIFY dbtab, source
... @wa$|@( expr )
$| ${ TABLE @itab$|@( expr ) $}
( SELECT
subquery_clauses $[UNION$|INTERSECT$|EXCEPT ...$] ) ...
Alternatives:
1. ... @wa$|@( expr
)
2. ... TABLE @itab$|@( expr )
3. ... ( SELECT subquery_clauses $[UNION$|INTERSECT$|EXCEPT ...$] ) ...
Effect
A non-table-like data object wa can be specified after FROM in the statement MODIFY and an internal table or a parenthesized subquery can be specified after TABLE. The work area and the internal table can be specified as a host variable or a host expression. On one hand, the content of the data objects or the result set of the subquery determines whether the rows are inserted or changed, and on the other hand, which values are inserted or used for changes.
Note
Host variables without the escape character @ are
obsolete. The escape character @ must be specified in the
strict modes of the syntax check from Release .
Alternative 1
... @wa$|@( expr )
Effect
When a non-table-like work area that meets the requirements for use in statements is specified as a host variable @wa or host expression @( expr ), a row is searched in the DDIC database table or view that has the same content in the primary key as the corresponding initial part of the work area.
- If a row like this is found, this row is overwritten in accordance with the same rules as for the statement UPDATE.
- If a row like this is not found, a new row is inserted according to the same rules as for the statement INSERT.
If the change would produce a duplicate entry in a unique secondary index, it is not executed and sy-subrc is set to 4.
Views whose fields are all key fields should not be written to using MODIFY FROM. For DDIC database views, this produces a syntax check warning and for DDIC projection views a syntax error or runtime error.
Notes
- The wa work area should always be declared with reference to the DDIC database table or the DDIC view in the ABAP Dictionary. For the derivation of LOB handle structures, there are special additions of the statements TYPES and $[CLASS-$]DATA.
- Exceptions due to invalid values can also be raised in compatible work areas. For example, components of the types d and t can contain invalid dates and times that are not accepted by columns of the types DATN and TIMN.
- If the DDIC database table or DDIC view is specified statically, a
short form can be specified outside of classes. This means that the work area specified using FROM wa can be omitted if a
table work area
dbtab for the respective DDIC database table or the DDIC view is declared using the statement
TABLES. The system then implicitly adds the addition FROM dbtab to the MODIFY statement.
Example
Creation or changing of a message in the DDIC database table T100. If there is no message with the number 100 in the MYMSGCLASS message class in English, it will be created. Otherwise, only the text is changed.
Example
The same example as before, but with a host expression.
Alternative 2
... TABLE @itab$|@( expr )
Effect
When an internal table is specified as a host variable @itab or host expression @( expr ), its rows are evaluated to overwrite existing rows or to insert new rows. The row type of the internal table must meet the prerequisites for use in statements.
This behavior is platform-dependent and follows one of the following patterns depending on the database system:
- UPDATE followed by INSERT:
- First, the same function as for UPDATE FROM TABLE is executed for all rows of the internal table.
- Next, the same function as for INSERT FROM TABLE is executed for all rows. Here, any rows that have the same primary key or unique secondary index are ignored.
- The processing of the rows in the internal table can also be split into blocks depending on the database system.
- Row by row MODIFY
- In a loop, each row in the internal table is processed in accordance with the rule above for MODIFY ... FROM wa. Here, the database system specifies whether processing continues in cases where a row could not be inserted due to a unique secondary index.
These two platform-dependent processing methods can produce different results in cases where the DDIC database table has unique secondary indexes (see executable example).
If the change to a row in the internal table would produce a duplicate entry in a unique secondary index, the corresponding row is not inserted and sy-subrc is set to 4. If the internal table is empty, no rows are processed. However, sy-subrc is still set to 0. The system field sy-dbcnt is set to the number of rows that are actually processed.
Notes
- To prevent platform-dependent behavior, MODIFY ... FROM itab should only be applied to DDIC database tables without unique secondary indexes. If not, the required behavior must be programmed explicitly using UPDATE and INSERT or using LOOP AT itab and MODIFY.
- When an internal table is specified, locators can be used as a source, but no writer streams can be created.
Example
Creation or changing of multiple rows in DDIC database table DEMO_UPDATE. This DDIC database table does not have a unique secondary index and the result is therefore not platform-dependent.
Example
The same example as before, but with a host expression.
Alternative 3
... ( SELECT subquery_clauses $[UNION$|INTERSECT$|EXCEPT ...$] ) ...
Effect
If a parenthesized subquery is specified, the rows in the result set defined by subquery_clauses are evaluated to overwrite the existing rows or to insert new rows. The language elements UNION, INTERSECT, and EXCEPT can be used to combine the result sets of multiple subqueries. In this case, special rules query_clauses apply to specifying clauses.
When used with a subquery, the statement MODIFY is platform-dependent, as above when an internal table is specified, and follows one of the two following database-dependent patterns:
- UPDATE followed by INSERT
- Row by row MODIFY
With respect to the following actions,
- client handling,
- inserting or modifying the data in the DDIC database table or view, and
- handling of null values,
the same rules and notes apply as when using a subquery as a data source of the statement INSERT. In particular, a subquery cannot be used if logging is enabled for the table to be modified.
If the result set of the subquery is empty, no rows are processed and sy-subrc is set to 4.
A subquery in the statement MODIFY is not supported by all databases. This means a syntax check warning from the extended program check can occur that can be hidden using the pragma ##db_feature_mode[modify_from_select]. If this is detected at runtime on a database that does not support the pragma, a catchable exception of the class CX_SY_SQL_UNSUPPORTED_FEATURE is raised.
Notes
- The constant MODIFY_FROM_SELECT of the class CL_ABAP_DBFEATURES can be used to query whether the current database supports subqueries in the statement MODIFY.
- When a subquery is used in the statement MODIFY, the syntax check is performed in strict mode from Release , which handles the statement more strictly than the regular syntax check.
Example
A subquery of the statement MODIFY reads all rows in the database table demo_join3 and uses the result set to modify the database table demo_join1. Two rows of the result set overwrite existing rows in demo_join1 and a row is inserted. Only if logging is disabled for DDIC database table DEMO_JOIN1, a subquery can be used. Otherwise, the data must be inserted into an internal table that serves as a source for the modification.
BAL Application Log Documentation rdisp/max_wprun_time - Maximum work process run time
This documentation is copyright by SAP AG.
Length: 13538 Date: 20240420 Time: 081719 sap01-206 ( 177 ms )
