Diif b/w Check and stop....

[Former Member]

Hi,

"Exit" and "Stop". What is the difference?

Reg,

Suresh.V

[Former Member]

Refer

EXIT

http://www.sts.tu-harburg.de/teaching/sap_r3/ABAP4/exit_.htm

STOP

http://www.sts.tu-harburg.de/teaching/sap_r3/ABAP4/stop.htm

[Former Member]

Hi,

STOP command will take you the END-OF-SELECTION event..

EXIT will go out of LOOP or event..etc..

Thanks,

Naren

[Former Member]

Hi Suresh,

Stop : Can be used only in the following events - AT SELECTION-SCREEN (without additions), START-OF-SELECTION & GET. On encounterng STOP, it trigeers the END-OF-SELECTION immediately.

Exit: Within a Loop, it terminates the LOOP processing. In processing blocks, it ends the cureent processing block. It is recommended not to use EXIT in processing blocks.

Regards,

Bharati

[Former Member]

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.

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. Examples of loop structures are:

DO ... ENDDO

WHILE ... ENDWHILE

LOOP ... ENDLOOP

SELECT ... ENDSELECT

Note

Outside loops, a CHECK with a negative outcome will cause you to exit the current processing block (event block, dialog module, procedure). During the reporting event GET, the system terminates the processing of the current entry, read by the logical database, and processes the next entry in the current node of the logical database. Nodes that are subordinate in the hierarchical structure of the logical database are not processed.

SAP recommends that you only use CHECK within loops. Use the RETURN statement to exit processing blocks.

You can use the REJECT statement to exit the reporting event GET conditionally.

CHECK - Particularly for reports with logical databases

Variants:

1. CHECK sel.

2. CHECK SELECT-OPTIONS.

Effect

Statement for leaving a processing block in an executable program conditionally.

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.

This variant is not allowed in an ABAP Objects context.

See CHECK SELECT-OPTIONS not allowed.

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 find out from the ABAP Development Workbench whether dynamic selections are defined and, if so, for which logical database tables by choosing Development → Programming environ. → Logical databases followed by Extras → Dynamic selections.

Example

The logical database F1S of the demo flight reservation system contains the table SPFLI with dynamic selections, and the table SFLIGHT without dynamic selections.

NODES:

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.

similarly, in the following example, CHECK SELECT-OPTIONS is equivalent to CHECK SP_FROM:

GET SPFLI.

CHECK SELECT-OPTIONS

Note

With CHECK SELECT-OPTIONS, fields from superior tables in the database hierarchy are not checked.

STOP

Basic form

STOP.

This statement is not allowed in an ABAP Objects context. See STOP not allowed.

Effect

This statement terminates a processing block in an excutable program of type 1.

Note

The statement is only intended for use in the INITIALIZATION, AT SELECTION-SCREEN, START-OF-SELECTION, and GET events. During the execution of type 1 programs, it terminates the processing of the associated event blocks and triggers the sending of the selection screen during the event INITIALIZATION, and - in all other cases - triggers the event END-OF-SELECTION of the runtime environment. In all other processing blocks or if END-OF-SELECTION is not desired, you must use RETURN or EXIT.