Internal Tables

Cannot Use OCCURS with Declarative Statements

In ABAP Objects, you cannot define internal tables using the OCCURS addition in the TYPES or DATA statements (or any other declarative statement).

In ABAP Objects, the following statements cause an error message:

DATA: BEGIN OF itab OCCURS n,
  ...
  fi ...,
  ...
END OF itab.

and

TYPES|DATA itab TYPE|LIKE line_type OCCURS n.

Correct syntax:

TYPES|DATA: BEGIN OF line_type,
  ...
  fi ...,
  ...
END OF line_type.

TYPES itab TYPE|LIKE STANDARD TABLE OF line_type
                     WITH NON-UNIQUE DEFAULT KEY
                     [INITIAL SIZE n].

DATA itab TYPE|LIKE [STANDARD] TABLE OF line_type
                    [INITIAL SIZE n].

Cause:

TYPE|LIKE TABLE OF, the new addition for the DATA and TYPES statements, makes the OCCURS addition superfluous in table declarations. If necessary, you can define the initial main memory requirement using the INITIAL SIZE addition.

Note:

The system automatically updates the short form

DATA itab TYPE|LIKE TABLE of line_type.

to

DATA itab TYPE|LIKE STANDARD TABLE OF line_type
                    WITH NON-UNIQUE DEFAULT KEY
                    INITIAL SIZE 0.

so that you can use the former.

The system automatically updates the short form

TYPES itab TYPE|LIKE STANDARD TABLE of line_type.

to

TYPES itab TYPE|LIKE STANDARD TABLE of line_type
                     INITIAL SIZE 0.

and defines a standard table type with a generic key that can be used to type interface parameters and field symbols.

Cannot Use Headers in Tables

In ABAP Objects, you can only declare tables without header lines.

In ABAP Objects, the following statement causes an error message:

DATA itab TYPE|LIKE TABLE OF ... WITH HEADER LINE.

Correct syntax:

DATA: itab TYPE|LIKE TABLE OF ... ,
        wa LIKE LINE OF itab.

Cause:

Depending on the statement, the system can access tables with a header either by accessing the table body, or by accessing the header itself. The table name should signify the table unambiguously. This makes programs easier to read. Tables with headers do not offer any performance advantages.

Note:

When you call external procedures (subroutines and function modules) that are contained in the parameter interface TABLES parameter, be aware that this TABLES parameter always contains both a table body and a header. When a table without a header is transferred, the header of the TABLES parameter remains blank. When calling these procedures in methods, you must check to see whether the procedure expects to receive and evaluate the header. If necessary, adapt or rewrite the procedure. Method interfaces do not have TABLES parameters.

Cannot Use Short Forms in Line Operations

You cannot use the short form in any of the operations performed on the lines of a table in ABAP Objects. Instead you must always work with an explicit work area or field symbol.

In ABAP Objects, the following statements cause an error message:

Operations for all table types

INSERT TABLE itab.
COLLECT itab.
READ TABLE itab ...
MODIFY TABLE itab ...
MODIFY itab ... WHERE ...
DELETE TABLE itab.
LOOP AT itab ...

Operations for index tables

APPEND itab.
INSERT itab ...
MODIFY itab ...

Correct syntax:

Operations for all table types

INSERT wa INTO TABLE itab.
COLLECT wa INTO itab.
READ TABLE itab ... INTO wa | ASSIGNING <fs>.
MODIFY TABLE itab FROM wa ...
MODIFY itab FROM wa ... WHERE ...
DELETE TABLE itab FROM wa.
LOOP AT itab INTO wa ... | ASSIGNING <fs> ...

Operations for index tables

APPEND wa TO itab.
INSERT wa INTO itab ...
MODIFY itab FROM wa ...

Cause:

The reasons for this lie in the unambiguous separation of tables from work areas. This makes programs easier to read. Since you can declare tables without a header line only in classes, this is only a constraint in local classes when accessing global tables in the main program.

Cannot Change an Internal Table in a Loop

