A look on DATA DICTIONARY

DATA TYPES AND DATA OBJECT:

To work with data at runtime, you need to store it in the program at runtime and address it from your program. The system needs to know the type of the data (for example, character string, whole number, table consisting of name, currency amount, and date, and so on). A data object is a named memory area that is structured according to a particular data type . The type normally specifies all of the attributes of the data object. Using the name, you can access the contents, that is the data, directly. The name may be a compound name consisting of more than one single name.


You could regard a data type as being similar to the construction plans for a building. The plans could be used for more than one building, which would all have the same type, but you would still be able to tell them apart. Suppose the buildings were used for storage. You would find a particular item using the address of the building, and knowing on which floor, in which room, and in which shelf or bin it was stored. You would have to consider carefully when drawing up your plans the kinds of things you would want to store in your buildings.

The ABAP language is very flexible. Some of the attributes of a data type do not have to be specified until you use it to declare a data object, or, in some cases, not until runtime. It also allows you to use data objects that you have already declared or ABAP Dictionary objects as the basis for new types or data objects.

There are various places in the ABAP Workbench in which you can store and define data types:

ABAP Dictionary

The ABAP Dictionary contains 23 predefined data types, which serve as a basis for all other ABAP Dictionary objects (such as domains, data elements, data types, and so on). These ABAP Dictionary types are available for use globally throughout the system.

As well as the Dictionary objects used to access tables (tables, views, search helps, and so on), you can also (from Release 4.5) create global data types in the ABAP Dictionary.

Previously, the only way to define global data types was to use a type group. Type groups are still supported, but the concept is actually obsolete now that it is possible to define global data types in the ABAP Dictionary.

ABAP programs

Data types that you define in an ABAP program are local, that is, only valid within that program. You use the ten predefined ABAP data types as a basis for your own types.

Both global and local data types fit into the schematic diagram above. The names used above should make it easier for you to understand the following slides and the online documentation.

The technical attributes of an elementary field are defined by an elementary type .

A structure type consists of components.
A table type consists of a line type , access type , key definition, and key type .
In certain exceptional cases, types only desscribe part of the attributes of a data object. For example, a table type does not specify how many lines the table will have. This attribute is not set until runtime, and only affects that one data object.

You can nest types "deeply" to any level. That means:
A structured type can have components that are themselves structured or table types. This enables you to construct very complex data types. However, the smallest indivisible unit is always an elementary type.

The ABAP Dictionary contains a series of predefined data types to represent the external data types of the various database systems.

When you define a field with type CURR in the ABAP Dictionary, you must always link to a currency. You do this by specifying a field with the type CUKY. (When you create a list, you use the CURRENCY addition in the WRITE statement). The same applies to type QUAN, which must always link to a field with type UNIT.

Type FLTP is useful for calculations involving very large or very small numbers. This usually only occurs in scientific applications or when making estimates.

For business calculations, you should always use type DEC or QUAN. The arithmetic is the same as that to which you are used "on paper" - the system calculates precisely to the last decimal place.

A typical use for type NUMC is for postal code fields - fields in which only digits should be allowed, but with which you do not want to perform calculations. (It is, however, possible to use conversions and calculate with alpha-numeric data.) For further details about arithmetic and conversions, refer to the Statements unit.

Based on their underlying data type, some data objects are displayed according to formatting options (for example, country-specific date formats). Each user defines these formats in their user defaults.
All of these data types apart from string and rawstring are elementary types. For technical reasons, these are classified as nested types. This has consequences for certain uses, such as the INTO clause of a SELECT statement.

Data element

Data elements have a business meaning (field label, help text, and so on). Up to and including Release 4.0, it was only possible to specify the technical attributes of a data element by specifying a domain. Each domain had to have a predefined Dictionary type assigned to it. This is still possible. However, it is now possible to enter a predefined Dictionary type directly. If you want to ensure that the technical attributes of a group of data elements can only be changed centrally, you should continue to use domains.

As part of ABAP Objects, you can now designate a data element a reference type and declare global types for references to global classes or interfaces. Note that, in this case, the type of the data element is no longer elementary, but nested. The same applies when you use the predefined types string and rawstring.

Structure

