internal table

[Former Member]

what r the different methods to insert data in internal table?could u plzz tell

[Former Member]

Hi soniya,

The most used and best way is to insert the data using the select statement and retreiving it from DB and then writing it into our Internal Table.

Hope this is helpful.

Reward well.

Regards.

[Former Member]

Hello,

APPEND,INSERT

Syntax Diagram 
APPEND 

Variants: 
1. APPEND [wa TO|INITIAL LINE TO] itab.

2. APPEND LINES OF itab1 [FROM idx1] [TO idx2] TO itab2.

3. APPEND [wa TO] itab SORTED BY f.




In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Short forms of line operations not allowed. 

Variant 1 
APPEND [wa TO|INITIAL LINE TO] itab. 



Effect 
Appends a new line to the end of the internal table itab. You can only use this variant with index tables (standard or sorted table). 

If you specify wa TO , the new line is taken from the contents of the explicitly specified work area wa. 

If you use INITIAL LINE TO, a line filled with the correct initial value for the type is added. 

If the part before itab is omitted, the new line is taken from the header line of the internal table itab. 

After the APPEND, the system field SY-TABIX contains the index of the last line in the table. 


If the target table itab is a SORTED TABLE, it must be sorted correctly after the append, otherwise a runtime error results. 



Examples 
Generate a list with customer numbers: 



TABLES SCUSTOM. 
DATA: CUSTOMER TYPE STANDARD TABLE OF SCUSTOM-ID WITH 
                    NON_UNIQUE DEFAULT KEY. 

APPEND SCUSTOM-ID TO CUSTOMER. 



Append a blank line or a line with its initial value to the above list: 



APPEND INITIAL LINE TO CUSTOMER 



Generate a compressed list with plane data 



PARAMETERS: SEATS_LO LIKE SAPLANE-SEATSMAX DEFAULT 30, 
            SEATS_HI LIKE SAPLANE-SEATSMAX DEFAULT 50. 

DATA: PLANE        TYPE STANDARD TABLE OF SAPLANE WITH 
                        NON-UNIQUE DEFAULT KEY, 
      PLANE_NEEDED LIKE SAPLANE WITH HEADER LINE. 

LOOP AT PLANE INTO PLANE_NEEDED 
              WHERE SEATSMAX BETWEEN SEATS_LO AND SEATS_HI. 
  APPEND PLANE_NEEDED. 
ENDLOOP. 



Notes 
Performance: 


Avoid unnecessary assignments to the header line when using internal tables with a header line. Whenever possible, use statements that have an explicit work area. 
For example, "APPEND wa TO itab." is approximately twice as fast as "itab = wa. APPEND itab.". The same applies to COLLECT and INSERT. 


In contrast to COLLECT, APPEND does not check whether an entry with the same key exists. Therefore, it is considerably faster than COLLECT. If the COLLECT logic is not needed or lines with an identical default key cannot occur in a particular situation, you should always use APPEND instead of COLLECT. 


The runtime required for APPEND increases with the line width of the table and depends on the number of fields. Appending an entry to an internal table with a width of 100 bytes takes about 10 msn (standardized microseconds). 


To append an internal table to another internal table, you should use the variant APPEND LINES OF ... which is 3 to 4 times faster than using a LOOP to process the source table and append the entries line-by-line to the target table. 



Variant 2 
APPEND LINES OF itab1 [FROM idx1] [TO idx2] TO itab2. 



Effect 
Appends the internal table itab1 or a block of lines from itab1 to the end of the internal table itab2. 
You can only use this variant with index tables (standard or sorted table). 

By specifying FROM idx1 or TO idx2, you can restrict the line area taken from the source table itab1. If there is no FROM specification, it begins with the first line of itab1. If there is no TO specification, it ends with the last line of itab1. This means that the complete table is appended if neither a FROM nor a TO is specified. 

After the APPEND, the system field SY-TABIX contains the index of the last table entry appended, i.e. the total number of entries from the target table. 


If the target table itab is a SORTED TABLE, it must be correctly sorted after the append, otherwise a runtime error occurs. 



Example 
Merge two tables containing integers: 


