- Data Types
In ABAP Dictionary, global data types can be defined that are visible for all repository objects in the current AS ABAP and are usable as part of the package concept.
The possible data types in ABAP Dictionary are:
- Data elements for elementary data types and reference types
- Structures that can comprise any other number of data types.
- Table types with any row type
In ABAP programs, the TYPE addition of declarative statements reference the data types in ABAP Dictionary. Here, data elements work like elementary ABAP types, structures work like structured ABAP types, and table types work like corresponding ABAP types. The elementary components of each data type in ABAP Dictionary are based on a set of predefined types in ABAP Dictionary for which a mapping to the predefined ABAP types is defined. If a data type is changed in ABAP Dictionary, all consumers are modified automatically.
The name of a data type
- can have a maximum of 30 characters,
- can consist of letters, numbers, and underscores,
- must start with a letter,
- can be introduced using a namespace prefix (/.../) of a prefix namespace.
All types created in ABAP Dictionary, including database tables and views, are in a namespace that covers the entire current AS ABAP. Domains, on the other hand, are in a separate namespace, which enables them to have the same name as, for example, a data element.
Alongside its technical attributes, a data type in ABAP Dictionary can have semantic information, such as documentation texts, texts for use on UIs, or associations with search helps. Data types without semantic attributes can also be declared in groups known as type groups.
Notes
- In addition to the classic data types of the ABAP Dictionary, the CDS entities of ABAP Dictionary also display data types, which can be used as such in ABAP programs.
- As well as in ABAP Dictionary, global type declarations are also possible in classes and interfaces. Data types should always be created in a context that meets the requirements in question, while also encapsulating as much as possible. See also the associated programming guidelines.
- A data type in ABAP Dictionary should always be used in accordance with its semantic attributes. Elementary data types in ABAP Dictionary in particular should never be selected only on the basis of their technical attributes. See also the associated programming guidelines.
- Namespace prefixes can be used to prevent namespace conflicts.
- Within a program, locally defined types obscure global types from ABAP Dictionary with the same name.
Example
A data type defined in ABAP Dictionary, such as the structure DEMO_CONN, can be referenced in the parameter interfaces of global procedures (methods or function modules) and in the ABAP programs that use the procedures.
CLASS cl_demo_class DEFINITION.
PUBLIC SECTION.
CLASS-METHODS demo_meth
IMPORTING
para TYPE demo_conn .
ENDCLASS.
DATA structure TYPE demo_conn.
START-OF-SELECTION.
cl_demo_class=>demo_meth( structure ).
CLASS cl_demo_class IMPLEMENTATION.
METHOD demo_meth.
...
ENDMETHOD.
ENDCLASS.
Example
The elementary components of the structure SYST describe the ABAP system fields. The semantic attributes of these components or the data elements used for them are designed for system fields used internally in programs. It is not recommended that these components or their data elements are used for other purposes, such as dynpro fields or Web Dynpro fields, just because their technical attributes are right. Their semantic attributes, in particular their text descriptions and documentation, are not usually suitable for UIs. If there are no types with suitable semantic attributes that can be reused, new data types must be created.
- Data Elements
A data element in ABAP Dictionary defines an elementary data type or a reference type and describes, alongside the technical type attributes, the semantic meaning of an object defined with reference to the data element. Data elements are the elementary parts of complex types such as structures, table types, or database tables. An internal program object declared with reference to a data element always has one of the elementary predefined ABAP types. The type in question is defined by the mapping of the predefined types in ABAP Dictionary to ABAP types.
- Technical Attributes of Data Elements
- Semantic Attributes of Data Elements
Note
The technical attributes of a data elements can be described either directly or by using a reusable domain. This is why the concept is known as a two-level domain concept.
- Technical Attributes of Data Elements
A data element describes an elementary data type or a reference type with the following technical attributes:
1. Elementary type
A data element that describes an elementary type has a predefined data type from ABAP Dictionary, a length, and an (optional) number of fractional digits as its technical attributes. These technical attributes are defined either directly in the data element or are applied from a domain.
2. Reference type
A data element that describes a reference type is either a type for a data reference variable or for an object reference variable.
➨ The static type for a data reference variable is either the generic type DATA, any data type from ABAP Dictionary (including database tables or views), or a directly specified predefined data type.
➨ The static type for an object reference variable is either the generic type OBJECT or a global class or
global interface from the class library.
Note
When existing data elements are modified, all consumers of the data element are also affected. In particular, foreign keys can become inconsistent when used for fields of database tables, which makes conversions necessary.
Example
The data element S_CONN_ID takes its technical attributes (data type NUMC, length 4) from the domain S_CONN_ID. The data element S_CONN_ID has documentation and further texts that describe its semantics. It is used as a data type of many table fields, such as the column CONNID of the database tables SPFLI, SBOOK, and SFLIGHT, that match these semantic attributes.
- Semantic Attributes of Data Elements
The semantic attributes of data elements are mainly significant when they are used as types of dynpro (or Web Dynpro) fields. The only exceptions to this are the default component name and the flag for the change document. ABAP data objects declared with reference to a data element ignore the semantic attributes of the element.
1. Short text
The short text assigned to a data element appears as a header in the field help of all dynpro fields or Web Dynpro fields defined with a direct or indirect reference to the data element.
2. Field label
The short, medium, and long field labels assigned to a data element, plus a header, can be created where appropriate as descriptions or column headers of lists for fields on the screens of dynpros or Web Dynpros with direct or indirect reference to the data element. A freely definable maximum length with varying upper limits for the different field labels is applied to all languages and must be set accordingly.
3. Documentation
The documentation created for a data element appears by default as field help for all dynpro fields or Web Dynpro fields defined with a direct or indirect reference to the data element. If no documentation was created, only the short text appears.
4. Supplement documentation
Additional supplement documentation objects can be created for a data element, with each documentation object identified by a four-digit number. This supplement documentation can be used for program-specific and dynpro-specific field helps. The assignment of supplement documentation to a dynpro field is saved in the database table THLPF.
5. Documentation status
The status of the documentation for a data element can be noted as follows for any check tools:
➨ Object is documented
The default setting, indicating that the data element requires documentation.
➨ Object not used on a screen
The data element is not implemented for dynpro fields or Web Dynpro fields and no further documentation is required.
➨ Object is documented by its short text.
The short text provides enough documentation.
➨ Documentation is currently on hold
The data element requires documentation but it does not yet exist.
6. Search help
A data element with an elementary data type can be assigned a search help and a parameter can be passed to this search help. This search help is used for the input help of all dynpro fields or Web Dynpro fields defined with direct or indirect reference to the data element, unless the dynpro field is itself associated with a search help. Search helps cannot be assigned to a data element with a reference type.
7. SPA/GPA parameter
A data element with an elementary data type can be associated with an SPA/GPA parameter. Dynpro fields defined with direct or indirect reference to the data element are filled with the content of the parameter, unless the dynpro field is itself associated with an SPA/GPA parameter. A data element with a reference type cannot be associated with an SPA/GPA parameter.
8. Flag for input history
The flag for the input history defines whether the SAP GUI history is active for dynpro fields defined with direct or indirect reference to the data element. This makes it possible to switch the input history off for sensitive fields.
Flag for bidirectional fonts
This flag defines the behavior of dynpro fields or Web Dynpro fields defined with direct or indirect reference to the data element when handling bidirectional fonts (such as Hebrew or Arabic).
➨ Writing direction
This flag can specify the writing direction of a dynpro field as "From left to right", which overwrites the direction "From right to left" specified by logons in a bidirectional font. This flag can be useful for fields with numeric texts.
➨ BIDI filter
This flag can be used to prevent the Unicode formatting characters that specify the writing direction of bidirectional fonts in data transports between GUI and AS ABAP from being filtered out, regardless of the global system settings. The global system setting is made in the program I18N_SET_DATAELEMENT_FLAGS.
9. Default component name
The default component name of a data element is a naming suggestion for structure components or table fields defined with reference to this data element. Structures used in APIs in particular should use this proposal.
10. Flag for change document
The flag for change documents specifies whether changes to fields in database tables defined with reference to this data element are logged when change document objects are involved. A change document object groups multiple tables and is used to generate function modules that can be integrated into ABAP programs and that log changes. This flag cannot be set for data elements with a reference type.
11. Further semantic attributes can be defined in the domain referenced by a data element.
The texts in the semantic attributes (the short text, field labels, and documentation) are, like all AS ABAP texts, passed to the translation tools.
Note
It is highly significant that many semantic attributes of a data element define the behavior of dynpro fields or Web Dynpro fields. For example, a data element whose documentation describes the internal attributes of a technical type is not usually suitable for use in UI fields. One example are the data elements SYST_... that define the components of the system structure SYST. The documentation of these data elements describes the corresponding system fields and must not appear on a UI. Ideally, separate data elements are created with their own semantic attributes for UIs and database tables. Any data elements not used for UI fields do not usually need semantic attributes (except for the short text and possibly documentation). Conversely, attributes such as the flag for change documents are not relevant for data elements for UIs.
- Domains
A domain is a standalone dictionary object that defines technical and semantic attributes of elementary data types. Data elements can be defined with reference to a domain and inherit its attributes. Domains can only be used in data elements.
- Technical attributes of domains
- Semantic attributes of domains
Notes
- Domains are located in a different namespace from data types. A domain can have the exact same name as a data type and, more particularly, a data element.
- Redundant domains within an application component or a package should be avoided. Domains that only have technical attributes must be created as reusable domains in central basis packages. One example is the domain CHAR255.
- The fixed values of a domain can be used as special literals in CDS views as well as the full domain being used in data elements.
- Technical Attributes of Domains
The only technical attribute of a domain is the description of an elementary data type whose technical attributes
- predefined data type in ABAP Dictionary,
- length, and
- a number of decimal places (optional)
are defined directly in the domain.
Note
When existing domains are modified, all users of the domain are also affected. In particular, foreign keys can become inconsistent when used for the fields of database tables, which makes conversions necessary.
- Semantic Attributes of Domains
Domains can be given the following semantic attributes:
1. Short text
Each domain has a short description specified when it is created.
2. Documentation
A domain can be given (optional) documentation.
3. Output attributes
The output attributes determine how fields defined with reference to a data element (that itself references the domain) are displayed on dynpros or Web Dynpros or when formatted with the statements WRITE or WRITE TO.
➨ Output length
The (optional) output length overrides the implicit output length as assigned to the predefined elementary data types. The potential output length is determined by the data type and is checked by ABAP Dictionary. If a format is assigned to the predefined data type in question, the output length should be long enough for all formatting characters.
➨ Output style
A domain with the type of a decimal floating point number must be assigned an output style.
➨ Conversion routine
If a domain is assigned to a conversion routine, the associated function module ..._INPUT (for each input in a dynpro field defined with reference to a data element that itself references the domain) is called. Similarly, the associated function module ..._OUTPUT (for each output using a dynpro field defined with reference to a data element that itself references the domain) is also called. The function module ..._OUTPUT is executed in the same way when a data object is formatted using WRITE or WRITE TO when the data object is declared with reference to a data element of this type.
➨ Sign
If a data type of a dynpro field defined in ABAP Dictionary is numeric, the "Sign" attribute must be set so that negative numbers can be displayed on the screen. This attribute can only be specified using a domain.
➨ Lowercase letters
If a data type of a dynpro field defined in ABAP Dictionary is character-like, the "Lowercase Letters" attribute can be set so that these letters are not transformed to uppercase. This attribute can only be specified using a domain.
➨ Time format
For the data type TIMS, a 24-hour or 12-hour format can be set for displaying dynpro fields in accordance with the ABAP time formats.
4. Value range
Value ranges can be defined for domains of the predefined types CHAR, NUMC, DEC, INT1, INT2, INT4, and INT8. For domains of the types CHAR and NUMC, this range specifies the valid input values in dynpro fields defined with reference to a data element of a the domain in question. The value range is evaluated for all types for the input help of dynpro fields if no input help with a higher priority exists The value range is ignored for the content of data objects in ABAP programs or of database table fields that reference a data element with a domain of this type. A value range can be defined using
➨ fixed values and
➨ intervals
Fixed values and intervals can be combined as required. The following can be specified as fixed values and interval boundaries:
➨ Alphanumeric characters including blanks and special characters for the type CHAR. The length is restricted to 10.
➨ Positive integers (including 0) for the types NUMC, INT1, INT2, INT4, INT8, and DEC.
A short text can be specified for each fixed value or interval, which is then displayed when used in an input help. The fixed values of a domain can be specified as special literals in a CDS view.
5. Fixed value append
A fixed value append is an enhancement of the standard SAP system performed in customer systems that does not make any modifications and that is respected by upgrades. A fixed value append adds further fixed values or intervals to the value range of a domain. A domain can have more than one fixed value append.
6. Value table
A value table can be a database table that is used as a default for the check table in cases where a table field of a database table that references a data element with this domain is included in a foreign key. Just specifying a value table does not trigger a check.
Example
The domain S_CLASS with the type CHAR describes the possible classes in a flight booking. The value range of the domain is defined by the fixed values "C" (Business Class), "F“ (First Class), and "Y“ (Economy Class). This means that only the values "C", "F", and "Y" can be entered for all dynpro fields that point to this domain.
- Structures
A structure in ABAP Dictionary defines a structured type that contains other data types as components. These components can be:
- Elementary data types
- Reference types
- Structured types
- Table types
A structure that contains other structures as components is called a nested structure. Structure components are substructures and substructures can themselves be nested. A structure that contains a reference type or a table type as a direct or nested component is a deep structure. A structure that contains only elementary data types as a direct or nested component is a flat structure. An internal program object declared with reference to a structure is a data object structured correspondingly (or structure for short).
- Technical attributes of structures
- Semantic attributes of structures
A structure in ABAP Dictionary can be included in another structure as an include structure, with the components of the included structure being added as the components of the including structure.
Notes
- The data types of database tables and classic views are all flat (not nested) structures.
- A CDS entity (CDS view or CDS table function) also represents a structured type and can be used as this sort of type in ABAP programs but not in ABAP Dictionary.
- Mesh types cannot currently be defined in ABAP Dictionary.
- Customizing includes and append structures are available for making enhancements to structures in ABAP Dictionary delivered by SAP, without making modifications.
- Structures are edited using a source code-based editor in the ABAP Development Tools (ADT). Here, the structures can be created or edited using a syntax based on the ABAP CDS DDL.
Example
The structure SOADDRESS for the address of a SAPoffice user is a nested structure with substructures.
- Technical Attributes of Structures
A structure describes a structure type with the following technical attributes:
1. Component name
The name of a component can have a maximum of 30 characters, can contain only letters, numbers, and underscores, and must start with a letter or a namespace prefix. If a structure is inserted in a database table, however, the component names cannot have any of the reserved names that are not permitted in database tables.
2. Component type
- For elementary components, the technical attributes ( predefined data type, length, and any fractional digits) are defined with reference to a data element for an elementary type in ABAP Dictionary or directly in the structure component.
- For reference-like components, the technical attributes are defined by reference to a data element that describes a reference type or directly in the structure component. When specified directly, data references can be defined by reference to any data type in ABAP Dictionary or to the generic type DATA. Object references can be defined by reference to classes or interfaces in the class library or to the generic type OBJECT,
- Substructures are defined by reference to structures, database tables, or views in ABAP Dictionary. A substructure can be defined as a static box. In ABAP data objects declared with reference to the structure in ABAP Dictionary, a static box supports initial value sharing.
- Tabular components are defined by reference to a table type in ABAP Dictionary.
3. Enhancement category
The enhancement category of a structure specifies how a structure can be enhanced using customizing includes or append structures and dictates how ABAP programs that work with data objects of this structure type are checked,
4. Activation type
An activation type can be defined for a structure, like for database tables, but has no specific use here.
Notes
- In ABAP, the component names of structures are not strictly speaking a technical type attribute. They are listed here however to simplify the picture.
- The above rules for component names are checked strictly by ABAP Dictionary for table fields of database tables only and not for structures. Component names of structures can contain special characters (such as :) that prevent the component from being addressed in an ABAP program. For this reason, only those component names should be used that comply with the above rules.
- A substructure cannot be defined using a reference to a CDS entity. However it can be defined using a reference to a CDS database view of a CDS view.
- Enhancement Category of Structures
ABAP Dictionary structures and database tables that are delivered by SAP can be enhanced using customizing includes or append structures. These types of changes cause problems if the enhancements change the structure fragment view.
For this reason, structures and database tables are classified, which makes it possible to recognize and handle problems related to structure enhancements. This classification is used during in the program check to create a warning at all points where the program works with structures, and where later structure enhancements can cause syntax errors or changes in program behavior. When a structure or a database table is defined in ABAP Dictionary, the enhancement categories that are displayed in the following table can be used as a classification.
| Category | Meaning |
| Unclassified | The structure does not have an enhancement category. |
| Cannot be enhanced | The structure must not be enhanced. |
| Can be enhanced and character-like | All structure components and their enhancements must be character-like and flat. |
| Can be enhanced and character-like or numeric | All structure components and their enhancements must be flat. |
| Can be enhanced in any way | All structure components and their enhancements can have any data type. |
The warnings displayed after the program check are classified into three levels from the following table, depending on the consequences of the permitted structure enhancements.
| Type of Check | Meaning |
| Syntax check | An enhancement that exhausts the enhancement category of the structure in question in full produces a syntax error. |
| Extended check | Permitted enhancements can produce syntax errors, but not always. |
| Extended check | Permitted enhancements cannot produce syntax errors, although changes to program behavior do produce semantic problems. |
Example
If the structure ddic_struc in ABAP Dictionary is defined only with flat components but is classified as Can be enhanced in any way, the following program section produces a warning in the syntax check. If the structure were to be enhanced by a deep component after the program was delivered, the program would have incorrect syntax and would no longer be executable. This is why, in this case, either the structure ddic_struc must be classified in ABAP Dictionary as Can be enhanced and character-like or else the offset/length cannot be specified in the program.
DATA: my_struc TYPE ddic_struc,
str TYPE string,
off TYPE i,
len TYPE i.
...
str = my_struc+off(len).
- Semantic Attributes of Structures
Structures in ABAP Dictionary can be given the following semantic attributes:
1. Short text of the structure
Each structure has a short description specified when it is created.
2. Documentation
A structure can be given (optional) documentation.
3. Short text of components
Each component is assigned a short text description used in any references to an existing type. A custom text can be specified if the type is defined directly.
4. Output style of components
A component with the directly specified type of a decimal floating point number can be assigned an output style for dynpros.
5. Reference field for components of the predefined data types CURR and QUAN
A component of the same or a different structure (or database table or view) must be defined as a reference field (with the predefined data type CUKY or UNIT) for each currency field with the type CURR and quantity field with the type QUAN. This field is the currency key or unit key that specifies the currency or the unit. A table in which a reference field is defined is called a reference table.
6. Check table
Like table fields of database tables, structure components can be assigned check tables. This is useful for structures included in database tables and which become part of the their foreign keys.
7. Search help
Structure components whose data type is specified by a data element with elementary data type can be assigned a search help. This is only useful, however, for components used for input fields on UIs.
8. Key field and flag for initial value
Like table fields of database tables, structure components can be defined as key fields and can be assigned a flag for initial values. This is relevant for structures that are bound into database tables. The table fields are then given these attributes. Components of structures used as lock parameters in a lock object must continue to be defined as key fields.
Note:
Structure components whose type is defined using data elements and not by being defined directly have the additional semantic attributes of the data elements.
- Include Structures
Components of a structure can be defined by including the components of other structures in ABAP Dictionary, including database tables or views. These included structures are known as include structures (or includes for short). From a technical perspective, the structure in which an include structure is included references the included structure and is modified accordingly whenever changes are made to this structure. An include structure can itself contain include structures, with the maximum nesting depth being nine includes.
When an include structure is included, all components of an existing structure are added to the including structure as a replacement for a component. No substructure is created, which means that the components are inserted as if they were specified individually at this position and they are handled like directly defined components. Regular components and include structures can be combined as required.
When a structure is included as an include structure, it can be assigned a name of a group and a three-character suffix.
➨ In ABAP programs, the name of a group is an additional addressing option for data objects declared with reference to the structure. All components of the included structure can be addressed together using this name or individual components can be addressed using the structure component selector (-) after the name.
➨ A suffix is appended to the component name to rename each component and avoid naming conflicts between components. The original name of a component of an include structure included in a structure with a suffix cannot have more than 27 characters.
Group names and suffixes are assigned in the same way as with the additions AS name [RENAMING WITH SUFFIX suffix] of the statement INCLUDE TYPE in ABAP programs. Unlike in the statement INCLUDE TYPE, an include structure in ABAP Dictionary can have a suffix without a specified name.
The fields of an included include structure are still part of the structure. They can only be edited using the structure and any changes made to the structure are applied to all including structures. The fields of an included include structure can also be transformed to direct fields of the including structure that are then no longer associated with the originally included structure.
Notes
➨ The potential for naming conflicts between components when including structures makes these actions highly error-prone, particularly in any enhancements made to the included structure. If possible, substructures should be used instead. If this is not an option (for example, in database tables), suffixes should be used to avoid naming conflicts.
➨ Including structures should not be confused with the adding of components as performed in ABAP Dictionary. Here, the definition of the components is simply copied to a different structure and no binding is persisted. In the same way, an existing include can be resolved to individual component definitions.
➨ The name of a group is just an additional addressing option and does not resolve any naming conflicts. In particular, group names in statements like MOVE-CORRESPONDING or SELECT INTO CORRESPONDING are ignored. Components renamed with a suffix, on the other hand, really do have this name and are not ignored.
➨ A CDS entity (CDS view, CDS table function) cannot be included as an include structure. A CDS database view of a CDS view can, however, be included.
Example
The structure DEMO_WEEK includes the structure DEMO_DAY five times as an include structure with group names and suffixes. The program DEMO_INCLUDE_STRUCTURE shows how its components can be accessed in ABAP.
- Table Types
A table type in ABAP Dictionary defines the data type of an internal table in ABAP. The table type specifies
➨ the row type
➨ the table category
➨ the table key
of an internal table. An internal program object declared with reference to a table type is an internal table of this type.
➨ Technical attributes of table types
➨ Semantic attributes of table types
Note:
Unlike in data elements and structures, the meaning of the table types in ABAP Dictionary consists only of creating globally visible definitions of internal tables. Table types replace the definition of internal tables in type groups and can themselves be replaced using the declaration of internal table types in global classes and interfaces, if the context where the type is required is suitable. The attributes of an internal table that can be defined in ABAP Dictionary match in full those that can be specified using the statement TYPES ... TABLE OF in ABAP programs.
Example
The table type SPFLI_KEY_TAB describes a hashed table with the structured row type SPFLI with a unique primary key and two non-unique secondary table keys.
- Technical Attributes of Table Types
A table type describes an internal table with the following technical attributes:
1. Row type
The row type can be defined as follows:
➨ Any row type can be defined by referencing any data type, including database tables and classic views in ABAP Dictionary.
➨ Elementary or reference-like row types can also be specified by using their technical attributes directly. This is done in the same way as with data elements or structure components.
2. Table category
The table category can be specified as follows:
➨ Standard table
➨ Sorted table
➨ Hashed table
➨ Index table as a generic table category for standard tables and sorted tables
➨ Any table as a generic table category for all table categories
These methods are the same as defining the table category using the statement TYPES.
3. Table key
The following can be defined as table keys:
➨ A primary key as a primary table key. The primary key is either the standard key, the entire table row if this is not a table type or does not contain a table type as component, or is defined using individual components of a structured row type in the relevant order. A primary key of sorted tables and hashed tables can be given a unique alias name from the namespace of the secondary keys. It is not currently possible to specify an empty primary table key explicitly in ABAP Dictionary. Depending on the table category, the primary key is either unique or non-unique (and cannot be specified at all in the case of generic table categories). If no primary key is specified or its uniqueness is not defined, the table type is generic with respect to this attribute.
➨ Up to 15 secondary keys as secondary table keys. Each secondary key has a unique name, which cannot be PRIMARY_KEY or LOOP_KEY, and is either a sorted key or a hash key. Sorted keys can be either unique or non-unique and a hash key is always unique. A secondary key is defined either by the entire table row if this is not a table type or does not contain a table type as component, or is defined using individual components of a structured row type in the relevant order. Using the additions WITH or WITHOUT FURTHER SECONDARY KEYS of the statement TYPES, it is possible to define explicitly whether the table type is generic with respect to the secondary keys.
4. Initial row count
This is information for internal memory management of internal tables and corresponds to the addition INITIAL SIZE in the declaration of an internal table in an ABAP program.
Notes:
1. Generic table types (namely table types for which one more attributes are generic) can only be used in ABAP for generic typings of formal parameters or field symbols.
2. A row type cannot be defined using a reference to a CDS entity. However it can be defined using a reference to a CDS database view of a CDS view.
- Semantic Attributes of Table Types
Table types in ABAP Dictionary can be given the following semantic attributes:
1. Short text of the table type
Each table type has a short description specified when it is created.
2. Documentation
A table type can be given (optional) documentation.
3. Short description of a secondary key
Each secondary key has a short description specified when it is created.
- Ranges Table Type
A ranges table type is a table type for a ranges table. A ranges table is a standard table with a standard key and a specially structured row type for use in a general logical expression with the relational expression IN seltab or after WHERE in Open SQL with the relational expression IN seltab. In ABAP Dictionary, ranges table types are created using the statement TYPES ... RANGE OF.
The data types of the components SIGN and OPTION are the data elements DDSIGN and DDOPTION. The data type for the components LOW and HIGH must be elementary and can be specified directly as a predefined data type or using data element.
The structure of the ranges table must be a standalone structure in ABAP Dictionary. When a ranges table type is defined, it can be created from the types specified for the components LOW and HIGH.
Notes:
1. In ABAP programs, ranges tables can also be defined with reference to data types other than elementary data types.
2. In ABAP programs, the structure of a ranges table does not need to be a standalone structure.
- Type Groups
A type group is an ABAP program managed by ABAP Dictionary that is initiated by the statement TYPE-POOL and that contains ABAP statements for defining globally visible data types, constants, and macros. More information about type groups can be found under ABAP Program Types and under the statement TYPE-POOL. A type group and its types, constants, and macros do not have any semantic attributes except a short text and any comments in the source code. The name of a type group can have a maximum of five characters, can contain only letters, numbers, and underscores, and must start with a letter.
Notes
- Types in type groups are the predecessors for general type definitions in ABAP Dictionary, which include reference types and table types alongside elementary data types.
- Since it is possible to also define data types and constants in the public visibility section of global classes or in interfaces, type groups are obsolete and should no longer be created. Existing type groups can still be used.
- One drawback of type groups are their missing semantic attributes when compared to the other dictionary objects. These attributes can also be defined in global classes.
- The name of a type group can also be prefixed with a namespace prefix (/.../) of a prefix namespace. This prefix can have a maximum of four characters.
Example
One type group often used in ABAP programs is ABAP itself, which contains many low-level types and constants. The drawback of this group is that the entire type group must be loaded, even if only a few types and constants are needed, such as the type abap_bool and the associated constants abap_true and abap_false.
No comments:
Post a Comment