Each component of a structure must have a name so that it can be addressed directly. For the type of a component you may specify a predefined Dictionary type, a data element, a structured type, or a table type. This allows you to construct nested data types. Note the consequences we have already mentioned with particular kinds of access. For example, if a structure contains a component with the type reference or string, you cannot use INTO CORRESPONDING FIELDS OF in a SELECT statement. Instead, you must list the components in the INTO clause.

The data type of an internal table is fully specified by its:

Line type
The line type defines the attributes of the individual fields. You can specify any ABAP data type.

Key definition
The key fields and their sequence determine the criteria by which the system identifies table lines.

Key type
You can define the key as either unique or non-unique . The uniqueness of the key must be compatible with the access type you have chosen for the table. If the key is unique, there can be no duplicate entrie s in the table.


Access type

Unlike database tables, the system assigns line numbers to certain kinds of internal tables. This means that you can use the index to access lines as well as the key. We sometimes use the term "table type " to refer to this.

We can also divide up internal table types into three kinds by their access type:

Standard tables.

In a standard table, you can access data using either the table index or the key. Since the key of a standard table always has to be non-unique for compatibility reasons, the system searches the whole table each time you access it using the key. Consequently, you should always use the index to access a standard table whenever possible.

Sorted tables.

In a sorted table, the system automatically stores the entries and inserts new entries sorted by the table key. The system uses a binary search on the table when you access it using the key. You can specify the key of a sorted table as unique. You will often use the key to access a sorted table, but it is also possible to use the index. Standard tables and sorted tables are generically known as index tables.

Hashed tables.

You can only access a hashed table using the key. There are certain conditions under which you can considerably reduce the access times to large tables by using a hashed table.

The key of a hashed table must always be unique.

You do not have to specify the access type fully. You can either omit it altogether, or specify it partially (index table). The table type is then generic, and, by omitting certain attributes, we can use it to specify the types of interface parameters.

To find out the access type of an internal table at runtime, use the statement DESCRIBE TABLE KIND .

The line type specifies the semantic and technical attributes of the individual fields in a line. As already mentioned, you can specify either another table type, a structured type, or an elementary type. If you only use an elementary type, the internal table will have a single column with no component name (unstructured table

Key definition

The default key consists of all character (alphanumeric) components of the line type that are not themselves table types. In this case, it would be empty (only possible with standard tables).

It is particularly useful to name the line type , that is, the whole line, as the key if the table type is unstructured.

You can also name key components and their sequence explicitly.

A final possibility is not to specify the key, leaving it generic instead.
Key type As well as defining the key as unique and non-unique , you can specify a generic key type by omitting the specificatio n.


Type F is useful for calculations involving very large or very small numbers. This usually only occurs in scientific applications or when making estimates.

For business calculations, you should always use type P. The arithmetic is the same as that to which you are used "on paper" - the system calcualtes precisely to the la st decimal place.

A typical use for type N is for postal code fields - fields in which only digits should be allowed, but with which you do not want to perform calculations. (It is, however, possible to use conversions and calculate with alpha-numeric data.) For further details about arithmetic and conversions, refer to the Statements unit.

Unlike type C, N, or X fields, the length of a string or hexadecimal string is not statically defined. Instead, it is variable, and, at runtime, will always take the length of its current contents. The memory is managed dynamically by the system. Strings and hexadecimal strings can have any length.

You cannot currently use STRING or XSTRING to specify the type of a screen field.
You can only define a new data type based on an existing type. Use the TYPE addition to refer to data types, that is, predefined ABAP types, user-defined local types, predefined ABAP Dictionary types, user-defined ABAP Dictionary types, or fields or entire lines from database tables. If you refer to an ABAP Dictionary type, changes to the global type are automatically passed on to your type. This ensures that your type is always compatible with the corresponding ABAP Dictionary object. Types that refer to the ABAP Dictionary also have the advantages of formatting options, field help, and possible entries help.

The underlying ABAP Dictionary data type is converted into the corresponding ABAP data type when the program is generated. For further information, refer to the ABAP syntax documentation for the TABLES statement.

If a global and a local data type both have the same name, the system uses the local type .

Use the LIKE addition to refer to the type of a data object that you have already declared. This also applies to the next slides.

Elementary types

The length specification after the type name for ABAP data types C, N, and X specifies the number of characters in the type. For type P fields, you can also set the number of decimal places. If you omit these specifications, the system uses the default values (refer to the chart under Predefined ABAP Types).

Structured type s Use the statements

TYPES BEGIN OF .
And TYPES END OF .
to enclose the list of components in your structure. Any type definitions may appear between the two statements. You can also construct nested data types.
To refer to the line type of a table type or an internal table, use the additions TYPE LINE OF or LIKE LINE OF respectively.

Table types Similarly to when you create table types in the ABAP Dictionary, you must specify various attributes here:

The line type after ... TABLE OF (as always, if you refer to a data type, use TYPE, if you refer to a data object that has already been declared, used LIKE);

The access type before TABLE OF ... (If you omit this, the system uses the default access type, which is standard. You can also specify a generic table type using INDEX or ANY.);

The key definition after the key type (to specify the default key, use the DEFAULT KEY addition); You can also specify fields from the (flat) line type and specify the sequence explicitly. If the table is unstructured, you can use the TABLE LINE addition);