DATA: ITAB1  TYPE STANDARD TABLE OF I WITH NON-UNIQUE 
                  DEFAULT KEY INITIAL SIZE 100,       ITAB 2 TYPE STANDARD TABLE OF I WITH NON-UNIQUE 
                  DEFAULT KEY INITIAL SIZE 100. 

APPEND 2 TO ITAB1. 
APPEND 3 TO ITAB1. 
APPEND 5 TO ITAB1. 
APPEND 7 TO ITAB1. 

APPEND 3 TO ITAB2. 
APPEND INITIAL LINE TO ITAB2. 

APPEND LINES OF ITAB1 FROM 2 TO 20 TO ITAB2. 



The table ITAB2 now contains five lines with the values 3, 0, 3, 5 and 7. 



Note 
Performance: 


This variant is 3 to 4 times faster than using a LOOP to process the source table and append the entries line-by-line to the target table. 



Variant 3 
APPEND [wa TO] itab SORTED BY f. 



Effect 
Inserts the new entry into table and re-sorts the table by the sub-field f in descending order. This only makes sense if the table was sorted beforehand. When the number of table entries reaches the INITIAL SIZE parameter value, the last entry is deleted if the value f of a new entry is greater (particularly suitable for ranked lists). You can only sort by one component, and may only use this variant with a STANDARD TABLE. 

If you specify wa TO, the new line is taken from the contents of the explicitly specified work area wa. Otherwise, it comes from the header line of the internal table itab. 



Example
TYPES: BEGIN OF COMPANIES_TYPE, 
        NAME(10), SALES TYPE I, 
      END   OF COMPANIES_TYPE. 

DATA COMPANIES TYPE STANDARD TABLE OF COMPANIES_TYPE 
          INITIAL SIZE 3, 
     WA_COMPANIES TYPE COMPANIES_TYPE. 

WA_COMPANIES-NAME = 'big'. 
WA_COMPANIES-SALES = 90. 
APPEND WA_COMPANIES TO COMPANIES. 

WA_COMPANIES-NAME = 'small'. 
WA_COMPANIES-SALES = 10. 
APPEND WA_COMPANIES TO COMPANIES. 

WA_COMPANIES-NAME = 'too small'. 
WA_COMPANIES-SALES =  5. 
APPEND WA_COMPANIES TO COMPANIES. 

WA_COMPANIES-NAME = 'middle'. 
WA_COMPANIES-SALES = 50. 
APPEND WA_COMPANIES TO COMPANIES SORTED BY SALES. 



The table now has three (-> INITIAL SIZE 3) entries. The line with the contents 'too small' in the sub-field NAME is deleted from the table because the entry for 'middle' has a greater value in the component SALES. This entry now appears in the second table line (after 'big' and before 'small'). 



Notes 
Whenever an internal table is processed with APPEND SORTED BY, it should always be filled in this way. 


If you specify APPEND with the parameter SORTED BY, the system always searches the entire table. Therefore, it is sometimes better to create the table with a simple APPEND and then use SORT to sort in descending or ascending order afterwards. 
You can also sort in ascending order by first determining the insert position with READ TABLE itab WITH KEY f = itab-f BINARY SEARCH and then by inserting the new entry into the table (perhaps read SY-SUBRC beforehand) with INSERT itab INDEX SY-TABIX. 
However, you should be aware that, in such cases, the table may contain more entries than specified in the OCCURS parameter. 


If several lines with an identical value f are added, lines added later are treated as smaller, i.e. they are inserted after existing lines with the same value f. 


If you use APPEND ... SORTED BY f with an explicitly specified work area, this must be compatible with the line type of the internal table. 


If the sort criterion f is not known until runtime, you can use SORTED BY (name) to specify it dynamically as the contents of the field name. If name is blank at runtime or contains an invalid component name, a runtime error occurs. 


Regardless of whether you specify it statically or dynamically, you can restrict the sort criterion f further by defining an offset and/or length. 



Note 
Runtime errors: 


TABLE_INVALID_INDEX: Invalid index value (<= 0) in a FROM, TO or INDEX specification. 

