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
Related CONTINUE , EXIT , REJECT , STOP
Index
?SAP AG 1996
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
Related CONTINUE , EXIT , REJECT , STOP
Index
?SAP AG 1996
