ABAP Internal Tables

1.Data Structures
Structures
Structures in code are similar to structures in the Dictionary in that they are simply field strings. However, they are not dictionary objects, but temporary objects in program memory.
Structures are used in connection with sequential datasets and
subroutines as well as a “staging area” for internal tables.
Internal Tables
Internal tables are comprised of records which have the same format as an individual structure.
Internal tables are tables which only exist during the execution of a program.
Unlike the ABAP Dictionary transparent tables, internal table data
is not stored on the database server. Internal table data resides in
a program specific work area.
Data can only be entered in an internal table by going through a “staging area”. A “staging area” can either be a header line or a work area, either of which has the same structure as the internal table itself.
Prior to the 4.0 release, program structures were simply called “field strings”.
2.Declaring a Structure – Method #1

.

Structures are defined with the DATA statement. The start and end of the structure are indicated by BEGIN OF <FSname> and END OF <FSname>.
Fields in a structure are defined as individual fields; you must specify the length, and data type. You can also define default values for components of structures. With the LIKE parameter, it is possible to adopt the attributes of internal fields which have already been declared or the attributes of fields defined in the ABAP Dictionary.
Reference fields in a structure as follows:
<Structure> – <field name>

e.g. YCUSTOMER-COUNTRY

A table work area defined in an ABAP program with the TABLES statement is comparable in construction to a structure.
 (Note: Here the processing does not use the table TABNA, and so in this case the Tables statement is not required.)

.

3.Declaring a Structure – Method #2
A structure can also be defined using a combination of the TYPES and
DATA statements.
The TYPES statement defines a data type which in this example includes the fields: flag, id, name1, and city. It does not allocate any memory for these fields.
The DATA statement defines a variable using the data type defined with the TYPES statement. At this point, memory is allocated and the structure is present in the program’s work area.
This method is preferable to the previous one, especially when it comes to building an internal table from a structure.

.

4.Populating a Structure with Field-by-Field Transport
The statement MOVE-CORRESPONDING <f1> to <f2> transports values field by field between the ABAP data structures f1 and f2 for all sub-fields with the same field names. The system searches in f1 for all single fields that also occur in f2 and generates a statement for all pairs of fields found: MOVE <f1>-<field name> TO <f2>-<field name>. The other fields remain unchanged.
The CLEAR statement resets all fields to their initial value. The data type initial values were covered in chapter 1.04.01.

               Performance Tips:

 M                           OVE-CORRESPONDING is less efficient than a specific MOVE statement for each field in the work area/data structure. If the data structures f1 and f2 are the same and the sequence and attributes of all fields are identical, you can just use the statement MOVE <f1> to <f2> to transport the values of all fields from f1 to f2.
5.Creating an Internal Table with Header Line
An internal table type is defined using the TYPES statement. No memory is allocated when defining a type.
An internal table object is created with the DATA statement by referring to an internal table type using the TYPE parameter. It is this DATA statement occupies memory. Internal table objects can also be created through a reference to an existing table or structure using the LIKE parameter.
The internal table object must have an INITIAL SIZE <n> parameter to indicate the initial number of table lines for which memory will be allocated.
The above code creates a standard internal table EMPTAB of structure EMP, and then loads the employee data from table work area EMPLOYEE into the internal table header line of EMPTAB, and then appends to the body of EMPTAB.
 In previous versions, there was only one type of internal table, so the STANDARD TABLE OF addition was not necessary. See the appendix for extended examples of older internal table declaration styles. Also the INITIAL SIZE extension was called OCCURS. The old declarations are still recognized in 4.x.
 
6.Internal Table Keys
 By default, all the records that you append to your internal table have a key. This key is the combination of all non-numeric fields. This is the implicit key.
 You can also define your own key for an internal table. You would add WITH KEY FIELD1 FIELD2 … etc. to your DATA statement.
 More specifically, you can make your user-defined key:
 UNIQUE: additional records with the same key would not be permitted
 NON-UNIQUE: additional records with the same key would be permitted
 Standard tables can have:
 NON-UNIQUE KEY (same as just plain KEY), or
 no user-defined key at all (more likely)
 Indexing is used more than keys when it comes to reading standard internal tables.
 User-defined keys are new in 4.0. You would only be able to use the implicit key in previous releases.
 
