Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Obsolete Language Elements →  Obsolete Processing of External Data →  Logical Databases (Obsolete) →  Logical Databases - Components 

Logical Databases - Database Program

The database program of a logical database ldb has the name SAPDBldb. It is used as a container for subroutines called by the ABAP runtime environment when a logical database is processing. The order of the calls and how they combine with events in executable programs or the function module LDB_PROCESS is determined by the structure of the logical database.

A logical database program usually contains the following subroutines.

  • ldb_process_init
Called once before processing in the logical database, to prepare the database for any multiple calls by the function module LDB_PROCESS. If a logical database needs to be called more than once consecutively, the subroutine must exist and its input/output parameter subrc must be set to zero. If the parameter subrc is not set to zero, the function module LDB_PROCESS raises the non-class-based exception LDB_NOT_REENTRANT.
  • init
Called once before the selections are edited.
  • pbo
Called each time the selection screen is displayed, which means only when associated with executable programs and not in calls of the function module LDB_PROCESS.
  • pai
Called each time a user action is performed on the selection screen, which means only when associated with executable programs and not in calls of the function module LDB_PROCESS. At the same time, the interface parameters fname and mark are passed to the subroutine.
  • fname contains the name of a selection criterion or parameter on the selection screen.
  • mark describes the selection mad by the user. If mark contains a blank, this indicates that the user entered a simple single value or interval selection. If mark contains "*", this indicates that the user also made entries on the multiple selection screen.
  • ldb_process_check_selections
Is called instead of the subroutine pai if the logical database is called without selection screen processing by the function module LDB_PROCESS. This subroutine can check the selections passed by the function module. The subroutine is called after the parameters and selection tables of the selection screen are filled by the interface parameters of LDB_PROCESS. If its input/output parameter subrc is not set to zero, the function module LDB_PROCESS raises the exception LDB_SELECTIONS_NOT_ACCEPTED. A message in SYMSG format can be assigned to the structured input/output parameter msg. This message is then available to the caller of the function module in the system fields sy-msg....
  • put_node
Called in an order defined by the structure. This subroutine reads the data of the node node and uses the statement PUT node to trigger an appropriate GET event in the ABAP runtime environment. This statement is the central statement of this subroutine. It can be used only in a subroutine of a logical database whose structure has the node node and whose name starts with put_node. The PUT statement branches the program flow in accordance with the structure of the logical database. The read depth is determine by the GET statements of the application program or by the interface parameter CALLBACK of the function module LDB_PROCESS. First, the subroutine put_node is edited for the root node. The statement PUT branches the program flow as follows:
  • If the subroutine authority_check_node exists in the database program, the statement PUT branches to this subroutine first.
  • The PUT statement then triggers a GET event in the runtime environment. If a related statement GET node exists in an associated executable program, the corresponding event block is processed. If the parameter CALLBACK of the function module LDB_PROCESS is filled accordingly, the associated callback routine is called.
  • The PUT statement then branches the program flow as follows:

    (a) To the next existing subroutine of a direct successor node, if a lower node (not necessarily the direct successor) of the associated subtree in the executable program or function module is requested using GET.

    (b) To the subroutine of a node at the same level, if the superordinate node branches to a subroutine of this type and if a node of this type is requested in the executable program or function module using GET. Here, the PUT statement starts again with the first step. Branching does not continue in the subroutine of the lowest node in a subtree requested using GET. Instead, the current subroutine is resumed. If a subroutine put_node is executed in full, the program flow returns to the PUT statement from which a branch to put_node was made.
  • After returning from a subordinate subroutine put_node, the PUT statement triggers the event GET node LATE in the runtime environment.
  • authority_check_node
Called automatically by the statement PUT node. An authorization check for the node node in question from the structure of the logical database can be incorporated into this subroutine.
  • put_ldb_sp
Called when a selection is made using the search help, to be edited in the key selected in the search help. ldb is the name of the logical database. The table entries in the search help tables can be used to read the required entries from the root node from this subroutine. PUT can then be used to trigger the processing in the program. The subroutine put_node cannot then be called automatically for the root node.
  • before_event
