INternal table

[Former Member]

ABAP GURU"s

Provide the coding for following details.

1-we have two internal table with some feilds and we want to extract both table data into third internal table.

2- how many types we create internal table give details with examples.

PLz reply me.

THanks..

[Former Member]

there are 3 types of internal table

sorted

hash

standard

for combining 2 internal tables u have to populate 3rd internal table having all the fields of that 2 internal tables in it

and loop on the two internal table transferring values into third internal table

eg.

Consider you have 2 internal tables say itab1, itab2.

Itab1 has fng fields say A, B, C, D.

Itab2 has fng fields say D, E.

To combine itab1 and itab2,,,

loop at itab1

itab3-fld1 = itab1-fld1.

itab3-fld2 = itab1-fld2.

itab3-fld3 = itab1-fld3.

append itab3.

clear itab3.

endloop.

loop at itab2.

itab3-fld4 = itab1-fld4.

itab3-fld5 = itab1-fld5.

append itab3.

clear itab3.

endloop.

reward if helpful

Edited by: Ashish Paliwal on Apr 3, 2008 4:45 PM

[Former Member]

Hi Sachin,

MOVING DATA BETWEEN TWO INTERNAL TABLES

look at the folowing code for reference

*&--mard structure

types: begin of struc_mard,

matnr type matnr, "Material Number

werks type werks_d, "Plant

lgort type lgort_d, "Storage Location

labst type labst, "Valuated stock with unrestricted use

end of struc_mard.

*&--mara structure

types: begin of struc_mara,

matnr type matnr, "material number

meins type meins, "unit of measurement

mtart type mtart, "material type

ersda type ersda, "Creation date

end of struc_mara.

*&--maktx structure

types: begin of struc_maktx,

matnr type matnr, "material number

maktx type maktx, "material description

end of struc_maktx.

*&--Final structure

types: begin of struc_final,

matnr type matnr, "Material Number

werks type werks_d, "Plant

lgort type lgort_d, "Storage Location

labst type labst, "Valuated stock with unrestricted use

meins type meins, "unit of measurement

mtart type mtart, "material type

ersda type ersda, "Creation date

maktx type maktx, "material description

v_box(1) type c, "for checkbox field

end of struc_final.

*&---work area for Internal Tablespopulation 1

data: wa_mard type struc_mard,

wa_mara type struc_mara,

wa_maktx type struc_maktx,

wa_final type struc_final.

-

---

INTERNAL TABLES DECLARATION *

-

---

*&---Internal tables for storing data.populaiton 1

data: i_mard type standard table of struc_mard,

i_mara type standard table of struc_mara,

i_maktx type standard table of struc_maktx,

i_final type standard table of struc_final.

*&--fetching the data from table for storage

select matnr

werks

lgort

labst

into table i_mard

from mard

where matnr in r_matnr and werks in r_werks and lgort in

r_lgort

.

if sy-subrc 0. "if unsuccesful

message e004. "Error- Record does not exist

endif.

selection of material description

if i_mard[] is not initial.

*SELECT DISTINCT FOR UNIQUE ENTRIES ONLY

select distinct matnr

maktx

into table i_maktx

from makt

for all entries in i_mard

where matnr = i_mard-matnr and

spras = sy-langu.

if sy-subrc 0. " if unsucessful

wa_maktx-maktx = text-028. "NO DESCRIPTION

endif.

*fetching information from material master

select distinct matnr

meins

mtart

ersda

into table i_mara

from mara for all entries in i_mard

where matnr = i_mard-matnr.

if sy-subrc 0.

message e003.

endif.

*&--sorting the tables

sort: i_mard by matnr werks lgort,

i_mara by matnr,

i_maktx by matnr.

*&--Clearing workareas.

clear: wa_mard,

wa_mara,

wa_maktx,

wa_final.

*PROCESSING

loop at i_mard into wa_mard.

*moving values to final workarea

wa_final = wa_mard.

at new matnr.

read table i_maktx into wa_maktx

with key matnr = wa_mard-matnr binary search.

read table i_mara into wa_mara

with key matnr = wa_mard-matnr binary search.

endat.

if sy-subrc = 0.

