Linking to a Logical Database 

When you create an executable program, you can specify the name of a logical database in its program attributes. A logical database is a special ABAP program that combines the contents of certain database tables. You can use a logical database with any number of executable programs. If you enter an asterisk (*) for the logical database, the system uses a standard database that controls the selection screen, but does not read any data.

Running Programs With and Without Logical Databases

When you run an executable program that has a logical database linked to it, the two programs function like a single executable program whose processing blocks are called by the runtime environment in a particular order. For further details, refer to the diagram in the section Link with Executable Programs.

The main functions of a logical database are to call the selection screen and read data. If there is an appropriate logical database in the system, you no longer need to program these functions.

Executable programs that do not use a logical database, but define their own selection screen and read data using Open SQL statements (SELECT) often require only one single processing block – the standard event block START-OF-SELECTION. In this case (and only in this case), an executable program behaves like a classic sequentially-processed program. However, as soon as you process a selection screen in the program (for example, filling input fields before the call or checking user input after the call), you have to include further processing blocks (INITIALIZATION, AT SELECTION-SCREEN). If you use a logical database, the program is fully event-driven. The most important event used with logical databases is GET. At this time, the logical database passes an imported record to the appropriate processing block in the executable program.

For an overview of events and the sequence in which they are processed, refer to Event Blocks in Executable Programs. You can, of course, program your own database accesses using Open SQL in any event block.

The following example compares two simple executable programs that read data from the hierarchical database tables SPFLI and SFLIGHT. One does not use a logical database, the other uses the logical database F1S. Both programs generate the same list.

Executable program without logical database

REPORT demo_program_read_tables_1.

DATA: wa_spfli TYPE spfli,
      wa_sflight TYPE sflight.

SELECT-OPTIONS: sel_carr FOR wa_spfli-carrid.

SELECT carrid connid cityfrom cityto
       FROM spfli
       INTO CORRESPONDING FIELDS OF wa_spfli
       WHERE carrid IN sel_carr.

  WRITE: / wa_spfli-carrid,
           wa_spfli-connid,
           wa_spfli-cityfrom,
           wa_spfli-cityto.

  SELECT fldate
         FROM sflight
         INTO CORRESPONDING FIELDS OF wa_sflight
         WHERE carrid = wa_spfli-carrid
           AND connid = wa_spfli-connid.

    WRITE: / wa_sflight-fldate.

  ENDSELECT.

ENDSELECT.

This program does not need any explicitly-declared processing blocks. All non-declarative statements automatically belong to the default event block START-OF-SELECTION. The selection screen, work areas for data, and the SELECT statements all have to be written in the program itself.

Executable program with logical database

The logical database F1S is entered in the attributes of the executable program:

REPORT demo_program_read_tables_2.

NODES: spfli, sflight.

GET spfli FIELDS carrid connid cityfrom cityto.

  WRITE: / spfli-carrid,
           spfli-connid,
           spfli-cityfrom,
           spfli-cityto.

GET sflight FIELDS fldate.

  WRITE: / sflight-fldate.

If you compare this program with the executable program without a logical database, you see that this program does not have to take on any tasks, except the list output. These tasks are performed by the logical database. The NODES statement declares the work areas into which the logical database places the data that it reads.

Controlling the Logical Database from the Executable Program

When you use a logical database, you can control the selection screen and the depth to which the logical database reads data. With NODESstatement, you specify the nodes of the logical database that you want to use in the executable program. The statement declares table work areas for these nodes in the program. These are data objects with the same name and structure as the corresponding node. The selection screen of the logical database only contains input fields for the nodes that you have declared using NODES.

You control the depth to which the logical database reads data by defining GET event blocks. You do not have to program a GET event block for every node declared using NODES. The logical database always reads the necessary data – that is, at least the key fields – for all nodes along the path of the hierarchy tree up to the lowest-level node for which a GET event block is defined. If you have not defined a particular node for processing, the logical database also ignores all the corresponding subordinate parts of the hierarchy tree.

Each GET event block knows both the fields of the current node and the fields that it has read from all the higher-level tables that are along the current read path. At the end of a hierarchy level, the logical database resets the table work area in the executable program to HEX null.

You can also dynamically change the depth to which the logical database is read by terminating a GET event block (EXIT, CHECK). When you terminate a GET event block, the logical database ignores any subordinate nodes in the hierarchy.

By specifying a field list in the definition of the GET event block, you can have the program control the amount of data read for each node. This only works if the relevant node in the logical database has been defined for field selections.

Example of read depth using logical database F1S:

NODES: spfli, sflight, sbook.
  ...
  GET spfli.

The logical database does not read any data from the table SFLIGHT or SBOOK.

NODES: spfli, sbook.
  ...
  GET sbook.

The logical database reads data from the tables SPFLI and SFLIGHT, since they are on the access path for the node SBOOK. However, you cannot access data from SFLIGHT in the executable program.

Advantages of Using Logical Databases

Logical databases save you having to program a selection screen and read data from the database in each executable program. The program does not have to specify how to retrieve the data, but instead only has to process it and display it on the output screen.

An executable program can always only work with one logical database, but each logical database can be used by several executable programs. This offers considerable advantages compared with the method of integrating the database accesses into the individual executable programs using SELECTstatements. It means that you only have to code identical access paths once. The same applies to coding authorization checks.

When you use logical databases, most executable programs benefit from having

· An easy-to-use and standard user interface

· Check functions which check that user input is complete, correct, and plausible

· Meaningful data selection

· Central authorization checks for database accesses

· Good read access performance (for example, with views) while retaining the hierarchical data view determined by the application logic.

Even though you are using central logical databases, the program itself remains flexible because:

· You can still create your own selection screens for each program

· You can code your own functions in any event block in the program. For example, you may want to write user dialogs for further authorization or plausibility checks on the selection screen.

Programming Logical Databases

Logical databases are editing using the tool Logical Database Builder in the ABAP Workbench (Transaction SLDB or Tools ® ABAP Workbench ® Development ® Programming Environment ® Logical Database Builder. For further information about programming logical databases, refer to the section Logical Databases.