7.Size of the Internal Table
INITIAL SIZE <n> parameter: With <n>, you specify an initial number of lines for the internal table. For the number of lines specified, memory will be reserved as soon as the first line is written into an internal table.
If more lines are added to an internal table than specified by <n>, the reserved memory will expand automatically. Therefore, it is possible to create an internal table with the parameter INITIAL SIZE 0.
If there is not enough storage in memory for the internal table, it will be written into a buffer or on a disk (paging area).
If the INITIAL SIZE parameter is left off, a value of INITIAL SIZE 0 is set.
The INITIAL SIZE parameter will affect the physical size of an internal table if the APPEND <Internal table> SORTED BY <field> statement is used to load data into the internal table (see next slide).

Performance Tips:

 If you know the maximum size of an internal table and that size is less than 8K, you can increase the system’s performance by specifying the maximum size in the INITIAL SIZE <n> parameter. If you do not know the maximum size of an internal table or if it’s greater than 8K, you should let the system allocate the appropriate memory by specifying INITIAL SIZE 0 in the internal table definition. Any table larger than 8K should be declared INITIAL SIZE 0.
 
8.Loading an Internal Table with a Header Line
The APPEND <internal table> statement adds the contents of the header line to the end of the internal table.
The APPEND <internal table> SORTED BY <field> statement adds a new record to an internal table and sorts the table by a single <field> in descending order (the default and only option).
The SORTED BY clause limits the maximum number of table entries to the
value in the INITIAL SIZE parameter. If the table is full then, the last table
entry is removed.

Performance Tips:

 An INITIAL SIZE 0 cannot be used with the SORTED BY option, as no entries will be saved into the body of the internal table.

Coding Recommendations:

 An internal table can also be loaded by copying the data from one internal table to another. ‘[ ]’ is added to distinguish the body of the table from the header line.

  Ex:  ITAB2[ ] = ITAB1[ ].   Copies all the data from the body of internal table ITAB1 to ITAB2.

    ITAB2 = ITAB1.   Copies the data in the header line for ITAB1 to the header line for ITAB2.

In the first example, the table entries are saved in the sequence in which they are read. More than ten entries can be saved.
In the second example, the table entries are sorted by the field salary in descending order. A maximum of ten table entries are saved.
With an APPEND <internal table> SORTED BY <field> statement, the number of entries in the table exceeding the value of the INITIAL SIZE clause are deleted. Normally, it is better to use an external SORT (covered in a later slide).

.

.

.

.

.

.

.

.

9.

REPORT Z220DM38.

A  TABLES:  EMPLOYEE.

  TYPES:  BEGIN OF EMP,

     ID    LIKE EMPLOYEE-ID,

     NAME1  LIKE EMPLOYEE-NAME1,

     COUNTRY  LIKE EMPLOYEE-COUNTRY,

    END OF EMP.

B  DATA:  EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 WITH   HEADER LINE.

  SELECT * FROM EMPLOYEE.

   MOVE-CORRESPONDING EMPLOYEE TO EMPTAB.

   APPEND EMPTAB.

  ENDSELECT.

9.Internal Table With Header Line

.

.

In the first example, the table entries are saved in the sequence in which they are read. More than ten entries can be saved.
In the second example, the table entries are sorted by the field salary in descending order. A maximum of ten table entries are saved.
With an APPEND <internal table> SORTED BY <field> statement, the number of entries in the table exceeding the value of the INITIAL SIZE clause are deleted. Normally, it is better to use an external SORT (covered in a later slide).

.

.

.

.

REPORT Z220DM38.
A  TABLES:  EMPLOYEE.
  TYPES:  BEGIN OF EMP,
     ID    LIKE EMPLOYEE-ID,
     NAME1  LIKE EMPLOYEE-NAME1,
     COUNTRY  LIKE EMPLOYEE-COUNTRY,
    END OF EMP.
B  DATA:  EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 WITH   HEADER LINE.
  SELECT * FROM EMPLOYEE.
   MOVE-CORRESPONDING EMPLOYEE TO EMPTAB.
   APPEND EMPTAB.
  ENDSELECT.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

10.Internal Table With Header Line

.

.

.

REPORT Z220DM38.

A  TABLES:  EMPLOYEE.

  TYPES:  BEGIN OF EMP,

     ID    LIKE EMPLOYEE-ID,

     NAME1  LIKE EMPLOYEE-NAME1,

     COUNTRY  LIKE EMPLOYEE-COUNTRY,

    END OF EMP.

B  DATA:  EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 WITH   HEADER LINE.

  SELECT * FROM EMPLOYEE.

   MOVE-CORRESPONDING EMPLOYEE TO EMPTAB.

   APPEND EMPTAB.

  ENDSELECT.