The key type after ...WITH (UNIQUE or NON-UNIQUE).
If you omit the key specification entirely, the system uses the non-unique default key.

For information about the optional INITIAL SIZE addition, refer to the page Declaring Internal Tables.

We have not yet introduced reference types. These will be discussed in conjunction with field symbols and references.

Similarly to when you define data types, you must specify a type when you declare data objects. You can do this in one of two ways:

Either by referring to a data type (using the TYPE addition), or a data object in the program that has already been declared (using the LIKE addition). You can use exactly the same syntax variants in the DATA statement as when you declare local data types using the TYPES statement.

You can also construct a field, structure, or internal table directly in a DATA statement, without having to define your own data type first.
In most cases, you will want to change the value of data objects at runtime. They are therefore also known as variables. You can assign a starting value to a data object using the VALUE addition. If you do not, the system assigns it the initial value appropriate to its type (see the table under Predefined ABAP Types).

There are two further statements that you can use to declare special data objects:

STATICS declares local variables in a subroutine whose values are retained in subsequent subroutine calls instead of being initialized again. For further information, refer to the Subroutines uint.

CLASS-DATA, an ABAP Objects statement, allows you to declare static class attributes.
With the exception of the WITH HEADER LINE addition, the syntax for declaring internal table objects is exactly the same as that used to define table types or other kinds of data objects. The addition allows you to create an internal table with a header line . However, this is an obsolete programming technique, and you should consequently no longer use it. For more information about header lines, along with general information about internal tables, refer to the Internal Table Operations unit.

Dynamic table extension

Unlike arrays in other programming languages, the number of lines in an internal table is increased automatically by the ABAP runtime environment as required. You therefore do not have to worry about managing the size of the table, but only about inserting, reading, or deleting lines. This makes chained lists redundant in ABAP.

INITIAL SIZE addition

When you create an internal table, the system allocates 256 bytes to it. The system then allocates a block of 8 KB to the table when you first add data, followed by further 8KB blocks as required. If you are only expecting to place a few lines in your table, or are using nested internal tables, it may be worth restricting the first automatic extension using the addition INITIAL SIZE . You may do this either in the data object definition or in the type definition. is the maximum number of lines that you are expecting to put in the table. When the system first allocates memory, it allocates the product of and the length of the line. In the second step, it allocates twice that amount, and then in subsequent steps, it allocates between 12 and 16 KB.


Selection screens are a special kind of screen whose layout you program directly in the processing logic using ABAP statements . In an executable (type 1) program, there is a standard selection screen (screen number 1000). The definition of the standard selection screen does not require the statements that normally mark the beginning and end of a selection screen definition, neither does it require an explicit call. The following statements allow you to easily create screens on which the user can enter data.


PARAMETERS creates an input field on the selection screen with the type you specify and a variable in the program with the same name. You cannot use f, string, xstring, or references to specify the type.

SELECT-OPTIONS creates a pair of "from - to" fields on the screen, in which it is possible to enter sets of complex selections for a specified variable. The values that the user enters are stored in an internal table that the system creates automatically. The internal table has four fields sign, option, low, and high.
You can also create this kind of table using …{TYPE|LIKE} RANGE OF … . However, tables declared in this way are not linked to the selection screen.

