ARTICLE
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 value 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.
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 .
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved