Kontakt

Ansicht
Dokumentation

Logical databases, selection screens, and variants ( RELNBC_ABAP_LDB_40 )

Logical databases, selection screens, and variants ( RELNBC_ABAP_LDB_40 )

Fill RESBD Structure from EBP Component Structure   PERFORM Short Reference  
This documentation is copyright by SAP AG.
SAP E-Book

Short text

Logical databases, selection screens, and variants

Description

Release 4.0 contains the following new features:

  1. Logical databases
    1. Namespace extension
    2. Logical nodes
    3. Search help instead of matchcode objects
  2. Selection screens
    1. CALL SELECTION-SCREEN
    2. Additional functions in dynamic selections
  3. Variants
    1. Screen-specific variants
    2. Importing subobjects
    3. Suppressing SPA/GPA handling
    4. System variants, transporting variants
    5. User variables

1a. Namespace extension

As part of the namespace extension in Release 4.0, the names of logical databases have been extended to 20 characters. The namespace prefix, enclosed in forward slashes ('/'), has a maximum length of 10, including the separators '/'.

Examples of valid names:
KDF ; verylong_NAME ; /Firm/kdf verylong_NAME ; /Firm123/My_name

Examples of invalid names:
/Firm_My_name ; /This/Name_is_too_long ; /COMPANYNAME/KDF ;
('/' missing) (total length > 20) (Prefix > 10)

Application identification codes no longer exist in Release 4.0.

The name of the database program is made up of 'SAPDB' plus the name of the logical database. In the selection include, the name of the logical database comes between 'DB' and 'SEL'. The name is prefixed.

Examples: Logical database -> Database program
Selection include

F1S -> SAPDBF1S
DBF1SSEL

/Firm/My_Name -> /Firm/SAPDBMy_Name
/Firm/DBMy_NameSEL

For further information, see the namespace documentation.

1b) Logical nodes in logical databases

The old logic, by which logical databases only worked with tables that were based in the ABAP Dictionary, has been replaced by the concept of logical nodes:

A node of a logical database may have a name of up to 14 characters long.

There are currently three possible node types:

  • T (Table): The name is the name of a Dictionary structure. In this case, as before, the TABLES work area serves as a common data area for the database program and the report. Only table names can be used here, these must be less than 15 characters long.
  • S (Structure): Can have any name. A Dictionary structure is assigned. The work area is created with DATA in COMMON PART. You can also use Dictionary structures with this type, whose names are longer than 14 characters.
  • C (Complex data object): Can have any name. The name of a type is assigned. The work area is created with DATA in COMMON PART.

Examples:

Node SPFLI, type T
PUT SPFLI -> GET SPFLI fills the work area created using TABLES SPFLI

Node HUGO, type S, structure SPFLI
PUT HUGO -> GET HUGO fills the field HUGO LIKE SPFLI.

Node OTTO, type C, type RSDS_WHERE
PUT OTTO -> GET OTTO fills the field OTTO TYPE RSDS_WHERE.

Conversion of previous logical databases

All existing logical databases were converted such that all nodes received type T. Thus both the logical databases and the reports that they use can run exactly as they always have, all new changes are one hundred percent compatible.

Activation of a node

Up until now, nodes in database progams and reports were activated by TABLES . During this process a work area was created and all objects belonging to the database (PARAMETERS, SELECT-OPTIONS, SELECTION-SCREEN objects) that were part of or part of a table above in the logical database's hierarchy were reported to the program and, if need be, taken into account during selection screen generation.

This is now taken care of by the new keyword NODES . Both variations (NODES or TABLES ) are allowed with type T nodes.

Examples: (with the nodes from above)

NODES SPFLI. (or TABLES SPFLI.)
creates a TABLES work area for SPFLI
activates all database-specific objects for SPFLI and the nodes above it

NODES HUGO.
creates the data object (in COMMON PART):

DATA HUGO LIKE SPFLI activates all database-specific objects for HUGO and the nodes above it

NODES OTTO.
creates the data object (in COMMON PART):

DATA OTTO TYPE RSDS_WHERE activates all database-specific objects for OTTO and the nodes above it

Database-specific objects for type S/C nodes

PARAMETERS and SELECTION-SCREEN objects are assigned to a node using the addition FOR NODE (instead of FOR TABLE as was done up until now).
Either FOR NODE or FOR TABLE can be used for type T nodes.

'LIKE' fields allowed in the PARAMETERS statement

The following 'LIKE' fields f can be can be used in the ABAP statement PARAMETERS p like f:

  • a node field, but only at the highest level with node type C
  • a dictionary field or dictionary structure

Examples:

Allowed for f:
SPFLI-CARRID (node field for SPFLI)
HUGO-CARRID (node field for HUGO)
OTTO-TABLENAME (node field for OTTO at the highest level)
HUGO (node)
SFLIGHT-CONNID (dictionary field)