11. Internal Table With Header Line

.

REPORT Z220DM38.

  TABLES:  EMPLOYEE.

  TYPES:  BEGIN OF EMP,

          ID  LIKE EMPLOYEE-ID,

          NAME1  LIKE EMPLOYEE-NAME1,

          COUNTRY  LIKE EMPLOYEE-COUNTRY,

      END OF EMP.

  DATA:  EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 WITH HEADER LINE.

  SELECT * FROM EMPLOYEE.

            MOVE-CORRESPONDING EMPLOYEE TO EMPTAB.

       APPEND EMPTAB.

  ENDSELECT.

12.  Internal Table With Header Line

.

REPORT Y170DM38.

  TABLES:  EMPLOYEE.

  TYPES:  BEGIN OF EMP,

     ID  LIKE EMPLOYEE-ID,

     NAME1  LIKE EMPLOYEE-NAME1,

     COUNTRY  LIKE EMPLOYEE-COUNTRY,

    END OF EMP.

  DATA:  EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 WITH   HEADER LINE.

1   SELECT * FROM EMPLOYEE.

2   MOVE-CORRESPONDING EMPLOYEE TO EMPTAB.

   APPEND EMPTAB.

  ENDSELECT.

13.  Internal Table With Header Line

.

REPORT Y170DM38.

  TABLES:  EMPLOYEE.

  TYPES:  BEGIN OF EMP,

     ID  LIKE EMPLOYEE-ID,

     NAME1  LIKE EMPLOYEE-NAME1,

     COUNTRY  LIKE EMPLOYEE-COUNTRY,

    END OF EMP.

  DATA:  EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 WITH   HEADER LINE.

1   SELECT * FROM EMPLOYEE.

2   MOVE-CORRESPONDING EMPLOYEE TO EMPTAB.

3    APPEND EMPTAB.

  ENDSELECT.

.

.

.

15.  Creating an Internal Table Without Header Line

To create an internal table without a header line, the programmer must:
Create an internal table data type with the TYPES statement. This type will become the structure of the internal table.
Once the TYPE is created, a DATA statement is coded to identify the actual internal table object with a name and an INITIAL SIZE clause. The internal table inherits the fields and attributes from the TYPES statement defined earlier.
In addition to the internal table definition with the INITIAL SIZE clause, the programmer must also define an internal table work area (staging area). This work area is defined using the same format as the table. It uses the same user-defined data type as the internal table.
The work area is loaded programmatically (i.e., MOVE-CORRESPONDING EMPLOYEE TO EMPTAB_WA), then appended to the internal table.
To load an internal table without a header line, the following APPEND statement is used: APPEND <work area> to <internal table>.

.

16.  Internal Table without a Header Line WHY ?

Why would we choose to use an internal table without a header line when it is easier to code one with a header line?
Separate Internal Table Work Area: The work area (staging area) defined for the internal table is not limited to use with just one internal table.
Suppose you want two internal tables for EMPLOYEE one to contain all records and one to contain only those records where country = ‘USA’. You could create both of these internal tables without header lines and use only one work area to load data into both of them. You would append all records from the work area into the first internal table. You would conditionally append the ‘USA’ records from the same work area into the second internal table.
Performance Issues: Using an internal table without a header line is more efficient than one with a header line (see how to test this below).
Nested Internal Tables: If you want to include an internal table within a structure or another internal table, you must use one without a header line.

Performance Tips:

 To test efficiency issues, go to SYSTEM UTILITIES RUNTIME ANALYSIS and click on the ‘Tips & Tricks’ push-button. Here you can test various internal table performance issues. The one dealing with header line versus no header line is entitled ‘Using explicit work areas’. Within this area, you can measure the runtime to see that internal tables without header lines are more efficient.

.

.

.

.

.

.

.

.

.

.

.

.

17. Internal Table without a Header & Work Area

REPORT Z220DM40.

  TABLES: EMPLOYEE.

  TYPES: BEGIN OF EMP,

    ID LIKE EMPLOYEE-ID,

    NAME1 LIKE EMPLOYEE-NAME1,

    COUNTRY LIKE EMPLOYEE-COUNTRY,

   END OF EMP.

  DATA: EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 ,

                EMPTAB_WA TYPE EMP.

  SELECT * FROM EMPLOYEE.

   MOVE-CORRESPONDING EMPLOYEE TO EMPTAB_WA.

   APPEND EMPTAB_WA TO EMPTAB.

  ENDSELECT.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18. Internal Table without a Header & Moving Data Flow