"if succesful then move to final workarea

wa_final-maktx = wa_maktx-maktx.

*for mara values

wa_final-meins = wa_mara-meins.

wa_final-mtart = wa_mara-mtart.

wa_final-ersda = wa_mara-ersda.

endif.

*append final workarea

append wa_final to i_final.

endloop.

clearing and refreshing the table I_MARD

refresh: i_mard.

clear: wa_mard.

endif.

endform. "zf_populate_info

this will move all the data into final table you have got, with the performnce tuned way

TYPES OF INTERNAL TABLES

Internal tables

Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.

Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects. A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.

Internal Tables as Data Types

Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.

Line type

The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.

Key

The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.

If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.

The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.

Table type

The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:

Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled

very quickly, since the system does not have to check whether there are already existing entries.

Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are

known generically as index tables.

Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.

Generic Internal Tables

Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures. You cannot use them to declare data objects.

Internal Tables as Dynamic Data Objects

Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.

Choosing a Table Type

The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.

Standard tables

This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access,

standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.

Sorted tables

This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for

partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.

Hashed tables

This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.

Kindly Reward Points If You Found The Reply Helpful,

Cheers,

Chaitanya.

[Former Member]

create the 3 rd internal table with the structure which has fields of both internal tables.

and append them.

u hav to read the 3 rd table while appending second internal table.

[Former Member]

Hi,

You can achieve your requirement by using inner join .See th sample code below:

Inner joins using 3 tables

Try this :-

SELECT stpo_{stlnr stpo}idnrk mast_{matnr mara}mtart stpo~menge

INTO CORRESPONDING FIELDS OF TABLE zmat1 FROM mast

JOIN stpo ON stpo_{stlnr = mast}stlnr

JOIN mara ON mara_{matnr = mast}matnr

