ABAP Dictionary
Purpose
You use the ABAP Dictionary to create and manage data definitions (metadata). The ABAP Dictionary permits a central description of all the data used in the system without redundancies. New or modified information is automatically provided for all the system components. This ensures data integrity, data consistency and data security.

The ABAP Dictionary supports the definition of user-defined types (data elements, structures and table types). You can create the corresponding objects (tables or views) in the underlying relational database using these data definitions. The ABAP Dictionary describes the logical structure of the objects used in application development and shows how they are mapped to the underlying relational database in tables or views.

The ABAP Dictionary also provides standard functions for editing fields on the screen, for example for assigning input help to a screen field.

Integration
The ABAP Dictionary is completely integrated in an ABAP system. The ABAP system works interpretatively, permitting the ABAP Dictionary to be actively integrated in the development environment. Instead of the original objects, the interpreters see only internal representations of these objects.

These internal representations are adjusted automatically when the system finds that changes have been made in the ABAP Dictionary. This ensures that the screen and ABAP interpreters, input help, database interface, and development tools always access current data.

When you work on development projects, objects of the ABAP Dictionary can be changed any number of times before being activated and made available to the operative components of the system. Objects can have both an active and an inactive version in the ABAP Dictionary at the same time.

Inactive ABAP Dictionary objects have no effect on the runtime system (ABAP processor, database interface). This permits greater changes to several objects without impairing the executability of the system. The objects can be activated together only when they all have been changed.

Database Tables
Definition
In ABAP Dictionary, the term “database table” (or table for short) is the database-independent definition of a database table. In Open SQL, only those database tables can be accessed that are defined in ABAP Dictionary.

The name of a database table in ABAP Dictionary can have a maximum of 16 characters, can consist of letters, numbers, and underscores, must start with a letter can be prefixed by a namespace prefix (/…/) of a prefix namespace. It is in the namespace of the data types in ABAP Dictionary.

Tables can be defined independently of the database in the ABAP Dictionary. The fields of the table are defined with their (database-independent) data types and lengths.

When the table is activated, the system creates a physical table definition in the database for the table definition stored in the ABAP Dictionary.

Views
You define a view to combine data of an application that is deployed on several database tables.

Procedure
To define a view, proceed as follows:

Select the database tables of the view.
These tables must be linked by defining the join conditions. It is also possible to use the join condition from a foreign key defined between the tables.
Select the fields of the base tables that the view uses.
Formulate the selection conditions that restrict the records in the view.
Following different view types are supported:
Database views are implemented with an equivalent view of the database.
Projection views are used to hide fields of a table (only projection).
Help views can be used as a selection method in search helps.
Maintenance views allow you to maintain the data distributed to several tables for one application object at a time.

Data Types
In ABAP Dictionary, global data types can be defined that are visible for all repository objects in the current AS ABAP.

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.

Domains
Definition
A domain defines a value range. A domain is assigned to a data element. All table fields or structure components that use this data element have the value range defined by the domain. The relationship between the field or component and the domain is defined by the data element of the field or component.

Use
When you change the domain, the system automatically changes fields or components that refer to this domain (with the assigned data elements). This ensures that the value ranges of these fields or components are consistent. Fields or components that are technically the same can be combined with a reference to the same domain. In the following figure you can see an example where fields from different tables refer to a domain.

The value range of a domain is defined by specifying a data type and length (and number of decimal places for numeric data types).

Tip
A personnel number is defined by the data format NUMC and by specifying the number of places for this personnel number.

The value range of a domain can be restricted by defining fixed value. If all the fields or components that refer to the domain must be checked against a certain table, you can define this table as the value table of the domain.

You can also define output attributes for all the fields or components that refer to the domain. For more information, see Creating Domains. A conversion routine can be assigned to a domain. This conversion routine converts values from display format to internal format for the fields or components that refer to this domain.