Called before an event whose name is passed in the interface parameter event. Currently, only the value "START-OF-SELECTION" can be assigned to event to execute a subroutine before this time.
  • after_event
Called after an event whose name is passed in the interface parameter event. Currently, only the value "END-OF-SELECTION" can be assigned to event to execute a subroutine after this time.
  • par_val, selcrit_val, selcrit-low_val, selcrit-high_val
Called if (on the selection screen) the user calls the input help for the parameter par or the selection criterion selcrit, which must be one of the selections of the logical database.
  • par_hlp, selcrit_hlp, selcrit-low_hlp, selcrit-high_hlp
Called if (on the selection screen) the user calls the input help for the parameter par or the selection criterion selcrit, which must be one of the selections of the logical database.

The following internal table exists implicitly and can be used in the program:

DATA: BEGIN OF get_events OCCURS 10,
        node(10),
        kind,
      END OF get_events.

In each row, it contains the name of a node of the logical database in the component node. The component kind indicates whether the node is requested by the user and how:

  • "X": Node is addressed using GET and GET LATE.
  • "G": Node is addressed using GET only.
  • "L": Node is addressed using GET LATE only.
  • "W": Node is not addressed using GET or GET LATE. A subordinate node, however, is addressed using GET or GET LATE.
  • " ": Node is not addressed using GET or GET LATE and no subordinate node is addressed either.

Other versions: 7.31 | 7.40 | 7.54


Note

When a selection include is created, Logical Database Builder generates a template based on the existing structure and the selections defined in the selection include. The generated database program consists of multiple include programs:

  • DBldbTOP
    Contains the introductory program statement and global declarations.
  • DBldbXXX Incorporates the following include programs:
  • DBldb001, DBldb002, ...
    For the subroutines put_node and authority_check_node.
  • DBldbFXXX
    Subroutines for processing selection screens (initialization, PBO, PAI, ...).
  • DBldbSXXX
    Subroutine put_ldb_sp for handling search helps.
  • DBldbF001, DBldbF002, ... Self-defined include programs for additional functions.

The predefined NODES or TABLES statements and the predefined names of the automatically created include programs and subroutines cannot be modified. It is, however, possible to define further include programs or subroutines and modify the ABAP statements that read data. Self-defined include programs must use the naming convention DBldbFnnn, otherwise they cannot be transported by the logical database.


Example

LFB1 is a successor of LFA1 in the structure of the logical database. The following selection criteria are defined in the selection include:

SELECT-OPTIONS: slifnr FOR lfa1-lifnr,
                sbukrs FOR lfb1-bukrs.

One possible section of a database program is therefore:

FORM put_lfa1.
  SELECT * FROM lfa1
           WHERE lifnr IN slifnr.
    PUT lfa1.
  ENDSELECT.
ENDFORM.

FORM put_lfb1.
  SELECT * FROM lfb1
           WHERE lifnr =  lfa1-lifnr.
           AND   bukrs IN sbukrs.
    PUT lfb1.
  ENDSELECT.
ENDFORM.

An executable program associated with the logical database contains the lines:

GET lfa1.
  WRITE lfa1-lifnr.
GET lfb1.
  WRITE lfb1-bukrs.

In this example, the runtime environment calls the routine put_lfa1 after the event START-OF-SELECTION. The statement PUT lfa1 triggers the event GET lfa1. If the corresponding event block has been processed in the program, PUT lfa1 branches to the subroutine put_lfb1. From here, the event GET lfb1 is triggered in the program. If LFB1 is the last node to be read, the processing of the SELECT loop is then resumed in put_lfb1. If not, a branch to the subroutine put_node of the next node is performed. At the end of the SELECT loop of the last node, the SELECT loop of the next node up is resumed. The programming across nested SELECT loops makes the process flow easier to understand here. This should be avoided in real logical databases, however, to reduce the number of database reads. The PUT statements also do not branch to the subroutines for authorization checks in this example.


Example

See also Example of a Database Program.