Processing an internal table is done in an Abap specific way. With internal tables, a work area is required. Actual changes are done on the fields in a work area, which can be appended (APPEND) at the end of the internal table or inserted (INSERT) at a given position (by specifying an index number). Since internal tables play such a big big role in Abap reporting, check out this article internal table specifics. Here's a listing of actions you can do to your internal table:

The examples apply to the following internal table definition:

  TYPES: begin of ty_material,
                matnr type mara-matnr, 
                mtart type mara-mtart,
                owner type char40, 
              end of ty_material. 
  DATA: ta_materials type standard table of ty_material, 
           wa_material type ty_material. 

  * Some testdata: 
    select matnr mtart from mara into table ta_materials
      up to 20 rows. 

• Read an entry from the table, to determine the material type for a material number

  READ TABLE ta_materials 
    WITH KEY matnr = 'A123' INTO wa_material.
  

  Note that SY-SUBRC can be checked to determine whether the read had a result. INTO wa_material is required to instruct the read statement where to place the results. If the table was defined as a table WITH HEADER LINE then the variabele ta_materials would hold the selection results (for which INTOshould be omitted).

   

• If an internal table has no actual fields, using the READ statement (in OOPS context) requires a little extra attention. Error message: "The variant " WITH KEY k" is no longer supported in the OO context. Use an explicit key specification instead.". A solution is the TABLE_LINE addition, like so:

  DATA: lta_vbap_posnr TYPE STANDARD TABLE OF vbap-posnr,
         lva_item_nr_we_need_to_check type vbap-posnr. 
  
  * ... 
  READ TABLE lta_vbap_posnr 
    WITH KEY TABLE_LINE = lva_item_nr_we_need_to_check
    TRANSPORTING NO FIELDS. "We are only checking existance
  

   

• Loop through an internal table, to process logic that needs to be executed for each line on the table.

    LOOP AT ta_materials INTO wa_material.
    * perform whatever logic using wa_material 
      wa_material-owner  'PIETJE'. 
      MODIFY ta_materials FROM wa_material. 
    ENDLOOP.
  

  Note that a MODIFY statement executed from within a LOOP .. ENDLOOPstatement, will modify the current entry (hence it is not needed to specify an index).

   

• Loop through an internal table with a WHERE clause to specify which entries should be processed.

    LOOP AT ta_materials INTO wa_material
      WHERE owner = ''. 
    * perform whatever logic using wa_material 
      wa_material-owner  'KLAASJE'. 
      MODIFY ta_materials FROM wa_material. 
    ENDLOOP.
  

  Thus only the entries which have no value for the OWNER field is processed. If no such entries are available, the SY-SUBRC value will be set to 4 just after the ENDLOOP statement. So this example will set the owner to a specific value, if no owner was available. 

   

• Add a new line to the table

    wa_material-matnr = 'A123-2'. 
    wa_material-mtart = 'DIEN'. 
    wa_material-owner = 'JOHN'. 
    APPEND wa_material TO ta_materials. 
  

  Note, when the append is done multiple times, the same line will be added to the internal table multiple times.

   

• Insert a new line into the table

    wa_material-matnr = 'A123-2'. 
    wa_material-mtart = 'DIEN'. 
    wa_material-owner = 'JOHN'. 
    INSERT wa_material INTO ta_materials INDEX 1. 
  

  Insert the new line into the start of the internal table. Specify another index to insert elsewhere. E.g. INDEX 3will insert the line into the table where the new location of the line will become index 3 (anything below the given index will shift).

   

• Change all "owner" values from 'KLAASJE' to 'ROBERT' in the internal table:

    wa_material-owner = 'ROBERT'. 
    MODIFY ta_materials FROM wa_material TRANSPORTING owner
      WHERE owner = 'KLAASJE'. 
  

  Note that only the owner field should be changed, which is controlled with the TRANSPORTING option.

   