Search Helps
Definition
Search helps are objects that you can use to assign input help (F4 Help) to screen fields. You can do this by creating a search help in the ABAP Dictionary and attaching it to the corresponding screen field.

Use
The input help (F4 help) is a standard function of the SAP system. You can display the list of all possible input values for a screen field using this help. You can enhance possible input values with further information. This is approbiate especially when the field requires the input of a formal key.

To understand the functionality of search helps in detail, you have to be familiar with the standard input help process.

Standard Input Help Process

You call an input help using the following steps (some steps can be omitted, depending on the definition of the input help):

Start the input help to display the possible input values for a field (search field) in a screen template.
The system suggests you a number of possible search paths. You have to select one of these. Each search path suggests a number of restrictions to limit the number of possible input values. These values are provided in a dialog box for value restriction when the search path is selected.
Enter the restrictions, if required, and then start the search.
The following figure shows an example that explains the first three steps.

The system determines the values that satisfy the entered restrictions (hits) and displays them as a list (hit list).
The following figure explains step 4 and step 5.

Select the most suitable line from the hit list by double-clicking it.
The value of the search field is returned to the screen template (possibly together with other values).
Note
The system omits step 2 if there is only a single search path available. In this case the dialog box for the value selection is offered immediately. You can also output the hit list directly after starting the input help. In this case the system omits steps 3 and 4.

Function of a Search Help

This standard process can be completely defined by creating a search help in the ABAP Dictionary. This search help must be assigned only to the screen fields in which it has to be available. (For more information, see Attaching Search Helps to Screen Fields.)

There are two types of search helps:

Elementary search helps
These describe a search path. The elementary search help must define the following:
Where must the data of the hit list be read from (selection method)
Which enhanced options should be provided for the search method (type-ahead and full text search)
How the exchange of values between the screen template and selection method is implemented (the interface of the search help)
How the online input help must be defined (online behavior of the search help).
Collective search helps
Collective search helps combine several elementary search helps. A collective search help can offer several alternative search paths.
Using Search Helps in Web Dynpro ABAP

You can use search helps from the ABAP Dictionary in Web Dynpro for ABAP. Additional information is available under ABAP Dictionary Search Helps.

Lock Objects
Definition
The SAP system synchronizes several users’ simultaneous access to the same data records with a lock mechanism. When interactive transactions are programmed, the system sets and releases locks by calling function modules (see Function Modules for Lock Requests). These function modules are automatically generated from the definition of lock objects in the ABAP Dictionary.

Structure
In a lock object, you must define the tables in which data records must be locked with a lock request, and the key fields of these tables. When you select the tables, you must first select the primary table. You can also add further tables (secondary tables), using foreign key relationships (see Conditions for Foreign Keys). The following figure shows a primary table and its relations with two other tables (secondary tables).

Lock Arguments

The lock argument of a table in the lock object consists of the key fields of the table.

The lock argument fields of a lock object are used as input parameters in the function modules for setting and removing locks generated from the lock object definition. When these function modules are called, the table rows to be locked or unlocked are specified by defining certain values in these fields. These values can also be generic. The lock argument fields define which subset of the table rows must be locked.

The simplest case of a lock object consists of exactly one table and the lock argument of the table is the primary key of this table. You can also include several tables in a lock object. A lock request can lock not only a record of a table, but also an entire logical object. Such a logical object can be a document comprising an entry in a header table and N entries in a position table, for example. The figure below shows the locked records in an example with three tables.

Note
Locks can also be set from programs in other systems with the corresponding interfaces if the lock object was defined with RFC authorization.
A lock mode can be assigned to each table in the lock object. This mode defines how other users can access a locked record of the table.

Adjustment of Database Structures
Use
To enable ABAP programs to access database tables correctly, the runtime object of a table must correspond to the structure of the table in the database. If the table is changed in the ABAP Dictionary, you must ensure that the database structure of the table is adjusted to the change in the ABAP Dictionary during activation (when the runtime object is rewritten). This process is clearly explained in the figure below.

