Show TOC

Logical Databases with Different Node TypesLocate this document in the navigation structure

Use

From Release 4.0A, you have the option of defining logical database nodes in various ways:

  1. Type T nodes (Dictionary tables), type Database Tables from 4.5A This type of node corresponds to the only type of node that existed prior to Release 4.0A (a flat Dictionary structure).

  2. Type S nodes (structure from the ABAP Dictionary), Dictionary Type from 4.5A. In Releases 4.0A and 4.0B, this node type makes it possible for a flat Dictionary structure to be provided with an alias name that can be chosen at will within the logical database. This is needed if the name of one of these structures is longer than the maximum length of 14 characters allowed for node names. In addition, this node type allows you to include a Dictionary structure in a logical database numerous times under different aliases. From Release 4.5A you can define complex types, meaning nested structures and table types, in the Dictionary. This node type allows you to use nodes with this kind of complex Dictionary type.

  3. Type C nodes (complex data objects); type Data type from 4.5A These types of nodes refer to an arbitrary number of complex types that are defined in a type pool. From Release 4.5A, types of this sort are better represented using complex Dictionary types. It is therefore no longer recommended that you use them in logical databases, as this leads to certain disadvantages in ABAP Query.

When defining InfoSets in Releases 4.0A and 4.0B, you may only use those logical databases containing type Database table (type T) nodes. From Release 4.5A logical databases containing both other types of nodes can also be used. There are, however, some restrictions to be taken into account.

When using nodes with complex types (Dictionary type or Data type), ABAP Query only allows you to evaluate those fields that can be addressed directly from the highest level of the type. If the complex type in question contains a table, the individual components that the table is made up of cannot be accessed. This is demonstrated in the following example.

Example

The following kind of complex type. ABAP Notation is chosen. This kind of type could also be depicted as a Dictionary Type.

TYPES: BEGIN OF person
                name(20),
                first_name(20),
                birthday(10),
        END OF person,
        BEGIN OF address,
                street(30),
                number(6),
                zipcode(10),
                city(30),
        END OF adress,
        adress_table TYPE address OCCURS 0.

TYPES: BEGIN OF personal_data,
                person TYPE person,
                first_adress TYPE address,
                other_addresses TYPE
address_table,
        END OF personal_data.
            

If the logical database node PDATA is of type PERSONAL_DATA, the following fields of this node can be evaluated using the ABAP:

  • PDATA-PERSON-NAME

    PDATA-PERSON-FIRST_NAME

    PDATA-PERSON-BIRTHDAY

    PDATA-FIRST_ADDRESS-STREET

    PDATA-FIRST_ADDRESS-NUMBER

    PDATA-FIRST_ADDRESS-ZIPCODE

    PDATA-FIRST_ADDRESS-CITY

Those fields containing information about additional addresses (OTHER_ADRESSES) cannot be evaluated because a table type is being used here.

Restrictions

Additional restrictions apply to nodes with type Data type (type C). Due to the fact that nodes of this type are not defined as ABAP Dictionary types, no long texts or headers exist for these fields. Therefore, when defining an InfoSet, you can only use the technical names of the fields as name suggestions (for example PERSON-NAME). In order for these fields to appear in the same way that all other database nodes do, you must maintain all texts for them.

Additionally, pay attention to the fact that reference field definition is not possible with nodes of type Data type since this is only allowed with Dictionary types. Because of this, ABAP Query cannot recognize values with units (currency sums or quantities), nor can it evaluate them within these nodes.