REPORT Z220DM40.

  TABLES: EMPLOYEE.

  TYPES: BEGIN OF EMP,

    ID LIKE EMPLOYEE-ID,

    NAME1 LIKE EMPLOYEE-NAME1,

    COUNTRY LIKE EMPLOYEE-COUNTRY,

   END OF EMP.

  DATA: EMPTAB TYPE STANDARD TABLE OF EMP INITIAL SIZE 10 ,

   EMPTAB_WA TYPE EMP.

1  SELECT * FROM EMPLOYEE.

2       MOVE-CORRESPONDING EMPLOYEE TO EMPTAB_WA.

3       APPEND EMPTAB_WA TO EMPTAB.

  ENDSELECT.

.

.

.

.

19. Transferring ABAP Dictionary Table Structures

REPORT Z220DM41.

TABLES: EMPLOYEE.

DATA: EMPTAB LIKE STANDARD TABLE OF EMPLOYEE INITIAL SIZE 10 WITH HEADER LINE.

SELECT * FROM EMPLOYEE.

MOVE EMPLOYEE TO EMPTAB.

APPEND EMPTAB.

ENDSELECT.

The example above demonstrates how to create an internal table that gets
its structure from an existing table/structure in the ABAP Dictionary (in this example, EMPLOYEE). This is a very valuable capability. Referencing other previously defined structures can save time (not having to code them) and problems.
The only difference between making an internal table from a TYPES statement or from an existing dictionary structure, is the use of the word TYPE or LIKE in the DATA declaration.
It is also possible to refer to other objects defined in the program.
Notice the use of MOVE instead of MOVE-CORRESPONDING. The MOVE statement is used because the structure of EMPTAB is identical to the structure of EMPLOYEE.
The above code loads the EMPLOYEE data into the internal table EMPTAB. It does not process the internal table (this will be covered in later slides).

20.  Automatic Field Conversion

When a MOVE-CORRESPONDING is performed, type conversion occurs automatically for the individual fields. The process is carried out on a field-by-field basis. MOVE specified field to specified field behaves the same way.
However, the following three scenarios are handled similarly to each other:
when you MOVE a structure to a structure of a different definition
MOVE a field to a structure
a structure to a field
In these case, the data would be converted to one long character string (type C) first, then conversion would take place.
If a piece of data is moving to a longer space in the new structure, it will be padded with spaces or zeroes according to its data type. Moving into a shorter length would cause truncation.
Structures with an internal table included as a component do not follow the typical rules.
See Online Help for extended information about all the data conversion rules.

.

21.   Mass Reading from Database Tables into Internal Tables

To read records from a database table directly into an internal table, you need a basic
SELECT * FROM <databasetable> statement with one of the following variations:

INTO TABLE <internal table>

APPENDING TABLE <internal table>

The INTO TABLE <internal table> addition fills the internal table with the selected database records. Any old entries in the internal table are overwritten.
The APPENDING TABLE <internal table> appends the selected database records to any existing entries in the internal table.
The database records are placed in the internal table EMPTAB in a single operation rather than one-by-one as in a basic SELECT processing loop.
Since no loop processing occurs, no ENDSELECT is needed.
The WHERE and ORDER BY additions are optional.
The internal table must be at least as wide as the database table. Records are placed in the internal table left-justified (i.e., starting from the first field listed in the definition of the internal table), so any additional field(s) you want in the internal table must be the last field(s) defined beyond the width of the database table.

  Coding Recommendations:

  The addition INTO CORRESPONDING FIELDS OF TABLE <itab> can be used.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

22.  Processing an Internal Table

An internal table is processed using the LOOP AT … ENDLOOP statement. On each loop pass, the system ‘reads’ the next table entry and places it in the header line. Also, the system field SY-TABIX is set to the line number of the entry read.
When internal table fields are referenced within a program (i.e., EMPTAB-COUNTRY), the data comes from the header line, not the body of the internal table. You cannot directly access values from inside the body of the internal table – you must first ‘read’ an entry into the header line.
After the WHERE parameter, you can specify a logical expression. The entire internal table is read. If at least one entry satisfies the logical expression,
SY-SUBRC is set to zero. If no table entry satisfies the logical expression,
the statements within the loop are not executed and the system field
SY-SUBRC is set to four. For each entry that satisfies the logical
expression, the statements within the loop are executed.
The programmer can use the FROM and TO parameters of the LOOP AT statement to restrict processing of an internal table to a specific block of lines.
When processing a table without a header line, the syntax of the LOOP statement is LOOP AT <internal table> INTO <work area>.

