ABAP_ALTERNATIVES: 1 ... SET set_expression1, set_expression2, ... $[WHERE sql_cond$] $[db_hints$]> 2 ... FROM @wa$|@( expr ) $[INDICATORS $[NOT$] SET STRUCTURE set_ind$]> 3 ... FROM TABLE @itab$|@( expr ) $[INDICATORS $[NOT$] SET STRUCTURE set_ind$]>
What does it do? The specifications in source> define which rows and columns are changed. Either individual columns are changed using the addition SET> or entire rows are overwritten using the addition FROM >. After FROM> a non-table-like data object, or after TABLE> an internal table, can be specified as a host variable> or host expression>. The content of these objects determines which rows are changed and which values are used to overwrite the rows. After FROM>, set indicators> can be used to define individual fields within a row to be changed (instead of overwriting the entire content of a row).
Latest notes: NON_V5_HINTS Host variables without the escape character @> are obsolete>. The escape character @> must be specified in the strict modes> of the syntax check from ABAP_RELEASE ABAP_740_SP05 . ABAP_HINT_END
ABAP Alternative 1 ... SET set_expression1, set_expression2, ... $[WHERE sql_cond>$] $[ db_hints>$]>
ABAP Addition 1 ... WHERE sql_cond> 2 ... db_hints>
What does it do? After the addition SET>, the changes are specified in a list of change expressions: set_expression1 >>, set_expression2>>, ...> The content of primary key fields can be modified only if the affected DDIC database table is not linked with a search help. If these changes would create a row which would produce duplicate entries in the primary key or a unique secondary index of the DDIC database table, no rows are changed and sy-subrc> is set to 4. If the value of a column with type LRAW> or LCHR> is modified, the associated INT2> or INT4> field must also be given a value.
Latest notes: NON_V5_HINTS
When a comma-separated list is used, the syntax check is performed in a ABAP_STRICT_740_SP05 strict mode / , which handles the statement more strictly than the regular syntax check.
Instead of using commas, blanks can be used to separate change expressions in an obsolete form>. Commas must be specified, however, in the strict modes> of the syntax check from ABAP_RELEASE ABAP_740_SP05 . ABAP_HINT_END
ABAP_EXAMPLE_ABEXA UPDATE>, Use of SET>> ABAP_EXAMPLE_END
ABAP Addition
What does it do? The addition WHERE> determines in which rows of the DDIC database table the changes are made. Those rows are changed for which the logical expression sql_cond>> is true. The relational expressions> of the logical expression sql_cond>> are subject to the restriction that no subqueries> can be evaluated on the modified DDIC database table. If no WHERE> condition is specified, all the rows in the target of the statement are modified by default. In a client-dependent target, these are the rows of the current client. Implicit client handling> can be defined using the addition USING>>. The client column> of a client-dependent target cannot be specified in the WHERE> condition.
Latest notes:
If the data source is accessed using generic table buffering>, the buffered area must be specified completely in the WHERE> condition. If not, buffering is bypassed.
If the data sources are accessed using single record buffering, the conditions joined using AND> in the WHERE> condition must be specified for all key fields of the primary key. If not, buffering is bypassed. NON_V5_HINTS
If implicit client handling> is disabled using the addition CLIENT SPECIFIED>>, which is obsolete here, it is still possible to use a client column as an operand in the WHERE> condition. ABAP_HINT_END
ABAP_EXAMPLE_VX5 Sets multiple columns in a row determined using a WHERE> condition. ABEXA 00758 ABAP_EXAMPLE_END
ABAP Addition
What does it do? In this variant, database hints> can be specified using db_hints>>.
ABAP Alternative 2 ... FROM @wa$|@( expr ) $[INDICATORS $[NOT$] SET STRUCTURE set_ind$]>
What does it do? If a non-table-like work area is specified as a host variable @wa>> or host expression @( expr )>>, a row is searched in the DDIC database table whose primary key content is the same as that of the corresponding initial part of the work area. The work area must meet the prerequisites> for use in AB-SQL statements.
If a work area that does not contain any reference variables for LOB handles> is specified, the content of the work area is used unconverted and according to the structure of the DDIC database table BEGIN_SECTION VERSION 5 OUT or the view END_SECTION VERSION 5 OUT . The content of the work area is assigned to the rows found. The assignment takes place without conversion, from left to right according to the structure of the DDIC database table BEGIN_SECTION VERSION 5 OUT or the view END_SECTION VERSION 5 OUT .
When a LOB handle structure> is specified, it must be structured exactly like the structure of the DDIC database table in accordance with the prerequisites >. Work area components that are not LOB handle components> are assigned directly to the corresponding column of the row found. In the case of a LOB handle component of a reader stream type, the reader is created. If it is a type for a locator, the locator must exist and is used as a source. For details, see LOB handles >.
When set indicators are specified with the addition INDICATORS>> and the work area does not contain any reference variables for LOB handles>, it must be compatible with the structure of the DDIC database table. In the case of a LOB handle structure>, the LOB handle components can be mapped to the data types STRING> or RAWSTRING> and are handled as described above. If there is no row with the same content for the primary key in the database or if the change would produce a duplicate entry in a unique secondary index, the row is not changed and sy-subrc> is set to 4.