ABAP Keyword Documentation → ABAP − Release-Specific Changes → Changes in Release 3.0
Logical Databases and Selection Screens in Release 3.0
1. Checkbox parameters
2. Matchcode selection with logical databases
3. SUBMIT WITH SELECTION-TABLE
4. Self-programmed F1
and F4
on selection screens
5. Date calculations in variants
6.
SUBMIT
: Runtime info returned by function module
7. No more blank selection screens
8. New OK
-command field SSCRFIELDS-UCOMM
on selection screens
9. Integration of data model
10. Function modules: User's own GUI status on selection screen
11. PARAMETERS
as radio buttons
12. Increase size of selection screens to 200 lines
13. SELECTION-SCREEN NEW-PAGE
no longer used
14. Selection screen versions instead of template screens
15. Blocks (with or without boxes) on selection screens
16. Ability to set comments on selection screens at runtime
17. User's own pushbuttons on selection screens
18. Dynamic selections on selection screens
19. Ability to set box title at runtime
20. Symbolic positions with SELECTION-SCREEN
statements
21. User's own pushbuttons in the application toolbar
22. Nested blocks on selection screens
23. Return to the selection screen after F3
in basic list
24. Passing report-specific selections to the database
25. Simplified SELECT-OPTIONS
on the selection screen
26. Field selection
27. Dynamic selections with SUBMIT
28. User-specific variables in variants
Other versions: 7.31 | 7.40 | 7.54
Modification 1
Checkbox parameters
PARAMETERS
now has an addition called AS CHECKBOX
which you can use to display a parameter on the selection screen as a checkbox.
Modification 2
Matchcode selection with logical databases
The addition AS MATCHCODE STRUCTURE
with PARAMETERS
allows you to use matchcode selection for a
logical database (e.g. xxx). The standard selection screen contains a box with input fields for matchcode ID and search string. In the
database program,
selected records are processed in the subroutine PUT_xxx_MATCHCODE
. Matchcode
selection improves performance since you can reduce the size of the selected dataset considerably. For
further information, see the documentation for PARAMETERS
and the extended help for Transaction SE36
, particularly the section "Matchcode
selection" in the chapter "Displaying and maintaining logical databases" and the section "Performance" in the chapter "Advantages of logical databases".
Modification 3
SUBMIT rep WITH SELECTION-TABLE seltab
.
The addition
WITH SELECTION-TABLE seltab
allows you to specify values passed via the
WITH clause to report parameters or selection criteria in an internal table. Here, the table
seltab has the structure of RSPARAMS
. You can use the function module
RS_REFRESH_FROM_SELECT_OPTIONS to fill the table with the contents of the current parameters
or selection criteria (it replaces the key word REFRESH
seltab FROM SELECT-OPTIONS). For further information, see the documentation on SUBMIT
.
Modification 4
Self-programmed F1 and F4 on selection screens
You can now define self-programmed help
(F4) and documentation
(F1) both for database-specific and report-specific parameters and selection criteria. For database-specific objects, you use an addition
(VALUE-REQUEST ...
or HELP-REQUEST ...
) with
PARAMETERS
and SELECT-OPTIONS
.
For report-specific objects, you specify the event to be processed at F1
or F4 explicitly (using AT SELECTION-SCREEN>
AT SELECTION-SCREEN ON VALUE-REQUEST FOR ...
or
AT_SELECTION-SCREEN>AT SELECTION-SCREEN
ON HELP-REQUEST FOR ...
).
Modification 5
Date calculations in variants
In addition to the variables available in table
TVARV
for parameters or selection criteria in variants (i.e. for retrieving
values at runtime), it is now possible to calculate dates or periods for parameters/selection criteria
of the type Date at runtime. Examples include "current date", "last day of previous month", and "first quarter of current year".
Modification 6
Runtime information returned by function module
The function module RS_SUBMIT_INFO
returns information about the current report execution process in the structure RSSUBINFO
. It is specifically intended for use during the processing of
selection screens.
It tells you, for example, whether the selection screen is processed when the report is executed, during
variant maintenance, or when scheduling a background job. This is important if you are using your own GUI status on the selection screen.
Modification 7
No more blank selection screens
Previously, selection screens were generated
and processed even if no parameters or selection criteria were defined. To reduce the number of selection screens, this is no longer the case. Events previously triggered by the selection screen
(AT SELECTION-SCREEN
,
AT SELECTION-SCREEN OUTPUT
) are not processed.
Modification 8
New command field SSCRFIELDS-UCOMM
on selection screens
Since the previous command field SY-UCOMM
used to be overwritten each time
a CALL SCREEN
statement was executed, it has been replaced by the field
SSCRFIELDS-UCOMM from the ABAP. In contrast to SY-UCOMM
, you must
declare the structure SSCRFIELDS
with
TABLES when reading or manipulating SSCRFIELDS-UCOMM
.
Since
SY-UCOMM
is always set at the same time, the process of reading it continues
to work as before. Only the procedure for setting SY-UCOMM
in the program has changed; you must now set SSCRFIELDS-UCOMM
instead.
Modification 9
Integration of data model
In Transaction SE36 (Logical Databases), you can
display the views that refer to a logical database table by selecting Goto -> Data
model -> Views and entities. The relevant entities are displayed from the Enterprise Data Model
(EDM). After choosing the views, you can select Goto -> Data model -> Graphics to display the convex closure of the relevant entities in the EDM.
Modification 10
Function modules: User's own GUI status on selection screen
Function modules
RS_SET_SELSCREEN_STATUS
and RS_EXTERNAL_SELSCREEN_STATUS
.
These function modules allow you to set your own status for the selection screen or to deactivate
function codes from the standard status (e.g. if you do not require the 'Print' function for the report).
While the function module RS_SET_SELSCREEN_STATUS
requires the desired
status to belong to the user interface for the report, the function module RS_EXTERNAL_SELSCREEN_STATUS
allows you to set a status that has been externally defined in a function group.
When you set
your own status, you should first inform yourself about the current situation with the function module
RS_SUBMIT_INFO
(see point 6). This way, you can avoid offering the 'Execute' key instead of the 'Save' key in variant maintenance.
Modification 11
PARAMETERS
as radio buttons
Addition RADIOBUTTON
GROUP group with PARAMETERS
By using this addition, you can combine PARAMETERS
together in radio
button groups on the selection screen. For further information, see PARAMETERS
.
Modification 12
Increase size of selection screens to 200 lines
Selection screens can now be up to 200 lines long. Since you can use the scrollbar to scroll within a screen, the continuation screens 1001, 1002 ... are no longer necessary.
Advantages: Since all SELECT-OPTIONS
and PARAMETERS
reside on one screen, you no longer have to check carefully that the incorrect field is actually on
the current screen when handling errors. Also, the addition 'OBLIGATORY' now applies for all SELECT-OPTIONS
or PARAMETERS
that were previously on a subsequent screen. The total number of generated selection screens is thus reduced.
Necessary actions: In theory, none. However, new pages previously forced by the SELECTION-SCREEN
NEW-PAGE statement may have to be replaced by something else like a block (see also points 13 and 14).
Modification 13
SELECTION-SCREEN
NEW-PAGE
no longer used.
Since continuation screens are no longer used, (see point 12), the key word
SELECTION-SCREEN NEW-PAGE is no longer required, but is retained for syntax reasons. However, it now starts a new line instead of a new page.
Modification 14
Selection screen versions instead of template screens
The option to define
non-standard selection screens by specifying the number of a model screen (belonging to the database
access program SAPDBxyz
) in the report attributes no longer exists. This
has been replaced by selection screen versions. Like model screens, these have a three-character name
that you specify on the report attributes screen. By pressing F4 there, you can get a list of all the selection screen versions for the underlying logical database.
You define the selection screen versions in the database INCLUDE
DBxyzSEL with the key words SELECTION-SCREEN
BEGIN/ END OF VERSION and SELECTION-SCREEN
EXCLUDE .... You use the latter to specify any objects to be excluded from the selection screen version.
Modification 15
Blocks (with or without boxes) on selection screens
You use the key word
SELECTION-SCREEN
BEGIN/END OF BLOCK block
to define logical blocks on selection screens. The addition ... WITH FRAME
allows you to generate a box round the block and, for each TITLE
addition,
you can define a text for the box. If the new event
AT SELECTION-SCREEN ON BLOCK block
contains an error dialog, only the fields in that block become ready for input.
The boxes previously generated round the database-specific or report-specific parts of the selection
screen are no longer required, since the new key words allow better and more individual grouping options.
Modification 16
Ability to set comments on selection screens at runtime
Besides numbered texts,
the key word SELECTION-SCREEN
COMMENT
now allows you to specify field names up to 8 characters long. These
fields are then generated automatically as output fields on the selection screen. You must define the texts in these comment fields at runtime and can change them while processing the selection screen.
Modification 17
User's own pushbuttons on selection screens
The key word
SELECTION-SCREEN
PUSHBUTTON ... USER-COMMAND ucom
allows you to generate pushbuttons on the selection screen. As with
SELECTION-SCREEN
COMMENT
, you can define the
text either statically in the form of a text symbol or dynamically by specifying an field name up to 8 characters long.
You can read the field SSCRFIELDS-UCOMM
with the accompanying user command
ucom
in AT SELECTION-SCREEN
.
Modification 18
Dynamic selections on selection screens
In the database INCLUDE
DBxyz
, you can use the
logical database
and the SELECTION-SCREEN
DYNAMIC SELECTIONS FOR TABLE dbtab statement to define 'dynamic selections' for the table
dbtab of the logical database xyz
. In this case, the key 'Dynamic
selections' appears on the selection screen, if the table dbtab
is used in
the report. After pressing this key, the user can enter selections for the fields expected by the logical
database. The result is passed directly from the logical database to the SELECT
statement.
Note
The field list for the dynamic selections can be defined by the logical database in the form of a grouped
set of fields which you maintain in the ABAP/4 Development Workbench or in logical database maintenance. To aid identification, you can use the origin
('SAP'
or 'CUS'
for 'customer'), the name of the
logical database and any name, which must always be 'STANDARD'
for the described
functionality on the selection screens. When reading the field list, the system first searches for the
set with the origin CUS
. If it finds nothing, it then searches for the origin
'SAP'
. This allows customers to define the optimal set to suit their requirements, if the SAP standard is not suitable.
Modification 19
Ability to set box texts at runtime
The title of a box defined with
SELECTION-SCREEN
BEGIN OF BLOCK ... WITH FRAME TITLE ...
can be set and changed at runtime.
Modification 20
Symbolic positions with SELECTION-SCREEN
statements
With all variants of SELECTION-SCREEN
which expect format specifications, you can define the position of the object on the selection screen symbolically
(POS_LOW
or POS_HIGH
for the positions where the
input fields of SELECT-OPTIONS
are output).
Modification 21
User's own keys in application toolbar
The key word SELECTION-SCREEN
FUNCTION KEY
n (n
must be between 1 and 5) allows you to activate up to five function
keys on the selection screen. You must set the texts for these at runtime. The keys appear in the application toolbar.
Modification 22
Nested blocks on selection screens
You can nest blocks defined with the language
construct SELECTION-SCREEN
BEGIN/ END OF BLOCK. For blocks in boxes, the nesting depth is restricted to 5 levels.
Modification 23
Return to the selection screen after F3 in basic list
If you use F3 to leave a basic list generated by a program (and the program
was executed from the selection screen), the system displays the selection screen again with the old contents.
Modification 24
Passing report-specific selections to the database
Report-specific selections with a reference field belonging to a
logical database table for which
dynamic selections are defined are passed directly
to the database. In exceptional cases, you can suppress this by using the addition NO
DATABASE SELECTION for the key word SELECT-OPTIONS
.
Modification 25
Simplified SELECT-OPTIONS
on the selection screen
Addition
NO INTERVALS
with SELECT-OPTIONS
and SELECTION-SCREEN
BEGIN OF BLOCK
.
You can use these additions to display and manipulate SELECT-OPTIONS
on the selection screen.
The function module SELECT_OPTIONS_RESTRICT
restricts the number of
valid selection options per SELECT-OPTIONS
at runtime. You can also switch
off the option 'E'
(= 'Exclude from selection'). This allows you to simplify the entry of selections on the selection screen.
Modification 26
Field selection.
Additions FIELDS f1 ... fn
with
GET
and
GET LATE, as well as FIELD SELECTION FOR TABLE dbtab
with SELECTION-SCREEN
.
These allow you to specify a list of fields required in the program for tables defined for this
purpose in the logical database. Only these fields are then filled with values, which leads to considerable improvement in performance.
Modification 27
Dynamic selections with SUBMIT
You can use the addition
FREE SELECTIONS ...
with SUBMIT
to pass dynamic selections directly.
Modification 28
User-specific variables in variants
User-specific values can be set for certain parameters and selection criteria intended for that purpose by the application.