.

.

23.  System Field SY-TABIX

When an internal table is read, the system field SY-TABIX is set to the index value of the internal table line which has been placed either in the header line or the work area (depending on the type of table you are reading).
Notice the use of the FROM and TO parameters in the LOOP AT statement to restrict the processing of the internal table to a specific set of records.
It is possible to have nested loops on internal tables. Within these loops SY-TABIX is set in a similar manner to SY-INDEX (see previous chapter)

Performance Tips:

Looping at internal tables for processing is more efficient than processing within

SELECTENDSELECT loops. The following is even more efficient than nested loops:

    SELECT FROM <database table>

      FOR ALL ENTRIES IN <internal table>

      WHERE <field> = <internal table field>.

.

.

24.   The COLLECT Statement – Internal Table

When the COLLECT statement is used, ABAP scans the internal table for entries which correspond to the header line in fields which are not of type P, I or F (i.e., all of the non-numeric fields become the ‘key’ of the header line).
If such an entry is found, the system adds all P, I and F fields in the header line to the corresponding fields in the matching entry.
If no corresponding table entry is found, the contents of the header line are added to the end of the table the same effect as the APPEND statement.
The COLLECT statement is also used to load a table with unique key fields. Before adding a line to the table, the system checks to see if the table has an entry with the same key value. If an entry already exists, the record is not added, otherwise the COLLECT statement has the same effect as an APPEND statement. If COLLECT is used to fill an internal table, duplicate entries cannot occur.
When using an internal table without a header line, the syntax of the COLLECT statement changes to: COLLECT <work area> INTO <internal table>.

Performance Tips:

COLLECT can be very CPU intensive – when using an internal table with > 50 entries.

.

25.  The SORT Statement – Internal Table

An internal table is sorted using the SORT <internal table> statement. If sort criteria is not specified, the table is sorted by all fields (except those of data types P, I, and F) in ascending order in the sequence in which they were declared.
With the additional specifications BY <field name> and ASCENDING or DESCENDING, you can restrict the sort process to specific fields (or to fields of type P, I, F) and can determine the sorting sequence and hierarchy.
Where possible, the sort process should be limited by using the BY <field name> parameter. ABAP then requires less storage space in the roll area for the sorting process.
The sort process is the same whether or not the internal table has a header line.
You have the option of using a sorted table instead of a standard table. Then the entries will be sorted automatically on their way from the header line into the internal table.

Performance Tips:

It is advisable to always specify the fields to be sorted by rather than just SORT.

.

.

26.  Control Level Processing – Internal Tables

When processing an internal table with the LOOP statement, it is possible to add additional code that will only be processed when a field changes.
This is referred to as Control Level Processing (and can be compared to the GET LATE syntax seen later for Logical Database Programs)
Depending on the coding requirements, it is usually required that the internal table is sorted before control level processing occurs.
For example, some of the customer details have been stored in an internal table, and these must be printed out grouped by country, with the country only written once and with the total number for each country at the end.
The syntaxes required to perform this type of operation are:
AT FIRST …………ENDAT.
Condition is true as soon as a single record is read.
AT NEW <field>………….ENDAT.
AT END OF <field>………….ENDAT.
AT LAST………..ENDAT.
Condition is true as soon as very last record is read.
WARNING: The timing of your AT statements are crucial. For example, within a LOOP block, if you code an AT END to print a total before the generic write statement to print the original individual amounts, your last record will be left hanging after the total.

.

.

.

.

.

.

.

.

.

.

.

27.  READ TABLE – Reading a Single Entry from Internal Table

The READ TABLE <internal table> statement reads a single table entry.
When using an internal table without a header line, the syntax of the READ TABLE statement changes to: READ TABLE <internal table> INTO <work area>.
If an entry was found with the READ statement:
SY-SUBRC is set to zero,
SY-TABIX is set to the line number of the entry read,
the table entry read is placed into the internal table header line or work area.
If an entry was not found with the READ statement:
SY-SUBRC is set to a non-zero number,
SY-TABIX is undefined,
the internal table header line or work area remains unchanged.
When you perform a LOOP AT <internal table> … ENDLOOP, the effect is the same as a READ TABLE <internal table> INDEX <i> where <i> starts at one and continues incrementing until the entire internal table is read. In other words, with each loop pass, SY-TABIX is set to the line number of the entry read and the header line or work area contains the data from the entry read.

