ABAPWHERE_STATIC - WHERE STATIC

PERFORM Short Reference   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
This documentation is copyright by SAP AG.

Effect

Static WHERE condition. All lines are processed for which the condition after WHERE is met. If a static WHERE condition is specified, the line type of the internal table must be known statically. WHERE can be specified for all table categories.

A logical expression log_exp can be specified after WHERE, in which the first operand of each relational expression is a component of the internal table. The following can be specified as relational expressions:

• All comparison expressions

• The following predicate expressions:

• IS $[NOT$] INITIAL

• IS $[NOT$] BOUND

• IS $[NOT$] INSTANCE OF

No other predicates can be specified. The components of the internal table must be specified as individual operands and not as part of an expression. Parenthesized character-like data objects cannot be used to specify a component dynamically here. The remaining operands of a relational expression are general expression positions at which any suitable individual operands or expressions can be specified, but no components of the internal table. The specified components can have any data type. The corresponding comparison rules apply to the evaluation. Here, a different rule applies to a string expression on the right side than to general logical expressions.

• When standard tables are accessed without a secondary key specification, the access is not optimized. This means that all lines of the internal table are checked for the logical expression of the WHERE addition.

• When using a sorted key or a hash key, that is, when accessing a sorted table, a hashed table, or a secondary table key, an attempt is made to optimize the access as described under Optimization of the WHERE Condition. If the corresponding prerequisites are not met:

• the entire logical expression or a part of it can be transformed into a key access,

• the transformable part of the logical expression has the same result as the resulting key access,

No optimization takes place when a sorted table or a hashed table is accessed using the primary table key and access using a secondary table key produces a syntax error or exception. In the part of the logical expression that is relevant for the optimization, the static WHERE condition cannot contain any duplicate or overlapping key specifications. Duplicate key components can, however, be specified in the part of the logical expression whose relational expressions do not make a contribution to the optimized access.

Notes

• When using a WHERE condition, it should be noted that the comparison rules for incompatible data types apply when comparing incompatible data objects. Here, the data types involved determine which operand is converted. If the additions WITH TABLE KEY and WITH KEY of the statement READ are used or if the corresponding keys are specified in table expressions, however, the content of the specified data objects is always converted to the data type of the columns before the comparison, which can produce varying results.

• The difference between comparison rules in a WHERE condition and conversion rules when reading individual lines is particularly significant for enumerated types for which the comparison rules are more restrictive than conversion rules. Conversions of an enumerated object to a character-like type produce a message from the extended program check.

• If possible, all operands of the logical expression should be in compatible pairs, so that the WHERE condition can be optimized.

• If a comparison expression with a ranges table is specified after IN as a logical expression, the expression for the initial table is always true and then all lines are then processed.

BAL_S_LOG - Application Log: Log header data   Vendor Master (General Section)  
This documentation is copyright by SAP AG.

Length: 7151 Date: 20230207 Time: 092227     sap01-206 ( 114 ms )