ITAB_ILLEGAL_SORT_ORDER: Sort order is incorrect following an APPEND to a sorted table. 

ITAB_DUPLICATE_KEY_IDX_OP: Inserting a key with indentical key to an existing entry where the target table is defined with UNIQUE. 



Related 
COLLECT itab, INSERT itab, SELECT / FETCH NEXT CURSOR ... INTO/APPENDING TABLE itab , MODIFY itab, WRITE f TO itab INDEX idx, SORT itab, READ TABLE itab, LOOP AT itab, DELETE itab 


Additional help 
Appending Table Lines 

INSERT - Insert into an Internal Table 


Variants: 
1. INSERT [wa INTO|INITIAL LINE INTO] itab [INDEX idx]. 
2. INSERT [wa INTO|INITIAL LINE INTO] TABLE itab. 
3. INSERT LINES OF itab1 [FROM idx1] [TO idx2] 
             INTO itab2 [INDEX idx3]. 
4. INSERT LINES OF itab1 [FROM idx1] [TO idx2] 
             INTO TABLE itab2. 



In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Short forms not allowed in line operations. 

Variant 1 
INSERT [wa INTO|INITIAL LINE INTO] itab [INDEX idx]. 



Effect 
Inserts a new line in the internal table itab using an explicit or implicit index specification. You can only use this variant with index tables (standard or sorted tables). 

If you use "wa INTO" the contents of the work area wa are used as the new line. If the respective types of wa and itab are incompatible, the contents of wa are moved according to MOVEy logic. 

If you use INITIAL LINE INTO a line is inserted in the table, filled with the initial values appropriate to the field types. 

If you do not specify anything before itab, the new line is taken from the header line of the internal table itab. 

You use INDEX idx to specify the table index before which the line is inserted into itab. If the table has idx - 1 entries, the line is appended to the end of the table. 

If you are adding entries to an index table using a LOOP, you can leave out the INDEX idx specification. The source table is inserted before the current line in the LOOP (implicit index specification). 

If the target table itab has the type SORTED TABLE , it must be correctly sorted after you have finished inserting lines, otherwise a runtime error is triggered. 

If the target table is defined with a UNIQUE KEY, the uniqueness must be preserved when you insert new lines. If it is not, a runtime error is triggered. 

The return code is set as follows: 

When you specify the insertion point using INDEX idx: 

SY-SUBRC = 0: 
The line was inserted successfully 
SY-SUBRC = 4: 
The index specified was too large. The line was not inserted, since the table has less than idx - 1 entries. 


If you do not use INDEY idx, return code is set to 0. 



Notes 
Within a LOOP ... ENDLOOP, the insertion of table lines takes effect in the next loop pass. 


Illegal index specifications (idx <= 0) cause a runtime error. 



Example 
Adding values to a table of whole numbers: 


DATA: VALUE TYPE I, 
      ITAB  TYPE I OCCURS 100 WITH HEADER LINE. 

ITAB  = 5. 
VALUE = 36. 

INSERT ITAB INDEX 1. 
INSERT VALUE INTO ITAB INDEX 2. 
INSERT INITIAL LINE INTO ITAB INDEX 2. 



Die Tabelle ITAB enthält nun drei Zeilen mit den Werten 5, 0 und 36. 



Variant 2 
INSERT [wa INTO|INITIAL LINE INTO] TABLE itab. 


Effect 
Inserts generically with a key into an internal table. The key values are taken from the work area. If you specify the work area explicitly, it must have a type compatible with the line type of the table. 

In contrast to variant 1, you can use this variant for any table. 

If the target table has a UNIQUE KEY, the system ignores any duplicates when you insert lines and sets SY-SUBRC as described below. 

The way in which the system inserts a new entry into the table depends on the table type: 



STANDARD TABLE: 
The new entry is added to the end of the table. Generic insertion is therefore the same as an APPEND. 


SORTED TABLE: 
The new entry is added in its appropriate place, determined by the table key. The key values are taken from the specified work area wa or from the header line of the table. If the key is NON-UNIQUE, the entry is placed at the top of the list of duplicates. The insertion point is determined internally using a binary search. This makes the relationship between the runtime required and the number of table entries logarithmic. 