WHERE stpo_{stlty = 'M' "AND stpo}idnrk IN s_matnr

AND mast~werks = 1000.

Here s_matnr is a select-options on the selection-screen.

Or this.

Code:

Select single Vbrk_{Bukrs Vbrk}Kunrg Vbrk~Vbeln

Vbrk_{Fkdat Vbrk}Bstnk_Vf Vbrk~Zterm

Tvzbt~Vtext

Vbak_{Vbeln Vbak}Bstdk

Likp_{Vbeln Likp}lfdat Likp~Lfuhr

into w_vbrk

from vbrk

inner join Tvzbt on Tvzbt_{Zterm = Vbrk}Zterm and

Tvzbt~Spras = sy-langu

Inner join Vbfa as SalesLnk

on SalesLnk~vbeln = pu_vbeln and

SalesLnk~vbtyp_v = c_order

inner join Vbak on Vbak_{Vbeln = SalesLnk}Vbelv

Inner join Vbfa as DeliveryLnk

on DeliveryLnk~vbeln = pu_vbeln and

DeliveryLnk~vbtyp_v = c_Delivery

inner join Likp on Likp_{Vbeln = DeliveryLnk}Vbelv

where vbrk~vbeln = pu_Vbeln.

This code locates sales, delivery and payment terms info from a billing document number.

or

Here, this one also works fine :

select zfpcd_{cadivi zfpcd}proforma zfpcd_{factura zfpcd}aniofactura

zfpcd_{montousd zfpcd}montoap zfpcd_{ebeln zfpcd}inco1

zfpcd_{lifnr lfa1}name1 zcdvs_{status zfpcd}conint

into it_lista

from zfpcd inner join zcdvs

on zfpcd_{ebeln = zcdvs}ebeln

and zfpcd_{proforma = zcdvs}proforma

and zfpcd_{lifnr = zcdvs}lifnr

inner join lfa1

on zfpcd_{lifnr = lfa1}lifnr

where zcdvs~status = '04'.

Creating Internal Tables

You define internal tables first as an abstract data type in the program or ABAP Dictionary, and then as a data object based on that, or they are declared directly as a fully specified data object. When you create an internal table as a data object, you should ensure that only the administration entry which belongs to an internal table is declared statically. The size of table headers for initial tables is currently 8 bytes. This should be heeded whenever internal tables occur as components of complex data objects. Also, empty tables can use up a relatively high amount of storage space as components of tables. The size of the entire storage space required for an internal table is not defined in the declaration – as is the case for data objects of the type string or xstring. Table rows are added to and deleted from the table dynamically at runtime by the various statements for adding and deleting records.

Table Types

Internal Tables

Special Aspects of Standard Tables

Reward Points if found helpfull..

Cheers,

Chandra Sekhar.

[Former Member]

hi,

Standard tables

This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.

Sorted tables

This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.

Hashed tables

This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.

-

---

This section describes how to define internal tables locally in a program. You can also define internal tables globally as data types in the ABAP Dictionary.

Like all local data types in programs , you define internal tables using the TYPES statement. If you do not refer to an existing table type using the TYPE or LIKE addition, you can use the TYPES statement to construct a new local internal table in your program.

TYPES <t> TYPE|LIKE <tabkind> OF <linetype> [WITH <key>]

[INITIAL SIZE <n>].

After TYPE or LIKE, there is no reference to an existing data type. Instead, the type constructor occurs:

<tabkind> OF <linetype> [WITH <key>]

The type constructor defines the table type <tabkind>, the line type <linetype>, and the key <key> of the internal table <t>.

You can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.

Table type

TYPES VECTOR TYPE HASHED TABLE OF I WITH UNIQUE KEY TABLE LINE.

TYPES: BEGIN OF LINE,
COLUMN1 TYPE I,
COLUMN2 TYPE I,
COLUMN3 TYPE I,
END OF LINE.

TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.

TYPES: BEGIN OF DEEPLINE,
FIELD TYPE C,
TABLE1 TYPE VECTOR,
TABLE2 TYPE ITAB,
END OF DEEPLINE.

TYPES DEEPTABLE TYPE STANDARD TABLE OF DEEPLINE 
WITH DEFAULT KEY.

Internal tables are dynamic variable data objects. Like all variables, you declare them using the DATA statement. You can also declare static internal tables in procedures using the STATICS statement, and static internal tables in classes using the CLASS-DATA statement. This description is restricted to the DATA statement. However, it applies equally to the STATICS and CLASS-DATA statements.

Reference to Declared Internal Table Types

Like all other data objects, you can declare internal table objects using the LIKE or TYPE addition of the DATA statement.

DATA <itab> TYPE <type>|LIKE <obj> [WITH HEADER LINE].

Here, the LIKE addition refers to an existing table object in the same program. The TYPE addition can refer to an internal type in the program declared using the TYPES statement, or a table type in the ABAP Dictionary.

You must ensure that you only refer to tables that are fully typed. Referring to generic table types (ANY TABLE, INDEX TABLE) or not specifying the key fully is not allowed (for exceptions, refer to Special Features of Standard Tables).

The optional addition WITH HEADER line declares an extra data object with the same name and line type as the internal table. This data object is known as the header line of the internal table. You use it as a work area when working with the internal table (see Using the Header Line as a Work Area). When you use internal tables with header lines, you must remember that the header line and the body of the table have the same name. If you have an internal table with header line and you want to address the body of the table, you must indicate this by placing brackets after the table name (<itab>[]). Otherwise, ABAP interprets the name as the name of the header line and not of the body of the table. You can avoid this potential confusion by using internal tables without header lines. In particular, internal tables nested in structures or other internal tables must not have a header line, since this can lead to ambiguous expressions.

TYPES VECTOR TYPE SORTED TABLE OF I WITH UNIQUE KEY TABLE LINE.

DATA: ITAB TYPE VECTOR,
      JTAB LIKE ITAB WITH HEADER LINE.

* MOVE ITAB TO JTAB.   <-  Syntax error!

MOVE ITAB TO JTAB[].

Merging two internal tables.

if both the internal tables have same structure you can add

using

append lines of itab1 to itab3. " good performance

append lines of itab2 to itab3

Hope thishelps, DO reward.

Edited by: Runal Singh on Apr 3, 2008 4:55 PM

[Former Member]

select

b~vbeln

b~posnr

a~wadat

into table i_tab1

from likp as a

inner join lips as b

on a_{vbeln = b}vbeln

where a~vkorg in s_vkorg "selection screen

if not i_tab1[] is initial.

select gbstk

vbeln

into table i_tab2

from vbuk for all entries in i_tab1

where vbeln = i_tab1-vbeln.

endif.

if not i_tab2[] is initial.

select

vbeln

into table i_tab3

from vbak for all entries in i_tab2

where vbeln = i_tab2-vbeln.

endif.

Here the i_tab1 is a internal table joined with another table.

now i_tab2 is second table. and i_tab3 is third table and now i_tab1, i_tab2 data is with i_tab3.

Try this.

Regards

Swetha

[Former Member]

Hi all,

U can use this sample program for ur reference.

TABLES: ekko,

ekpo,

eket.

TYPES: BEGIN OF t_ekko,

ebeln LIKE ekko-ebeln, " Purchasing Document Number

bukrs LIKE ekko-bukrs, " Company Code

statu LIKE ekko-statu, " Status of purchasing document

aedat like ekko-aedat, "Date on which the record was created

END OF t_ekko.

DATA: lt_ekko TYPE STANDARD TABLE OF t_ekko.

DATA: wa_ekko TYPE t_ekko.

TYPES: BEGIN OF t_ekpo,

ebeln LIKE ekpo-ebeln, "Purchasing Document Number

menge LIKE ekpo-menge, "Purchase order quantity

werks LIKE ekpo-werks, "Plant

matnr like ekpo-matnr, "Material Number

END OF t_ekpo.

DATA: lt_ekpo TYPE STANDARD TABLE OF t_ekpo.

DATA: wa_ekpo TYPE t_ekpo.

TYPES: BEGIN OF t_eket,

ebeln like eket-ebeln,

ebelp LIKE eket-ebelp, "Item Number of Purchasing Document

menge LIKE eket-menge, "Scheduled quantity

etenr like eket-etenr,

END OF t_eket.

DATA: lt_eket TYPE STANDARD TABLE OF t_eket.

DATA: wa_eket TYPE t_eket.

types: begin of t_final,

ebeln LIKE ekko-ebeln, " Purchasing Document Number

bukrs LIKE ekko-bukrs, " Company Code

statu LIKE ekko-statu, " Status of purchasing document

aedat like ekko-aedat,

menge LIKE ekpo-menge, "Purchase order quantity

werks LIKE ekpo-werks, "Plant

matnr like ekpo-matnr, "Material Number

ebelp LIKE eket-ebelp,

etenr like eket-etenr,

end of t_final.

data: lt_final type standard table of t_final.

data: wa_final type t_final.

select-options: s_date for EKKO-aedat,

s_matnr for ekpo-MATNR,

s_etenr for eket-etenr.

select ebeln

bukrs

statu

aedat

from ekko into table lt_ekko where ebeln in s_date.

if not lt_ekko[] is initial.

select

ebeln

menge

werks

matnr

from ekpo into table lt_ekpo for all ENTRIES in lt_ekko where

ebeln = lt_ekko-ebeln.

endif.

if not lt_ekko[] is initial.

select

ebeln

ebelp

menge

etenr

from eket into table lt_eket for all entries in lt_ekko where

ebeln = lt_ekko-ebeln.

endif.

loop at lt_ekko into wa_ekko.

move:wa_ekko-BUKRS to wa_final-bukrs,

wa_ekko-STATU to wa_final-bukrs.

read table lt_ekko into wa_ekko with key ebeln = wa_ekko-ebeln.

move : wa_ekpo-menge to wa_final-menge, "Purchase order quantity

wa_ekpo-werks to wa_final-werks. "Plant

read table lt_ekpo into wa_ekpo with key ebeln = wa_ekko-ebeln.

move: wa_EKET-EBELP to wa_final-ebelp,

wa_eket-MENGE to wa_final-menge.

read table lt_eket into wa_eket with key ebeln = wa_ekko-ebeln.

append wa_final to lt_final.

endloop.

loop at lt_final into wa_final.

write:/ wa_final-BUKRS,wa_final-STATU,wa_final-menge, wa_final-werks,

wa_final-EBELP, wa_final-MENGE.

endloop.