For further information about these statements, refer to the courses BC405 (Techniques of List Processing and ABAP Query) and BC410 (Programming User Dialogs).
Constants and literals are fixed data objects - you cannot change their values at runtime.

You define constants using the ABAP keyword CONSTANTS. In it, you must use the VALUE addition to assign a value to your constant.

Recommendation:

Avoid using literals wherever possible. Use constants instead. Your programs will then be easier to maintain.

Literals allow you to specify a value directly in an ABAP statement. There are two kinds of literals - numeric literals and text literals. Text literals must always be enclosed in single quotes. Integers (including a minus sign if appropriate) can be represented as numeric literals. They are mapped to the data types i and p (based on the interval that each data type can represent).

Example :

DATA: result1 TYPE i, result2 LIKE result1.
result1 = -1000000000 / 300 * 3. "result1: 999.999-
result2 = -10000000000 / 300 * 3. "result2: 10.000.000-
A numeric literal can contain up to 31 digits.
All other values (decimal and floating point numbers, strings, and so on) must be given as text literals. The system converts the data type if necessary.


A text literal can contain up to 255 characters.
If you want a single quote to appear in a text literal, you must use two single quotes in order for it to be interpreted as part of the literal and not the closing single quote.

Text symbols are a special form of text literals. You can create a set of text symbols for any program. These can be used for output in various ways. The advantage of text symbols over normal text literals is that they can be translated. Furthermore, text elements are stored separately from the program source code, making your program easier to understand.

Text symbols are often used to create lists that are not language-specific. You can also use them to assign texts dynamically to screen objects. (Static text elements for screen objects are a special case, and can be translated).
You can display text symbols in two different ways using the WRITE statement:

WRITE text-. (where can be any three-character ID).
WRITE ''(). (where can be any three-character ID). In this
case, is displayed if there is a text for it in the current logon language. If there is not, the default text is displayed.


When you use screens, the system automatically transports field contents from the processing logic to the screen and back, but only where screen fields and ABAP fields have the same names.

Restriction:

If you use screen fields with a reference to the ABAP Dictionary (Get from Dictionary function in the Screen Painter), you must use the TABLES statement to declare a data object with the same name as the ABAP Dictionary object in order for the field transport to work. Structures you declare like this are often referred to as work areas.

There are numerous advantages to using an ABAP Dictionary reference: Dictionary objects normally include foreign key checks, field help, possible entries, and the necessary error dialogs. Consequently you can catch inconsistent data as soon as the user enters it and before you even leave the screen.

If you program your own field checks, the field contents must already have been transported to the program. If you forget to reset the field when a check fails, an unwanted value may remain in the work area. You also face the same danger if you are not sure whether work areas are shared by more than one program.

To avoid these dangers, you should regard TABLES work areas as an interface between the screen and program, and only use them in this context. They provide data for the screen at the end of the PBO event, and receive it again when the values are transported from the screen.

Logical databases are special ABAP programs that you can attach to an executable (type 1) program. They read data from the database and pass it to the executable program. Because the task of reading the data has been passed to the logical database, your own ABAP program becomes considerably simpler.

The logical database passes the data to your program using interface work areas that you declare using the NODES statement. The statement creates a variable that refers to the data type in the ABAP Dictionary with the same name.

The data is passed to your program record by record. Each time the logical database makes a record available to your program, the corresponding GET or GET LATE event is triggered. In your program, you can code the relevant event blocks.
You can determine the type of the data record returned by the logical database using the TYPE addition However, you are restricted to types that are supported by the logical database.

The data object SPACE is a constant with type C and length 1. It contains a single space.

The system automatically creates a structure called sy for each program, based on the ABAP Dictionary structure syst. The individual components of the structure are known as system fields .

They contain values that inform you about the current state of the system. The values are updated automatically by the ABAP runtime environment.

