ABAP Keyword Documentation → ABAP - Reference → Obsolete Language Elements → Obsolete Processing of External Data → Logical Databases (Obsolete) → Logical Databases - Use
Logical Databases - Associated with Executable Programs
Other 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.. NODES statements
or 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 Open SQL statements implemented in the put_node
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.
Selection Screen
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.
Runtime Behavior
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).
Subroutine
init This subroutine is called once only before the selection screen is sent for the first time.
Event block
INITIALIZATION This event occurs once only before the selection screen is sent for the first time.
Subroutine
pbo This subroutine is called before each occasion a selection screen is sent.
Event block
AT SELECTION-SCREEN OUTPUT This event occurs before each occasion a selection screen is sent.
Subroutines
...val and ...hlp If the user requests input help or field help for database-specific parameters or selection criteria, these subroutines are called accordingly.
Event blocks
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 triggered accordingly.
Subroutine
pai USING fname mark. The interface parameters fname and
mark are passed by the runtime environment. fname
contains the name of a selection criterion or parameter on the selection screen. If mark
is initial, the user entered a simple single value selection or interval selection. If mark
has the value "*", the user also made entries on the multiple selection screen. A combination of "*"
for fname and "ANY" for mark enables all entries to be check at once for a user action. Event blocks
AT SELECTION-SCREEN ON ... and AT SELECTION-SCREEN without additions. Events for processing a specific input field, for processing multiple selections, and for processing all user input.
Subroutine
before_event with parameter "START-OF-SELECTION" The logical database can perform actions before data is read, such as initializing tables.
Event block
START-OF-SELECTION The first reporting event after selection screen processing. Preparations can be performed in the program in this event block.
Subroutines
put_node The logical database reads the selected data of the node
node. Event block
GET table [LATE] This event is triggered in the subroutine above by the
PUT statement. In
this event block, the data read for node can be passed from the corresponding interface work area. Subroutine
after_event with parameter "END-OF-SELECTION" The logical database can perform actions before data is read, such as releasing memory.
Event block
END-OF-SELECTION Last reporting event. In this event block, all buffered data can be edited (for example, sorted).
Note
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:
- Subroutines
paiandauthority_check...
- Event blocks
AT SELECTION SCREEN ...andGET
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.
Example