HASHED TABLE: 
The new entry is placed in the internal hash administration of the table according to the table key. The key values are taken from the specifiedwork area wa or the header line of the table. The runtime required remains constant, since it does not depend on the number of table entries. The key must be unique. 


The return code is set as follows: 


SY-SUBRC = 0: 
Entry added to the table. 
SY-SUBRC = 4: 
The entry could not be added to the table, since it duplicates an existing entry and the table is defined with a UNIQUE KEY. 


Example 
Construct a table sorted by name and age: 


TYPES: BEGIN OF PERSON, 
         NAME(10) TYPE C, 
         AGE      TYPE I, 
       END OF PERSON. 

DATA: P    TYPE PERSON, 
      PTAB TYPE SORTED TABLE OF PERSON 
                WITH UNIQUE KEY NAME AGE. 

P-NAME = 'Steve'. P-AGE = 20. INSERT P INTO TABLE PTAB. 
P-NAME = 'Andy'.  P-AGE = 20. INSERT P INTO TABLE PTAB. 
P-NAME = 'Steve'. P-AGE = 17. INSERT P INTO TABLE PTAB. 
P-NAME = 'Andy'.  P-AGE = 20. INSERT P INTO TABLE PTAB. 



Die Tabelle enthält nun die folgenden Einträge: 

   Andy               20 
   Steve              17 
   Steve              20 

SY-SUBRC is set to 4. 



Variant 3 
INSERT LINES OF itab1 [FROM idx1] [TO idx2] INTO itab2                                             [INDEX idx3]. 



Effect 
Inserts the internal table itab1 or an extract of it into the internal table itab2. This operation is the same as using a loop at the source area and inserting the entries into the target table line-by-line. 

In INDEX idx3, like in variant 1, you specify the table index position before which you want to insert the entry in itab2. itab2 cannot have the type HASHED or ANY TABLE, since these tables have no defined index operations. 

If you are using a LOOP you can omit the INDEX idx3 specification. The entry is then inserted in the target table before the current LOOP line. 

If the target table itab2 has the type SORTED TABLE, it must be correctly sorted when you have finished adding entries. Otherwise, a runtime error occurs. 

If the target table is defined with a UNIQUE KEY, you must ensure that this characteristic is preserved when you add more entries to it. If you try to add duplicate records, a runtime error occurs. 

You can restrict the number of lines taken from the source table itab1 by using FROM idx1 and TO idx2. If you omit FROM idx1, the range begins at the first line of itab1. If you omit TO idx2, the range ends at the last line of itab1. This means that if you omit both FROM and TO, the whole table is inserted into the target table. If itab1 has the table type HASHED or ANY TABLE, you may not use the FROM or TO additions, since these table types have no defined index operations. 

return code is set in the same way as in variant 1. If you insert an empty table, SY-SUBRC is set to 0. 



Notes 
You can find out the size of table itab1 before or after the INSERT statement using the DESCRIBE TABLE itab1 LINES ... statement. You can then see how many lines were added to the table. 



Within a LOOP ... ENDLOOP, inserting table entries affects subsequent loop passes. 



Illegal index specifications, such as idx1 <= 0, cause a runtime error. 



Example 
Insert one table of names into another table of names: 


TYPES NAME(10) TYPE C. 

DATA: NAME_TAB_1 TYPE STANDARD TABLE OF NAME WITH 
                      NON-UNIQUE DEFAULT KEY INITIAL SIZE 5, 
      NAME_TAB_2 TYPE STANDARD TABLE OF NAME WITH 
                      NON-UNIQUE DEFAULT KEY INITIAL SIZE 5. 

APPEND 'Alice'  TO NAME_TAB_1. 
APPEND 'Martha' TO NAME_TAB_1. 
APPEND 'Ruth'   TO NAME_TAB_1. 

APPEND 'Harry'  TO NAME_TAB_2. 
APPEND 'Walter' TO NAME_TAB_2. 

INSERT LINES OF NAME_TAB_1 FROM 2 INTO NAME_TAB_2 INDEX 2. 