You can access individual system fields using the notation sy-.
System fields are variables, so you can change them in your programs. However, you should only do this in cases where it is explicitly recommended in the documentation (for example, navigating between list levels by manipulating sy-lsind). In all other cases, you should only read the contents of system fields, since by changing them you might overwrite information that is important for subsequent steps in the program.
The online documentation contains a list of all system fields with notes on their use. You can also display the structure syst in the ABAP Dictionary.

You declare field symbols using the FIELD-SYMBOLS <> statement. The brackets (<>) are part of the syntax.

Field symbols allow you symbolic access to an existing data object. All of the changes that you make to the field symbol are applied to the data object assigned to it. If the field symbol is not typed (TYPE ANY), it adopts the type of the data object. By specifying a type for the field symbol, you can ensure that only compatible objects are assigned to it.

Field symbols are similar to dereferenced pointers .

You use the ASSIGN statement to assign a data object to the field symbol <>. To lift a type restriction, use the CASTING addition. The data object is then interpreted as though it had the data type of the field symbol. You can also do this with untyped field symbols using the CASTING TYPE addition.

Use the expression <> IS ASSIGNED to find out whether the fie ld symbol <> is assigned to a field.

The statement UNASSIGN <>. sets the field symbol <> so that it points to nothing.

The logical expression <> IS ASSIGNED is then false.
An untyped field symbol that does not have a data object assigned to it behaves (for compatibility reasons) like a constant with type C and length 1.

The statement TYPES TYPE REF TO data. *) defines a reference type to a data object. DATA... defines the corresponding reference itself. Such a reference is a field in which an address can be stored.

The GET REFERENCE OF INTO statement writes the address of the data object (already declared) into the reference variable. In other words, the reference points to the data object in memory.

Thus ABAP uses reference semantics (changes apply to the address) as well as value semantics, as used in field symbols (where changes apply to the data objects). However, in ABAP, reference semantics is restricted to assignments.

The dereferencing operator ->* in the ASSIGN statement allows you to assign the data object to which the reference points to a field symbol. You can then access the value of the data object.

You can create a data object with a specified type at runtime using the CREATE DATA
statement. This data object has no name, but the reference points to its address.

You can use type casting dynamically when you assign a data object to a field symbol. The graphic presents an example of this.
The name of the database table is not known until runtime (and consequently, neither is the line type).

Since you cannot specify a dynamic INTO clause in the SELECT statement, the system writes the data records into the long character field line.

The assignment to field symbol and the type casting then make it possible to access the field as though it were a flat structure. All type attributes are inherited from the database table. (You can also refer to the line type of an ABAP Dictionary object using the TYPE addition.)

If you knew the component names, you could display the fields directly using
WRITE -... .

However, you will not normally know the names of the components. In this case, you must use the ASSIGN COMPONENT variant, in which the components of the structure are assigned one-by-one to the field symbol and then displayed. When the loop runs out of components, the program reads the next data record.

Problem

The address of line must satisfy the same address rules as a table structure (address must be divisible by four with no remainder). You can force this by declaring an integer field dummy directly before declaring line. (Integers are always stored at addresses that are divisible by four.)

Unlike conventional data objects, you can specify the type of a data object created at runtime dynamically. The above example is a slightly modified version of the example on the previous page.

This time, the idea is the create the data object for the INTO clause dynamically at runtime . In this case, the type is already known (you have entered the table name), and there are no more alignment problems. The statement ASSIGN d_ref->* to assigns the data object to the field symbol. The data type of the table is inherited by the field symbol, so type casting is no longer necessary.

Instead of using a long character field, you can now write the data record into the data object with the same type to which the reference d_ref is pointing, by using the field symbol .

You will sometimes need to find out the attributes of a data object at runtime , especially when you use field symbols and references. The DESCRIBE FIELD statement returns various type attributes of variables.

Caution:

If you query the length of a field with type string or xstring, the system does not return the length of the string. Instead, it returns the length of the string reference, which is always eight bytes. To find out the length of the string, use the OUTPUT-LENGTH addition.

The statement DESCRIBE TABLE LINES returns the number of lines in an internal table.

Since the introduction of ABAP Objects, there is now a system called the RTTI concept (Run Time Type Information) that you can use to find out type attributes at runtime. It is based on system classes. The concept includes all ABAP types, and so covers all of the functions of the statements DESCRIBE FIELD and DESCRIBE TABLE.