You cannot change a complete internal table in a loop operating on this table in ABAP Objects. Changes to the table as a whole may be caused by, for example, the REFRESH, CLEAR, FREE, MOVE, SORT, or SELECT INTO TABLE statements. This applies to internal tables from procedures and internal tables imported from a data cluster.

In ABAP Objects, the following statements cause an error message:

LOOP AT itab INTO wa.
  CLEAR itab.
ENDLOOP.

Correct syntax:

LOOP AT itab INTO wa.
  ...
ENDLOOP.
CLEAR itab.

Cause:

When the table is accessed again, system behavior will be unpredictable and may lead to runtime errors.

Compatible Line Types When Using the INSERT INTO TABLE Statement

When you insert lines from one internal table in another, in ABAP Objects, the line types must be compatible.

In ABAP Objects, the following syntax causes an error message:

DATA: itab TYPE SORTED TABLE OF f
                WITH UNIQUE KEY table_line,
      jtab TYPE HASHED TABLE OF i
                WITH UNIQUE KEY table_line.

INSERT LINES OF itab INTO TABLE jtab.

Correct syntax:

DATA: itab TYPE SORTED TABLE OF f
                WITH UNIQUE KEY table_line,
      jtab TYPE HASHED TABLE OF f
                WITH UNIQUE KEY table_line.

INSERT LINES OF itab INTO TABLE jtab.

Cause:

In any generic insert operation - that is, inserting lines into any type of table - the lines that are to be inserted must be compatible with the line type of the target table. The above statement has been adapted to fit these semantics.

Compatible Work Area When Processing Control Levels

The work area must be compatible with the table line type when processing control levels in an internal table.

In ABAP Objects, and as of release 7.0 also outside of classes, the following statement causes an error message:

DATA: itab LIKE TABLE OF line,
      wa(255) TYPE x.

SORT itab by col1.
LOOP AT itab INTO wa.
  AT NEW col1.
  ENDAT.
ENDLOOP.

Correct syntax:

DATA: itab LIKE TABLE OF line,
      wa   LIKE LINE OF itab.
SORT itab by col1.
LOOP AT itab INTO wa.
  AT NEW col1.
  ENDAT.
ENDLOOP.

Cause:

Control level processing is based on the line structure of the internal table. The system evaluates the work area when it wants to change the control level, which means that the work area must have the same structure as the line of the table.

Cannot Declare a Superfluous Work Area

In ABAP Objects, you cannot declare a work area as an addition to the READ TABLE statement, if you are also using the TRANSPORTING NO FIELDS addition.

In ABAP Objects, the following statement causes an error message:

READ TABLE itab INDEX i INTO wa TRANSPORTING NO FIELDS.

Correct syntax:

READ TABLE itab INDEX i TRANSPORTING NO FIELDS.

Cause:

Declaring INTO wa is superfluous. The work area is not affected in the statement.

Cannot Use Obsolete Key Declaration with TABLE LINE

If you intend to specify the whole line of an internal table as the key, you cannot enter TABLE LINE in ABAP Objects.

In ABAP Objects, the following statement causes an error message:

... TABLE LINE ...

Correct syntax:

... table_line ...

Cause:

The pseudo-component table_line replaces the TABLE LINE construction.

Cannot Use Obsolete READ Variants

You cannot use the READ variant that allows you to read key values from the table header line in ABAP Objects.

In ABAP Objects, the following statement causes an error message:

READ TABLE itab.

Correct syntax:

READ TABLE itab FROM key INTO wa.

or

READ TABLE itab WITH KEY ... INTO wa.

Cause:

This variant uses an implicit key consisting of all the fields of the table header that are not of numeric type (I, F, or P) and whose content is not SPACE. Declare the key explicitly instead. You could only ever use this variant with tables with a header.

In ABAP Objects, you cannot use the READ variant that lets you characterize the table using the structure of the key.

In ABAP Objects, the following statement causes an error message:

READ TABLE itab WITH KEY key INTO wa.

Cause:

