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

Logical Databases - Associated with Search Helps

A logical database can be associated with a suitable search help. The best type of search help for a logical database depends on the content of the database. For example, if a logical database is created to read vendor records, one output field of the search help must be the vendor number. The logical database is provided with the content of the search help output fields and uses it to perform the actual reads on the database tables.

To enable the user to use the search help, the a special parameter with the addition AS SEARCH PATTERN must be declared in the selection include. The selection screen then displays the Selection by Search Help box, including input fields for the search help ID and the search string. There is also a pushbutton for complex search helps and multiple selection is permitted for every individual field.

The runtime environment is responsible for interpreting the user input on the selection screen and reading the value list from the database. These rows are passed to the database program in the internal table ldb_sp and the subroutine put_ldb_sp is called for the root node instead of the subroutine put_node. Here, ldb is the name of the logical database. The value list in the internal table ldb_sp is used to enable this subroutine to read the actual data and raise the event GET for the root node using the statement PUT. It is often useful to call the subroutine put_node for the root node from put_ldb_sp. The subroutine then selects the data and raises the associated GET event using PUT. The structure of the internal table ldb_sp and other automatically generated tables is displayed as a comment in the database program source code. The source code also contains documentation about how to use these tables.

The options provided by dynamic selections and field selections should also be exploited when using search helps to access the database. Search helps can also be used to improve performance. The internal tables get_events, sp_fields, and sp_tables plus the structure sp_events can be used to program different database reads in the database program, depending on which tables and fields are used and filled. For example, it is possible to use views or joins and collect the read records in internal tables and thereby process the internal tables at a later time and raise the GET events in question.

Other versions: ~~7.31~~ | 7.40 | 7.54

Example

An imaginary logical database ZZF with the root node KNA1 is associated with the search help DEBI. The selection include DBZZFSEL contains the following lines:

SELECT-OPTIONS skunnr FOR kna1-kunnr. 
PARAMETERS p_sp AS SEARCH PATTERN FOR NODE kna1.

The source text of the database program now contains further comment lines, indicating that the following tables and fields were created:

Internal table zzf_sp in accordance with the following declaration:

DATA: BEGIN OF zzf_sp OCCURS 1000,
kunnr LIKE kna1-kunnr,
END OF zzf_sp.

The search help selections of the user create a hitlist in the filled output fields of the search help. This hit list is passed to the database program in the table zzf_sp.

Internal table sp_fields in accordance with the following declaration:

DATA: BEGIN OF sp_fields OCCURS 10. 
        INCLUDE STRUCTURE rsspfields. 
DATA: END   OF sp_fields.

If a collective search help is associated with the logical database, an elementary search help usually only fills some of the output fields of the collective search help. The table sp_fields tells the program which fields these are. The component supplied is non-initial whenever the search help passes a value to the field in fieldname.

Internal table sp_tables in accordance with the following declaration:

DATA: BEGIN OF sp_tables OCCURS 10. 
        INCLUDE STRUCTURE rssptabs. 
DATA: END   OF sp_tables.

If the search help contains fields from different tables, the table sp_tables tells the program which tables are covered by the search help. The component supplied is non-initial whenever the search help passes a value to the table in tablename.

Character-like data object sp_events with the length 200.

Each character in sp_tables stands for a node in the structure of the logical database (for example, the first character stands for the root node). The content of the individual items has the following meaning for the node in question:

"X2: Node is addressed in the application program using the statement GET and the search help assigned values for the key fields to sp_ldb.

"R": Node is addressed in the application program using the statement GET, but the search help did not assign values for the key fields to sp_ldb.

"M": Node is not addressed in the application program using the statement GET, but the search help assigned values for the key fields to sp_ldb.

" ": Table is not addressed in the application program using the statement GET and the search help did not assign values for the key fields to sp_ldb.

If the user selects all vendors in the search help on the selection screen whose sort field starts with "ABC" and this applies to the customer numbers 17, 125, and 230 , the tables above are filled as follows:

zzf_sp

kunnr
17
125
230

sp_fields

fieldname	supplied
KUNNR	X

sp_tables

tablename	supplied
KNA1	X

The subroutine put_zzf_sp (in comments) can now, for example, be modified and activated as follows to use the data records from the internal table zzf_sp:

FORM put_zzf_sp.
  CASE sp_events(1).
    WHEN 'X' OR 'M'.
      PERFORM put_kna1_Ssp
    WHEN OTHERS.
      PERFORM put_kna1.
  ENDCASE.
ENDFORM.

FORM put_kna1_sp.
  SELECT * FROM kna1 FOR ALL ENTRIES IN zzf_sp
                     WHERE kunnr = zzf_sp_kunnr.
    PUT kna1.
  ENDSELECT.
ENDFORM.

The table get_events is used to check whether the application program contains a GET statement for KNA1 or whether the search help has assigned appropriate values for key fields. If this is the case, put_kna1_sp is called, which executes a SELECT loop across KNA1 to read the rows that match the key fields in zzf_sp. The statement PUT kna1 is executed in the SELECT loop. Another option would be as follows:

FORM put_zzf_sp.
  IF sp_everts(1) NE abap_false
    CLEAR skunnr.
    REFRESH skunnr.
    skunnr-sign = 'I'.
    skunnr-option = 'EQ'.
    LOOP AT zzf_sp.
      skunnt-low = zzf_sp-kunnr.
      APPEND skunnr TO skunnr.
    ENDLOOP.
  ENDIF.
  READ TABLE GET_EVENTS WITH KEY 'KNA1'.
  IF sy-subrc = 0 AND get_events-kind IS NOT INITIAL.
    PERFORM put_kunnr.
  ENDIF.
ENDFORM.

This deletes the selection table skunnr for KNA1 and fills it with values from zzf_sp. The table get_events is used to check whether the application program contains a GET statement for KNA1. If this is the case, the subroutine put_kunnr is called. Here, the data from KNA1 is read as specified by the selection table skunnr and PUT kna1 is executed.