Features
The database structure does not need to be changed for certain changes in the ABAP Dictionary. For example, the database table does not need to be adjusted to a change in the field sequence (except for key fields) in the ABAP Dictionary. The field sequence in the ABAP Dictionary does not have to correspond to the field sequence in the database. In this case, the changed structure is simply activated in the ABAP Dictionary and the database structure remains unchanged, but the runtime object must be rewritten.

The database structure of a table can be adjusted to its changed ABAP Dictionary definition in three ways:

By deleting and re-creating the database table
The table is deleted in the database. The revised version of the table is then activated in the ABAP Dictionary and created again in the database.
Caution
You lose the data in the table during this process.

By changing the database catalog (ALTER TABLE)
Only the definition of the table is changed in the database. Sometimes when you use ALTER TABLE, there are additional actions possible. For example, if you change a column from null to not null, you get time-intensive actions like:
UPDATE””
SET “F01″=’…’
WHERE ‘F01’ IS NULL
When you use ALTER TABLE, the data in the table is retained (for some databases, when you add a not null column, the system writes the default value into each line).
Caution
The indexes on the table have to be rebuilt.

By converting the table (for more information, see Conversion Process)
The system renames the database table and it serves as a temporary buffer for the data. The revised version of the table is activated in the ABAP Dictionary and created in the database. The data is reloaded from the temporary buffer to the new database table (with MOVE-CORRESPONDING) and the indexes on the table are built.
The procedure actually used by the system in a particular case depends on:

The type of structural change
The database system used
Whether data already exists in the table
If the table does not contain any data, the existing table is deleted in the database and recreated. If there is data in the table, the system tries to change the structure using ALTER TABLE. If the database system used cannot execute the structural change with ALTER TABLE, the table is converted.

Conversion is the most resource-intensive method of adjusting structures. However, structural changes involving changes to the database catalog can also result in costly internal data reorganizations in some database systems. For information about the processes occurring in the database for structural changes with ALTER TABLE, see your database system documentation.

Caution
You must not adjust the database structure during production. At least all the applications that access the table must be deactivated during the structural adjustment. Since the table data is not consistent during the structural adjustment (in particular during conversion), programs may behave incorrectly when they access this data.

Data Types in the ABAP Dictionary
Use
The data type in the ABAP Dictionary is the user’s view of the data, that is, the data format at the user interface. This data format depends on the database system that you use. When you define a table in the ABAP Dictionary, the data types defined in the ABAP Dictionary are copied to the data types of the database system used.

If an ABAP Dictionary object (data element, structure, table type, table, or view) is used in an ABAP program, the system converts the Dictionary data types of the object fields to the corresponding ABAP data types. You can see an example of such a conversion in the following figure.

Note
Some data types have a predefined length and set templates for output.

Existing Data Types

ACCP: Posting period. The length is set to 6 places for this data type. The format is YYYYMM. In input and output, the system inserts a point between the year and month, so the template of this data type has the format ‘____.__’.

CHAR: Character string. Fields of type CHAR can have a maximum length of 1333 in tables. If you want to use longer character fields in tables, you must choose data type LCHR. There are no restrictions on the length of such fields in structures.

CLNT: Client. Client fields always have three places.

CUKY: Currency key. Fields of this type are referenced by fields of type CURR. The length is set to 5 places for this data type.

CURR: Currency field. Equivalent to an amount field DEC. A field of this type must refer to a field of type CUKY (reference field). The maximum length for this data type is 31 places.

DATS: Date. The length is set to 8 places for this data type. The output template can be defined with the user profile.

DEC: Counter or amount field with decimal point, sign, and commas separating thousands. A DEC field has a maximum length of 31 places.

FLTP: Floating point number. The length (including decimal places) is set to 16 places for this data type.