• The same as above:

    wa_material-owner = 'ROBERT'. 
    lv_old_owner = 'KLAASJE'. 
    MODIFY ta_materials FROM wa_material TRANSPORTING owner
      WHERE owner = lv_old_owner. 
  

  Note that only the owner field should be changed, which is controlled with the TRANSPORTING option.

   

• The actual where clause can also be set up as something dynamic:

    lv_where_clause = 'OWNER = '' && lv_naam && ''. 
    LOOP AT ta_materials INTO wa_material
      WHERE (lv_where_clause).
    ENDLOOP. 
  

   

• An alternative to using a variabele as work area is using a field symbols variabele. Field symbols are in fact pointers so when an change to a field is done via it's assigned field-symbol, the actual table field is already updated (as they are one and the same). No MODIFYneeded !

  FIELD-SYMBOLS: <fs_material> type ty_material. 
  
    LOOP AT ta_materials ASSIGNING <fs_material>.
      <fs_material>-mtart = 'QUQ'. 
    ENDLOOP. 
  

   

• Add multiple lines from a table to another table: APPEND LINES OF ta_materials_new TO ta_materials.. This can also be done with a subset of the original table: APPEND LINES OF ta_materials_new TO ta_materials FROM 2 TO 5., which will append only lines 2 to 5 of the ta_materials_newtable.

   

• Insert multiple lines from a table into another table: INSERT LINES OF lt_abap_coding INTO gt_abap_coding INDEX lw_statement-trow.. This too can be done for only a part of the source table, by specifying FROM .. TO ...

   

• Delete certain lines from the table: DELETE ta_materials WHERE owner = ''. Removes the entries for which no OWNERis available.

   

• Initialize a whole internal table: CLEAR: ta_materials[].The brackets indicate it it the table (and not it's header line) you want to clear.

   

• A table without a structure (ergo with only 1 field) or which has a structure that can be overlayed with character fields (thus no N fields in the table definition), can be appended to with constant values:

  APPEND 'MATERIAL001       DIENKLAAS' to ta_materials.

  This will add a line with all 3 fields populated to the table.

   

• Initialize a table without structure with a set of values:

    clear gt_keywords[].
    split 'FORM:ENDFORM:MODULE:ENDMODULE:CLASS:' && 
  'ENDCLASS:METHOD:ENDMETHOD'
      at ':' into table gt_keywords.
  

   

• Copy an internal table: ta_materials_copy[] = ta_materials[]. The structures of these tables need to be the same.

   

• If the table type you are working with is HASHED TABLE (or SORTED) then you will notice that the classic APPEND does not work. The APPEND would simply add the line at the end, which is a bit of a killer for a hashed table. Use INSERT lw_material INTO TABLE lt_materials. instead: the INSERTstatement will make sure the table remains hashed.

   

• If you need to filter your table for relevant objects and discard the rest, use the DELETE ADJACENT DUPLICATES statement. It allows setting the fields to compare and in combinaton with the SORTstatement, you can effectively do anything to your table. Note that the first matching entry is also the entry that remains in the table, see example below.

  types: begin of ty_t,
           f1,
           f2,
         end of ty_t.
  data: lt_t type STANDARD TABLE OF ty_t,
        lw_t type ty_t.
  
  append: '1B' to lt_t.
  append: '1F' to lt_t.
  append: '1Z' to lt_t.
  append: '1A' to lt_t.
  
  sort lt_t by f1 f2 descending.
  DELETE ADJACENT DUPLICATES FROM lt_t COMPARING f1.
  
  read table lt_t index 1 into lw_t.
  write: lw_t-f2, lines( lt_t ).

  The outcome of the above is 'Z 1', because the F2 field is sorted in descending order. Thus the delete adjacent duplicates statememnt will hold on to the first value / record it finds.

   

When processing an internal table, the system variabele SY-TABIX is set to the table index last processed.

• Prev
• Next