The key fields of a table must always be components of the line structure.

You cannot use the READ variant in which the whole line of the table is treated as a component and the declared key value is compared to the complete line of the table in ABAP Objects.

In ABAP Objects, the following statement causes an error message:

READ TABLE itab WITH KEY = key INTO wa.

Correct syntax:

READ TABLE itab WITH KEY table_line = key INTO wa.

Cause:

This variant is a special solution that lets you access the table with unstructured line types using a key. The introduction of the pseudo-component table_line, which can always be used instead of a key field, renders this variant superfluous.

When using an explicit search key in ABAP Objects, you can only declare a column once in the READ TABLE statement.

In ABAP Objects, the following statement causes an error message:

READ TABLE itab INTO line WITH KEY col1 = ... col1 = ...

Correct syntax:

READ TABLE itab INTO line WITH KEY col1 = ...

Cause:

Only the last declaration is evaluated. Multiple declarations are unnecessary.

No WRITE TO for Internal Tables

The WRITE TO statement is not allowed in ABAP Objects for internal tables.

In ABAP Objects, the following statement causes an error message:

WRITE ... TO itab INDEX idx.

Correct syntax:

FIELD-SYMBOLS <fs> TYPE ...

READ TABLE itab INDEX idx ASSIGNING <fs>.
WRITE ... TO <fs>.

Reason:

Field symbols can be used for direct access to table rows. The WRITE TO statement for table rows is superfluous.

No Field Symbols As Sort Criteria

When you sort internal tables, no field symbols may be used as sort criteria in ABAP Objects.

In ABAP Objects, the following statements cause an error message:

name = 'ITAB-COL1'.
ASSIGN (name) TO <fs>.

SORT itab BY <fs>.

Correct syntax:

name = 'COL1'.

SORT itab BY (name).

Reason:

Sort criteria must be defined with reference to the line structure (columns) of the internal table. Field symbols point to data objects and must not be used to name structure components. Since it is possible to define the name dynamically, it is not necessary to define a column with field symbols that point to the work area used. This variant was only possible for tables with a header line.

No field symbols as a control break criterion

In ABAP Objects it is not allowed to specify field symbols as control break criteria in control level processing.

Error message in ABAP Objects if the following syntax is used:

name = 'WA-COL1'.
ASSIGN (name) TO <fs>.

LOOP AT itab INTO wa.
  AT NEW <fs>.
    ...
  ENDAT.
ENDLOOP.

Correct syntax:

name = 'COL1'.

LOOP AT itab INTO wa.
  AT NEW (name).
    ...
  ENDAT.
ENDLOOP.

Reason:

Control break criteria must be specified with reference to the line structure (columns) of the internal table. Field symbols point to data objects and must not be used for naming structure components. Since dynamic name specification is possible, column specifications via field symbols that point to the used work area are obsolete.

Cannot Use INFOTYPES

This statement is not allowed in ABAP Objects because it creates a special table with a header line.

In ABAP Objects, the following statement causes an error message:

INFOTYPES nnn.

Cause:
The table you want to define must be declared using permitted statements, since tables with a header are not allowed in ABAP Objects.

Cannot Use RANGES

This statement creates a special table with a header line and as such is not allowed in ABAP Objects.

In ABAP Objects, the following statement causes an error message:

RANGES rangetab FOR f.

Correct syntax:

DATA rangetab TYPE|LIKE RANGE OF ...

Cause:

Tables with a header are not allowed in ABAP Objects; declare your table using permitted statements instead.

Cannot Use Short Form of PROVIDE

You can only apply this variant to tables with a header line, which means that it cannot be used in ABAP Objects.

In ABAP Objects, the following statements cause an error message:

PROVIDE f1 f2 ... FROM itab1
        g1 g2 ... FROM itab2
        ...                
          FROM itabn        
        ...                
        BETWEEN f AND g.    
  ...
ENDPROVIDE.

Cause:

You can only use the loop in local classes for tables in the main program. You should use the long form available since Release 6.20 instead.