DF34_RAW: Normalized decimal floating point number. Representation on the database based on type RAW. The values can be sorted and compared according to their numerical value, and they can be used in indexes. Database arithmetic is not available. Decimal floating point numbers of this type have 34 digits in the mantissa, and conform to the IEEE 754r standard. Valid values are numbers between 1E-6143 and 9.999999999999999999999999999999999E+6144, plus the corresponding negative numbers and zero.

DF34_SCL: Scaled decimal floating point number. The difference between this type and DF34_RAWis that DF34_SCL has an additional column of the type INT2 for the scale. This column is visible, but its value is written and read automatically. The values having this data type can be sorted and compared according to their numerical value, and they can be used in indexes. Database arithmetic is not available. The system supports up to 34 decimal digits in the coefficient. Decimal floating point numbers of this type are represented internally with 34 decimal places according to the IEEE-754 standard. Valid values are numbers between 1E-6143 and 9.999999999999999999999999999999999E+6144, plus the corresponding negative numbers and zero.

DF34_DEC: Decimal floating point number. Representation on the database with type DEC, length and number of decimal places must be specified by the programmer. The values have at most 31 digits on the database, with at most 14 decimal places. The advantage of this type is that database arithmetic is available. The disadvantage is that values are silently rounded to the specified number of decimal places when they are written into the database. An overflow can also occur when writing values into the database. In this case the system throws an ABAP-OO exception.

DF16_RAW: Normalized decimal floating point number. Representation based on type RAW. The values can be sorted and compared according to their numerical value, and they can be used in indexes. Database arithmetic is not available. The system supports up to 16 decimal digits in the coefficient. Decimal floating point numbers of this type are represented internally with 16 decimal places according to the IEEE-754r standard. Valid values are numbers between 1E-383 and 9.999999999999999E+384, plus the corresponding negative numbers plus zero.

DF16_SCL: Scaled decimal floating point number. The difference between this type and DF16_RAWis that DF16_SCL has an additional column of type INT2 for the scale. This column is visible, but the value is written and read automatically. The values having this data type can be sorted and compared according to their numerical value, and they can be used in indexes. Database arithmetic is not available. The system supports up to 16 decimal digits in the coefficient. Decimal floating point numbers of this type are represented internally with 16 decimal places according to the IEEE-754r standard. Valid values are numbers between 1E-383 and 9.999999999999999E+384, plus the corresponding negative numbers plus zero.

DF16_DEC: Decimal floating point number. Representation on the database with type DEC, length and number of decimal places must be specified by the programmer. The values have at most 15 digits on the database, with at most 14 decimal places. The advantage of this type is that database arithmetic is available. The disadvantage is that values are silently rounded to the specified number of decimal places when they are written into the database. An overflow can also occur when writing values into the database. In this case, the system throws an ABAP-OO exception.

INT1: 1-byte integer between 0 and 255. The length is set to 3 places for this data type.

INT2: 2-byte integer between -32767 and 32767. Fields of this type must be used only for length fields. The system positions these length fields immediately in front of a long field (type LCHR, LRAW). With INSERT or UPDATE on the long field, the database interface enters the length which was actually used in the length field. The length is set to 5 places for this data type.

INT4: 4-byte integer between -2147483648 and 2147483647.The length for this data type is limited to 10 places.

LANG: Language key. It has its own field format for special functions. This data type always has length 1. The language key is displayed at the user interface with 2 places, but is stored with 1 place in the database. The conversion exit ISOLA converts the display at the user interface for the database and vice versa. This conversion exit is automatically allocated to a domain with data type LANG at activation.

LCHR: Character string of any length, but has to be declared with a minimum of 256 characters. You must locate fields of this type at the end of transparent tables (in each table there can be only one such field) and must be preceded by a length field of type INT2. If there is an INSERT or UPDATE in ABAP programs, this length field must be filled with the length actually required. If the length field is not filled correctly, this leads to a data loss in the LCHR field. Fields of this type cannot be used in the WHERE condition of a SELECT statement.

