Logical Databases - Associated with Executable ProgramsOther versions:
How the Association Works
When an executable program
is associated with a logical database (meaning that the logical database is entered in the program attributes), the subroutines of the
database program are combined with the
reporting event blocks of the executable program
to create a complete modularized program for reading and processing data. The individual processing
blocks are called in a fixed order by the runtime environment. The runtime behavior is controlled by
the structure, selections, and
PUT statements of the logical database, plus the
GET statements of the executable program.
The runtime environment calls are determined by both the structure of the logical database and the definition
of the executable program. The structure of the logical database specifies in which order the subroutines
of the logical database are called, which themselves call the
GET event blocks
in the executable program. The
GET event blocks defined in the executable
program determine the read depth of the logical database..
TABLES statements in the global declaration part of the executable program
determine which of the input fields defined in the logical database are included on the selection screen and define interface work areas for passing data between the logical database and the executable program.
Generally, the database is actually accessed using ABAP SQL statements implemented in the
subroutines. The data read is passed to the executable program using the interface work areas. Once
the data is read in the logical database program, the executable program can process this data in the
GET event blocks. This is the point at which the reader actions are separated from processor actions.
If a logical database is specified in the attributes of an executable program, this modifies the standard selection screen of the program. The standard selection screen contains both the selections (selection criteria and parameters) of the logical database and the program-specific selections. By declaring interface work areas, the executable program determines which database-specific selections are relevant for its data analysis and appear on the selection screen.
The following describes the order in which the ABAP runtime environment calls the subroutines of the logical database and the event blocks in the executable program. Usually, the subroutines are called before the event blocks. To do this, various processors (such as the selection screen processor and reporting processor) are executed in sequence in the runtime environment (see also Flow of an Executable Program).
This subroutine is called once only before the selection screen is sent for the first time.
This event occurs once only before the selection screen is sent for the first time.
This subroutine is called before each occasion a selection screen is sent.
AT SELECTION-SCREEN OUTPUT
This event occurs before each occasion a selection screen is sent.
If the user requests input help or field help for database-specific parameters or selection criteria, these subroutines are called accordingly.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR ...and
AT SELECTION-SCREEN ON HELP-REQUEST FOR ...
If the user requests input help or field help for program-specific parameters or selection criteria, these events are raised accordingly.
pai USING fname mark.
The interface parameters fname and
markare passed by the runtime environment.
fnamecontains the name of a selection criterion or parameter on the selection screen. If
markis initial, the user entered a simple single value selection or interval selection. If
markhas the value "*", the user also made entries on the multiple selection screen. A combination of "*" for
fnameand "ANY" for
markenables all entries to be check at once for a user action.
AT SELECTION-SCREEN ON ...and
AT SELECTION-SCREENwithout additions.
Events for processing a specific input field, for processing multiple selections, and for processing all user input.
before_eventwith parameter "START-OF-SELECTION"
The logical database can perform actions before data is read, such as initializing tables.
The first reporting event after selection screen processing. Preparations can be performed in the program in this event block.
The logical database reads the selected data of the node
GET table [LATE]
This event is raised in the subroutine above by the
PUTstatement. In this event block, the data read for
nodecan be passed from the corresponding interface work area.
after_eventwith parameter "END-OF-SELECTION"
The logical database can perform actions before data is read, such as releasing memory.
Last reporting event. In this event block, all buffered data can be edited (for example, sorted).
Authorization checks performed by the statement AUTHORITY-CHECK are useful in the following subroutines of the database program or the event blocks of the executable program:
- Event blocks
AT SELECTION SCREEN ...and
Authorization checks should always be implemented centrally and should be reusable in the logical database program. The actual location of an authorization check (in the database program or in the executable program) can depend on the following factors, however:
- The structure of the logical database. For example, in the case where a company code authorization is only to be checked when a row with the Company Code field is read at runtime as well.
- Performance. Multiple checks, for example within
SELECTloops, should be avoided.