Afterwards, NAME_TAB_2 contains four entries with the names Harry, Martha, Ruth and Walter. 



Variant 4 
INSERT LINES OF itab1 [FROM idx1] [TO idx2] INTO TABLE itab2. 
See Compatible line types with INSERT INTO TABLE. 



Effect 
Generic insertion of internal table itab1 or an extract of it into internal table itab2. 

Unlike variant 3, you can use this variant for any source or target table. 

The way in which the lines from the source table itab1 are inserted into the target table itab2 depends, as in variant 2, on the table type of itab2. 

If the target table is defined with a UNIQUE KEY, you must ensure that this characteristic is preserved when you add new entries. If you try to add duplicate entries, a runtime error occurs. If the key is non-unique, duplicates from the source table are inserted before the entries in the target table. The sequence of the duplicates is the same as in the source table. 



Notes 
Performance: 


Avoid unnecessary assignments to the header line when using internal tables with a header line. Whenever possible, use statements that have an explicit work area. 
For example, "APPEND wa TO itab." is approximately twice as fast as "itab = wa. APPEND itab.". The same applies to COLLECT and INSERT. 


When you add a line to an index table, index maintenance costs result. These depend on the insertion point in the table. 

Inserting a line into the middle of an internal table 100 bytes wide with 200 entries, requires around 90 msn (standard microseconds). 


If you want to add an internal table to another internal table, the index maintenance costs only occur once when you use the INSERT LINES OF ... variant. This is considerably faster than using a LOOP to insert lines one-by-one from the source table into the target table. 

Inserting a table 100 bytes wide with 500 entries into the middle of a similar-sized table can be up to 20 times quicker. 



Note 
Runtime errors: 


TABLE_INVALID_INDEX: Invalid index value (<= 0) in a FROM, TO or INDEX addition. 

ITAB_DUPLICATE_KEY: You inserted a set of lines, more than one of which had the same key (target table defined with UNIQUE). 

ITAB_ILLEGAL_SORT_ORDER: The sort sequence has not been maintained in an INSERT with index into a sorted table. duplicate key. 



Related 
COLLECT itab, APPEND, SELECT / FETCH NEXT CURSOR ... INTO/APPENDING TABLE itab , MODIFY itab, WRITE f TO itab INDEX idx, SORT itab, READ TABLE itab, LOOP AT itab, DELETE itab 


Additional help 
Inserting Table Entries 

Inserting Table Entries Using the Index 

Syntax Diagram 
COLLECT 


Basic form 
COLLECT [wa INTO] itab. 


Addition: ... SORTED BY f 



In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Short forms of line operations not allowed. 

Effect 
COLLECT allows you to create unique or summarized datasets. The system first tries to find a table entry corresponding to the table key (see Key definition for internal tables ). The key values are taken either from the header line of the internal table itab, or from the explicitly-specified work area wa. itab must have a flat structure, that is, it may not contain other internal tables. All components that are not part of the key must be have numeric types (see ABAP numeric types). 
If the system finds an entry, the numeric fields that are not part of the table key (see ABAP number types) are added to the sum total of the existing entries. If it does not find an entry, the system creates a new entry instead. 
The way in which the system finds the entries depends on the type of the internal table: 


STANDARD TABLE: 
The system creates a temporary hash administration for the table to find the entries. This means that the runtime required to find them does not depend on the number of table entries. The administration is temporary, since it is invalidated by operations like DELETE, INSERT, MODIFY, or SORT. A subsequent COLLECT is then no longer independent of the table size, because the system has to use a linear search to find entries. For this reason, you should only use COLLECT to fill standard tables. 


SORTED TABLE: 
The system uses a binary search to find the entries. There is a logarithmic relationship between the number of table entries and the search time. 


HASHED TABLE: 
The system uses the internal hash administration of the table to find records. Since (unlike standard tables), this remains intact even after table modification operations, the search time is always independent of the number of table entries. 


For standard tables and SORTED TABLEs, the system field SY-TABIX contains the number of the existing or newly-added table entry after the APPEND. With HASHED TABLEs, SY-TABIX is set to 0. 