LRAW: Uninterpreted byte string of any length, but has to be declared with a minimum length of 256. You must locate fields of this type at the end of transparent tables (in each table there can be only one such field) and must be preceded by a length field of type INT2. If there is an INSERT or UPDATE in ABAP programs, this length field must be filled with the length actually required. If the length field is not filled correctly, this leads to a data loss in the LRAW field. A field of this type cannot be used in the WHERE condition of a SELECT statement.

NUMC: Long character field in which only numbers can be entered. The length of this field is limited to a maximum of 255 places.

PREC: Obsolete data type. The length is set to 2 places for this data type but internally it is treated like INT2. Dynpro fields of type PREC are restricted to 2 places and must not contain a sign.

QUAN: Quantity. Equivalent to an amount field DEC. A field of this type must always refer to a units field with UNIT format (reference field). The maximum length for this data type is 31 places.

RAW: Uninterpreted byte string. Fields of type RAW may have only a maximum length of 255 in tables. If longer raw fields are required in tables, you should select data type LRAW.

RAWSTRING: Uninterpreted byte string of variable length. In the Dictionary a length can be specified for this type (at least 256 characters). This data type can be used in types (data elements, structures, table types) and domains. You can store binary data of type RAWSTRING in the database. There are restrictions; for a description of them, refer to the documentation of the ABAP statement ‘STRING’. In ABAP, this type is implemented as a reference to a storage area of variable size. The system proposes 132 characters as the default for the output length. You cannot attach search helps to components of this type.

STRING: Character string with variable length This data type can be used only in types (data elements, structures, table types) and domains. In the dictionary a length can be specified for this type (at least 256 characters). It can be used in database tables only with restrictions. For a description of them, refer to the documentation of the ABAP statement ‘STRING’. In ABAP, this type is implemented as a reference to a storage area of variable size. The system proposes 132 characters as default for the output length. You cannot attach search helps to components of this type.

SSTRING: Short character string with variable length. In the Dictionary the number of characters can be specified for this type (from 1 to 1333). This data type can be used only in types (data elements, structures, table types) and domains. It can be used in database tables. To do so, refer to the documentation of the ABAP statement ‘STRING’. In ABAP, this type is implemented as a reference to a storage area of variable size. String fields of this type can be used in indexes and in the WHERE condition of a SELECT statement. You cannot use them in table keys.

TIMS: Time. The length is set to 6 places for this data type. The format is HHMMSS. The template for input and output has the form ‘..__’.

UNIT: Unit. Fields of this type are referenced by fields of type QUAN. The length of this data type is set to 2 or 3 places.

VARC: Character field of variable length. Creation of new fields of this data type is no longer supported.

Notes
When using the numeric data types CURR, DEC, FLPT, INT2, INT4 and QUAN, you can choose whether or not a sign must be output on screens.
With the data types CURR, DEC and QUAN, the system sets commas separating thousands and decimal points. The output length (number of places plus the number of necessary editing characters such as commas separating thousands and decimal points) is greater than the specified length.
The system omits editing characters if the output length specified in the domain maintenance is too small.
The types RAWSTRING and STRING or LOBs have a variable length. You can specify a maximum length, but there is no upper limit.
The type SSTRING also has a variable length, but there is an upper limit. The maximum length is 1333. The benefit of using it, and not CHAR, is that it is assigned to the ABAP type string. Its advantage over STRING is that it can also be used for key fields in database tables.
The maximum length of data types that are based on RAWSTRING, STRING, and SSTRING can be determined using the predefined function dbmaxlen.
The maximum number of characters of the types LCHR and LRAW is the value of a precedingINT2 field in a transparent database table.
If a data type CURR, DEC, DF34_DEC, DF16_DEC, or QUAN has an even number of characters (not recommend), the length of the associated ABAP type p is rounded up and hence becomes the next highest uneven number.
The data type PREC is obsolete and you should no longer use it. In ABAP Dictionary and in ABAP programs, it is handled like INT2, despite the predefined length (2). The length 2 is relevant only for screen fields of the type PREC, which can have two-character positive values at most. The property sign cannot be set for a domain of the type PREC
Caution
A column of type DF16_SCL or DF34_SCL cannot occur in the primary key.

