SAP NetWeaver AS ABAP Release 750, ©Copyright 2016 SAP AG. All rights reserved.
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.
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:
The source text of the database program now contains further comment lines, indicating that the following tables and fields were created:
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:
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:
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.