Notes 
COLLECT allows you to create a unique or summarized dataset, and you should only use it when this is necessary. If neither of these characteristics are required, or where the nature of the table in the application means that it is impossible for duplicate entries to occur, you should use INSERT [wa INTO] TABLE itab instead of COLLECT. If you do need the table to be unique or summarized, COLLECT is the most efficient way to achieve it. 



If you use COLLECT with a work area, the work area must be compatible with the line type of the internal table. 



If you edit a standard table using COLLECT, you should only use the COLLECT or MODIFY ... TRANSPORTING f1 f2 ... statements (where none of f1, f2, ... may be in the key) enthalten sein). Only then can you be sure that: 

-The internal table actually is unique or summarized 

-COLLECT runs efficiently. The check whether the dataset 
already contains an entry with the same key has a constant 
search time (hash procedure). 

If you use any other table modification statements, the check for entries in the dataset with the same key can only run using a linear search (and will accordingly take longer). You can use the function module ABL_TABLE_HASH_STATE to test whether the COLLECT has a constant or linear search time for a given standard table. 



Example 
Summarized sales figures by company: 



TYPES: BEGIN OF COMPANY, 
        NAME(20) TYPE C, 
        SALES    TYPE I, 
      END OF COMPANY. 

DATA: COMP    TYPE COMPANY, 
      COMPTAB TYPE HASHED TABLE OF COMPANY 
                                WITH UNIQUE KEY NAME. 

COMP-NAME = 'Duck'.  COMP-SALES = 10. COLLECT COMP INTO COMPTAB. 
COMP-NAME = 'Tiger'. COMP-SALES = 20. COLLECT COMP INTO COMPTAB. 
COMP-NAME = 'Duck'.  COMP-SALES = 30. COLLECT COMP INTO COMPTAB. 



Table COMPTAB now has the following contents: 

          NAME    | SALES 
          --------------- 
          Duck    |   40 
          Tiger   |   20 




Addition 
... SORTED BY f 

Effect 
COLLECT ... SORTED BY f is obsolete, and should no longer be used. It only applies to standard tables, and has the same function as APPEND ... SORTED BY f, which you should use instead. (See also obsolete statements.) 



Note 
Performance: 


Avoid unnecessary assignments to the header line when using internal tables with a header line. Whenever possible, use statements that have an explicit work area. 
For example, "APPEND wa TO itab." is approximately twice as fast as "itab = wa. APPEND itab.". The same applies to COLLECT and INSERT. 


The runtime of a COLLECT increases with the width of the table key and the number of numeric fields whose contents are summated. 



Note 
Runtime errors: 



COLLECT_OVERFLOW: Overflow in an integer field during addition 



COLLECT_OVERFLOW_TYPE_P: Overflow in a type P field during addition. 



TABLE_COLLECT_CHAR_IN_FUNCTION: COLLECT on a non-numeric field. 



Related 
APPEND, WRITE ... TO, MODIFY, INSERT 


Additional help 
Inserting Summarized Lines 

Regards,

Vasanth

[Former Member]

Hi,

Here isthe different methods:

1)Select f1 f2 from db table INTO TABLE ITAB where ...

2)Select f1 f2 from db table into (ITAB-f1, ITAB-f2) where...

append ITAb.Clear ITAB.

Endselect.

3) Select f1 f2 from db table INTO CORRESPONDING FIELDS of ITAB where....

4) Select single * from kna1 where ..

move-corresponding from kna1 to ITAB.

Regards,

Anji

[Former Member]

hi

there are multiple methods to insert data into internal table

one is by writing a select query or select statement

using append and insert statementand even copying the contents of one table 2 another by using ITAB1[] = ITAB2[].

regards,

kiran kumar k

[Former Member]

Hi Buddys,

Vasant's Reply is really appreciable.

Thanks,

Kaleem.

[Former Member]

Please try this, if u are selecting by a select query,

[Select * from SAPDB into TABLE itab.]

[Select * from SAPDB into corresponding feilds of TABLE itab.

When steucture is not of SAPDB type.]

[Select * from SAPDB into w_itab.

Append w_itab to itab.

Endselect.]

Hope this works to an extent.