Get Example source ABAP code based on a different SAP table
ID PROVIDE • PROVIDE ABAP Statement • * PROVIDE (special) • FROM PROVIDE (special) • INTO PROVIDE (special) • VALID PROVIDE (special) • BOUNDS PROVIDE (special) • FIELDS PROVIDE (special) • BETWEEN PROVIDE (special)
PROVIDE> Short Reference >
ABAP_SYNTAX PROVIDE FIELDS ${*$|${comp1 comp2 ...$}$}> FROM itab1 INTO wa1 VALID flag1> BOUNDS intliml1 AND intlimu1> $[WHERE log_exp1>$]> FIELDS ${*$|${comp1 comp2 ...$}$}> FROM itab2 INTO wa2 VALID flag2> BOUNDS intliml2 AND intlimu2> $[WHERE log_exp2>$]> ...> BETWEEN extliml AND extlimu> $[INCLUDING GAPS$].> ...> ENDPROVIDE.>
ABAP Addition 1 ... WHERE log_exp> 2 ... INCLUDING GAPS>
What does it do? Table iteration> across multiple tables depending on interval limits. The statements PROVIDE > and ENDPROVIDE> define a loop around a statement block. In this loop, any number of internal tables itab1>, itab2>, ... are processed together. A single table can be listed more than once. For each table itab> a FIELDS> addition must be specified. After FIELDS>, either the placeholder *> must be specified for all components or a list comp1>, comp2>, ... must be specified for certain components of the table in question. The names of the components comp1>, comp2>, ... can only be specified directly.
ABAP_PREREQUISITES Prerequisites for processing internal tables using PROVIDE> are:
All tables itab1>, itab2>, ... must be completely typed index tables.
Each table must contain two particular columns that have the same data type for all tables involved. The data type can be d>, i>, n>, or t>. ABAP_PREREQ_END For every table, the names of these columns must be specified as operands intliml1>, intliml2>, ... and intlimu1>, intlimu2>, ... behind the addition BOUNDS>.
Defining Intervals In every line of the internal tables involved, the columns intliml1 >, intliml2>, ... and intlimu1> , intlimu2>, ... must contain values that can be interpreted as limits of closed intervals. The PROVIDE> statement must be able to interpret intervals defined by these columns as a kind of unique key for each line within each individual internal table. This is achieved by the following additional prerequisites for the values in these columns:
The intervals must not overlap.
The intervals must be sorted in ascending order with regard to the primary table index>. Another external interval with limits extliml> and extlimu> must be specified using the BETWEEN> addition. The operands extliml> and extlimu> can be data objects that can be converted to the data types of columns intliml1>, intliml2>, ... and intlimu1>, intlimu2>, ... respectively. The interval limits intliml1>, intliml2>, ... and intlimu1>, intlim2>, ... of each line of all internal tables itab1>, itab2>, ... that are located within the closed interval made up by extliml> and extlimu> divide the latter into a set of sequential intervals, where each interval limit closes an interval in the original direction. If inside an involved table a lower interval limit follows an upper interval without a gap and if the components specified after FIELDS > have the same content in the corresponding lines, the two intervals are combined and the corresponding interval limits intliml1>, intliml2>, ... and intlimu1>, intlimu2>, ...are ignored for the new intervals.
Target Areas For every table, two target areas must be specified:
A work area wa1>, wa2>, that is compatible with the respective line type.
A variable flag1>, flag2>, ... which has a character-like data type with length 1 or can be converted into that type. For each loop pass of the PROVIDE> loop, values are assigned to work areas wa1>, wa2>, ... and variables flag1>, flag2>, ... for every internal table. A work area wa1>, wa2>, ... or a variable flag1>, flag2>, ... cannot be specified more than once.
Processing a PROVIDE> Loop The PROVIDE> loop processes the above described set of sequential intervals that results from the internal and external interval limits from left to right. For each interval of this set that overlaps with at least one of the internal intervals of a table involved, one loop pass is executed. and the target areas are filled with values as follows:
The components intliml1>, intliml2>, ... and intlimu1 >, intlimu2>, ... of every work area wa1>, wa2>, ...are filled with the interval limits of the current interval.
If the current interval overlaps with one of the intervals of an involved table, the remaining components of the corresponding work area are assigned the content of the corresponding components of this table line and the variables flag1>, flag2>, ... are set to the value X .
Otherwise, the work area components and the variables flag1>, flag2>, ... are set to their initial value>. For performance reasons, the components of the work areas are filled with values again only if the corresponding content of the table lines has been modified since the preceding loop pass.
Except for intliml1>, intliml2>, ... and intlimu1>, intlimu2>, ... the components not specified after FIELDS> are always set to their initial value. The components intliml1>, intliml2>, ... and intlimu1>, intlimu2>, ... are always assigned an interval limit. The PROVIDE> loop processes the set of sequential intervals from left to right and checks for each loop pass whether the lines of every table involved meet the above prerequisites of non-overlapping intervals and sorting within the interval made up by extliml> and extlimu>. If such a line is detected before the complete set of intervals is processed, catchable exceptions of the class CX_SY_PROVIDE_INTERVAL_OVERLAP> or CX_SY_PROVIDE_TABLE_NOT_SORTED> are raised.
Exiting a PROVIDE> Loop The PROVIDE> loop can be exited with the following statements;