Pooled and Cluster Tables
Use
Table pools (pools) and table clusters (clusters) are special table types in the ABAP Dictionary. The data from several different tables can be stored together in a table pool or table cluster. Tables assigned to a table pool or table cluster are indicated as pooled tables or cluster tables.

You must use a table pool or table cluster exclusively for storing internal control information (screen sequences, program parameters, temporary data, continuous texts such as documentation). Data of commercial relevance is stored in transparent tables.

Features
Table Pools

A table pool corresponds to a table in the database in which all records from the pooled tables assigned to the table pool are stored.

The definition of a pool consists of two key fields (Tabname and Varkey) and a long argument field (Vardata). A pool has the following structure:

Field Data type Description
Tabname

CHAR(10)

Name of pooled table

Varkey

CHAR (n)

Contains the entries from all key fields of the pooled table record as a string. The maximum length for n is 110.

Dataln

INT2(5)

Length of the string in Vardata

Vardata

RAW (n)

Contains the entries from all data fields of the pooled table record as a string. The maximum length n depends on the database system used.

If you save a pooled table record, the system stores it in the corresponding table pool. The name of the pooled table is written to the Tabname field. The contents of all key fields of the pooled table are written as a string to the Varkey field and the contents of all data fields as a string to the Vardata field. The database interface enters the length of the string stored in Vardata in the Dataln field. In the following figure you can see the structure of a table pool. The figure presents an example of a table pool with two assigned pooled tables.

Constraints

Due to the structure of a table pool, there are certain restrictions on the pooled tables assigned to it:

The name of a pooled table cannot exceed 10 characters.
Since Varkey is a character field, all key fields of a pooled table must have character data types (for example, CHAR, NUMC, CLNT).
The total length of all key fields or all data fields of a pooled table must not exceed the length of the Varkey or Vardata field of the corresponding pool.
Table Clusters

Several logical data records from different cluster tables can be stored together in one physical record in a table cluster.

A cluster key consists of a series of freely definable key fields and a field (Pageno) for distinguishing continuation records. A cluster also contains a long field (Vardata) that contains the contents of the data fields of the cluster tables for this key. If the data does not fit into the long field, the system creates continuation records. Furthermore, control information about the structure of the data string is written at the beginning of the Vardata field. A table cluster has the following structure:

Field Data type Description
CLKEY1

*

First key field

CLKEY2

*

Second key field

…

…

…

CLKEYn

*

nth key field

Pageno

INT2(5)

Number of the continuation record

Timestamp

CHAR(14)

Time stamps

Pagelg

INT2(5)

Length of the string in Vardata

Vardata

RAW (n)

Contains the entries from the data fields of the assigned cluster tables as a string. The maximum length n depends on the database system used.

The records of all cluster tables with the same key are stored under one key in the assigned table cluster. The values of the key fields are stored in the corresponding key fields of the table cluster. The values of all data fields of the assigned cluster tables are written as a string to the Vardata field of the table cluster. Besides the actual data values, the data string contains information about the structure of the data and which table it comes from. If the string exceeds the maximum length of the Vardata field, the system writes a continuation record with the same key values. The continuation records for a key are distinguished by their value in the Pageno field. The actual length of the string in the Vardata field is stored in the Pagelg field by the database interface.

In the following figure, you can see the structure of a table cluster. The figure presents an example of a table cluster which contains two cluster tables.

Caution
You need the structural information stored in the ABAP Dictionary to read the data from a pooled table or cluster table correctly. These tables can only be processed using Open SQL with the cluster interface, and not with Native SQL directly in the database.