CHECK ( ABAP Keyword) introduction & Details
CHECK – within loops
Basic form
CHECK logexp.
Effect
CHECK evaluates
the subsequent logical expression . If it is true, the processing continues with
the next statement.
In loop structures like
DO …
ENDDO
WHILE … ENDWHILE
LOOP … ENDLOOP
SELECT …
ENDSELECT
CHECK with a negative outcome terminates the current loop
pass and goes back to the beginning of the loop to start the next pass, if there
is one.
In structures like
FORM … ENDFORM
FUNCTION …
ENDFUNCTION
MODULE … ENDMODULE
AT
CHECK with a negative
outcome terminates the routine or modularization unit.
If CHECK is not in
a loop or a routine or a modularization unit, a negative logical expression
terminates the current event. In contrast, the statement REJECT terminates the
current event, even from loops or subroutines.
Note
If a CHECK
produces a negative result in a GET event , the GET events in subordinate tables
of the logical database are not processed either.
Related CONTINUE , EXIT ,
REJECT , STOP
CHECK – special for reports with logical databases
Variants
1. CHECK sel.
2. CHECK
SELECT-OPTIONS.
Variant 1
CHECK sel.
Effect
Checks the
selection criterion requested by the statement SELECT-OPTIONS sel …
.
This statement is equivalent to f IN sel , if sel was defined by
SELECT-OPTIONS sel FOR f and can be used anywhere in logical
expressions
If the result of this check is negative, the processing in
this event is terminated and the GET events for any subordinate database tables
are not processed either.
This variant of the CHECK statement should be
used only if the logical database for the corresponding table does not support
dynamic selections (see CHECK SELECT-OPTIONS ), or SELECT-OPTIONS with the
addition NO DATABASE SELECTION . Otherwise, the relevant record is not read from
the database and made available to the program.
Variant 2
CHECK
SELECT-OPTIONS.
Effect
Called only after a GET event.
This
statement checks all the selections for SELECT-OPTIONS where the reference field
after FOR belongs to the current table dbtab (specified after GET . However,
this applies only if the logical database for dbtab does not support dynamic
selections . Otherwise, the selections are passed directly to the logical
database (with the exception: addition ” NO DATABASE SELECTION ” to
SELECT-OPTIONS ).
This variant of the CHECK statement only makes sense if
the logical database does not support dynamic selections for the corresponding
table or SELECT-OPTIONS are defined with the addition ” NO DATABASE SELECTION
“.
You can determine from the ABAP/4 Development Workbench whether
dynamic selections are defined and, if so, for which logical database tables by
selecting Development -> Programming environ. -> Logical databases
followed by Extras -> Dynamic selections .
Example
The logical
database F1S of the demo flight reservation system contains the tables SPFLI
with, and the table SFLIGHT without, dynamic
selections.
TABLES:
SPFLI,
SFLIGHT.
SELECT-OPTIONS:
SF_PRICE FOR SFLIGHT-PRICE,
SP_CARR FOR
SPFLI-CARRID,
SP_FROM FOR SPFLI-CITYFROM NO DATABASE SELECTION,
SP_DEPT
FOR SPFLI-DEPTIME.
Since dynamic selections are defined with the
table SPFLI , but not with the table SFLIGHT , the following procedure
applies:
…
GET SFLIGHT.
CHECK SELECT-OPTIONS.
This
CHECK statement is equivalent to the following statement:
CHECK
SF_PRICE.
With
GET SPFLI.
CHECK
SELECT-OPTIONS.
the CHECK statement is equivalent to the following
statement:
CHECK SP_FROM.
Note
With CHECK
SELECT-OPTIONS , fields from superior tables in the database hierarchy are not
(!) checked.
Note
Runtime errors
CHECK_SELOPT_ILLEGAL_OPTION :
Wrong ” OPTION ” in SELECT-OPTIONS or RANGES table
CHECK_SELOPT_ILLEGAL_SIGN
: Wrong ” SIGN ” in SELECT-OPTIONS or RANGES table