.

28.  READ TABLE – Reading a Single Entry Options

READ TABLE <internal table>.
The contents of the header line determine the table entry to be read. ABAP searches for the first entry in the internal table that matches the header line’s search term which consists of all non-numeric fields with contents not equal to space.
READ TABLE <internal table> WITH KEY ‘<key>‘.
Enter the search argument after the parameter KEY (in single quotes).
Beginning with the first character of the first field of the first entry in the table, ABAP compares each record character by character with the search argument (‘<key>‘).
READ TABLE <internal table> WITH KEY ‘<key>‘ BINARY SEARCH.
Like variant 2, but using a binary search (faster than linear search).
The internal table must be sorted in ascending order by the
search argument.
READ TABLE <internal table> INDEX <i>.
The i-th table entry is read.
For information on the other READ options available, see Online Help.

Performance Tips:

 A BINARY SEARCH should always be used whenever possible, but the table MUST be sorted first.

.

29.  Maintaining Internal Tables

The INSERT <internal table> INDEX <i> statement generates a new table entry before line <i> with the contents of the header line. If the table <EMPTAB> has no entries, the contents of the header line are added to the table.
The MODIFY <internal table> INDEX <i> statement overwrites table line <i> with the contents of the header line. Line <i> must already exist.
The DELETE <internal table> INDEX <i> statement deletes table line <i>.
Within a LOOP AT <internal table> … ENDLOOP, you can make changes to an internal table. The line affected is always the current line (SY-TABIX).
INSERT <internal table>:
A new line with the contents of the header line is inserted before the current line.
MODIFY <internal table>:
The current line is overwritten by the contents of the header line.
DELETE <internal table>:
The current line is deleted.
Check SY-SUBRC after every attempt to change a table entry. If the change was successful, SY-SUBRC will be set to zero.

  Performance Tips:

  INSERT/MODIFY/DELETE <internal table> WHERE …. is more efficient than first LOOPing AT the table using the WHERE clause, then maintaining the tables header line.

.

.

.

.

.

30.  Working with an Internal Table without a Header Line

A work area (staging area) is required when working with an internal table without a header line. This work area is defined as a Structure with the same structure as the internal table. The work area is loaded and the table is processed from the work area.
A summary of the statements used for internal tables without header lines is
the following:
APPEND <work area> TO <internal table>
Appends the contents of the work area to the end of the internal table
COLLECT <work area> INTO <internal table>
Accumulates the values on a field into the table
INSERT <work area> INTO <internal table>
Inserts a new line with the contents of the work area before the
current line
MODIFY <internal table> FROM <work area>
Overwrites a line in the table with the contents of the work area
READ TABLE <internal table> INTO <work area>
Reads a line from the table into the work area
LOOP AT <internal table> INTO <work area>
Processes an internal table. On each loop pass, a table entry is placed in the work area.

.

.

.

.

.

.

.

.

.

.

31.  Deleting an Internal Table

The CLEAR <internal table> statement initializes all single fields in the header line of an internal table according to type.
The REFRESH <internal table> statement deletes all table lines. The table storage space is not released. The header line remains unchanged.
The FREE <internal table> statement releases the storage space required for a table. The header line remains unchanged.
This statement is particularly useful for very large internal tables. You can improve a program’s performance by ‘freeing’ the memory space allocated for the internal table.
Internal tables that are local to a subroutine are automatically ‘freed’ upon leaving the subroutine.
WARNING: If you are working with an internal table with a separate work area, and you accidentally say CLEAR <internal table>rather than CLEAR <internal table work area >, you will delete all the table lines. Use REFRESH to achieve this instead.

.

32.  Information about an Internal Table

The DESCRIBE TABLE <internal table> statement provides information about an internal table’s attributes. With this statement, the programmer must use at least one of the two parameters available LINES and OCCURS.
The LINES parameter allows the programmer to find out the number of existing table entries.
The OCCURS parameter contains the value of the OCCURS clause specified in the internal table definition.
Notice in the example above the internal table can have more records in it than the number specified in the OCCURS clause.

Performance Tips:

  Always use DESCRIBE to find out how many entries there are in an internal table – it is much more efficient than LOOPING AT the internal table and incrementing a counter.

.

.

.