Generally type F (Floating Point) reference fields and deep type reference fields are only allowed with the addition NO-DISPLAY.

Fields in the SELECT-OPTIONS statement

In the ABAP statement SELECT-OPTIONS sel FOR f, f can be a

  • node field, but only at the highest level if of node type C.

Examples:
Allowed for f:
SPFLI-CARRID (node field for SPFLI)
HUGO-CARRID (node field for HUGO)
OTTO-TABLENAME (node field for OTTO at the highest level)

Not allowed:
SFLIGHT-CONNID (not a node field)
Deep type fields are not allowed with SELECT-OPTIONS. Floats,
as with parameters, are only allowed with the addition NO-DISPLAY.

Advantages of logical nodes

  • The same Dictionary structure can be used for several nodes:
  • 'Secret' reading of additional information before PUT can now be made explicit by giving the node a complex type designation. These objects are then no longer overlooked by tools like query, dynamic selections or variants, at least in the long-term.
  • All database program naming conventions used up until now are retained: FORM PUT_ as well as FORM AUTHORITYCHECK_
    With names containing thirty characters or more this would have led to syntax errors and would have meant either an incompatible change or would have prohibited the use of long table names in logical databases.

1c. Search helps instead of matchcode objects

From Release 4.0, the matchcodes have been replaced by search helps. This has the following consequences for logical databases:

In the database program coding, the FORM routine and table identifiers have been slightly changed (see documentation for maintenance transaction of logical databases).

The display in the selection screen has been slightly changed. A button for complex search help selection has been added. You can find more detailed information in the documentation.

2a)

From 4.0, selection screens can be defined in all programs (apart from subroutine pools). These selection screens are defined via

SELECTION-SCREEN BEGIN OF SCREEN nnnn.

SELECTION-SCREEN END OF SCREEN nnnn.

nnnn is a number less than 9999 and not equal to 0 or 1000. In the selection screen, you can create objects as before using the PARAMETERS or SELECT OPTIONS instruction. You can include objects from a selection screen already defined in the program in the current selectionscreen using INCLUDE.

Example:

SELECTION-SCREEN BEGIN OF SCREEN 100.
PARAMETERS: PAR1 like ...
SELECT-OPTIONS: SEL1 for ....
SELECTION-SCREEN BEGIN OF BLOCK block1.
PARAMETERS: par2 like .....
SELECTION-SCREEN END OF BLOCK block1.
SELECTION-SCREEN END OF SCREEN 100.

SELECTION-SCREEN BEGIN OF SCREEN 2100.
SELECTION-SCREEN INLCUDE BLOCKS block1.
SELECTION-SCREEN INCLUDE par1.
SELECT-OPTIONS SEL2 for ....
SELECTION-SCREEN END OF SCREEN 2100.

The selection screens can be called as an initial screen for SUBMIT
SUBMIT......USING SELECTION-SCREEN nnnn
or, for example, as a dialog box using F4 to limit the values displayed.
This means that it is no longer necessary to start a report in order to see a selection screen.

Please refer to the online documentation for SELECTION-SCREEN for more information.

2b)
Dynamic selections now also support fields without reference to the
Dictionary, as well as Floating Point type fields.

You can now also control the selection screen with the events
AT SELECTION-SCREEN ......

You can now call dynamic selections as a dialog box. Please refer to the online documentation for SELECTION-SCREEN for more information, or to the function module documentation FREE_SELECTIONS_INIT and FREE_SELECTIONS_DIALOG.

3a)

Variants can now be explicitly defined for one or more selection screens.

3b)

Parameters/Select options can be completely exempted from the variant (Variant attributes -> Without values), which means that their content is no longer stored with the variant. At runtime, the old contents are not changed when the variant is imported.

Example:

PARAMETERS: DATE FOR SY-DATUM DEFAULT SY-DATUM.

In the variant, the field DATE is not filled with values (contents initial value). If you start the program using a variant, the DATE field will contain the respective date.

3c)

SPA/GPA handling can be switched off for PARAMETER/SELECT-OPTIONS in the variant. It is thus possible to store explicit initial values for objects with memory ID and - irrespective of the coincidental value of the SPA/GPA parameter - to store them at runtime.

3d)

System variants (starting with SAP& and CUS&) will only be created in client 000 from 4.0. However, they can be used in all other clients, for example for SUBMIT.

3e)

Dynamic selections can now also be filled using variables (Variant attributes -> Selection variables).






Addresses (Business Address Services)   ABAP Short Reference  
This documentation is copyright by SAP AG.

Length: 11543 Date: 20240603 Time: 043205     sap01-206 ( 144 ms )