How to create internal tables ?

[Former Member]

How to create internal tables in SAP ABAP.

[Former Member]

How to create internal tables in SAP ABAP.

[Former Member]

HI,

Method One:with out header line.

TYPES:begin of t_itab1,

name1(20) type c,

age(2) type n,

end of itab1.

data:I_itab1 type standard table of t_itab1,"""Internal table of type t_itab1.

wa_itab1 type t_itab1. ""work area.

Method two:with header line.

TYpes:begin of itab1 occurs 0.

name1(20) type c,

age(2) type n,

end of itab1.

Thanks,CSR

[Former Member]

HI,

Syntax

DATA itab { {TYPE tabkind OF [REF TO] type}

| {LIKE tabkind OF dobj} }

[WITH key] [INITIAL SIZE n]

[WITH HEADER LINE]

[VALUE IS INITIAL]

[READ-ONLY].

Addition:

... WITH HEADER LINE

Effect

This statement defines an internal table. The definition of the row type, table kind tabkind and initial memory size INITIAL SIZE exactly corresponds to the definition of table types in section TYPES - TABLE OF, except that you cannot use the generic types ANY TABLE and INDEX TABLE. Use DATA to generate a bound table type with these additions.

The syntax for defining the table key key is also the same as for defining table types. In contrast to the definition of table types, an internal table as a data object cannot have a generic table key. This results in a slightly different semantics when you omit the table key specification in the DATA statement or when you do not specify the uniqueness using UNIQUE or NON-UNIQUE:

If for standard tables you specify no key, the table key is automatically determined as a non-unique standard key. A key specified without explicit uniqueness is implicitly enhanced with the addition NON-UNIQUE KEY. You cannot specify addition UNIQUE KEY.

For sorted tables, you must specify the key fully; both additions UNIQUE KEY or NON-UNIQUE KEY are allowed.

For hashed tables, you must specify the key fully; only addition UNIQUE KEY is allowed.

When defining internal tables before release 6.40, you could not specify a start value with addition VALUE. As of release 6.40, you can specify IS INITIAL as a start value.

Notes

When creating an internal table as a data object, only the administration entry for an internal table is generated. The actual table rows are not inserted until runtime. Under Obsolete Declarations, obsolete declaration forms for standard tables and special tables are described.

Example

Declaration of an internal table. The row type corresponds to the structure of database table SPFLI. For the table key, two key fields are defined. The other statements show how to fill the table with rows from database table SPFLI and how to read a row.

DATA: spfli_tab TYPE HASHED TABLE OF spfli

WITH UNIQUE KEY carrid connid,

spfli_wa LIKE LINE OF spfli_tab.

SELECT *

FROM spfli

INTO TABLE spfli_tab

WHERE carrid = 'LH'.

READ TABLE spfli_tab

WITH TABLE KEY carrid = 'LH' connid = '0400'

INTO spfli_wa.

...

Addition

... WITH HEADER LINE

Effect

Apart from the internal table, this addition, which is not allowed in classes, declares another data object, the header line, which has exactly the same name as the internal table and has the row type of the internal table as the data type.

If at an operand position of an ABAP statement, you specify the name of internal table itab, it depends on the statement whether the table body or the header line are used. As a rule, all table-specific statements such as SORT or LOOP use the internal table, while all other statements use the header line. Exceptions are - among others - the statements IMPORT andEXPORT.

To address the table body instead of the header line in a statement, you can append [] to the name (or a field symbol or dereferenced data reference):

... itab[] ...

For internal tables without header line, the table body is always used. An internal table with a header line can not be a component of a structure or a row of another internal table.

Note

These statements for processing individual table rows have short forms that implicitly use the header line as work area. These short forms are allowed only outside of ABAP Objects.

************please reward points if the information is helpful to you*************

[Former Member]

STANDARD TABLE or TABLE

For creating standard tables.

SORTED TABLE

For creating sorted tables.

HASHED TABLE

For creating hashed tables.

Fully-specified table types determine how the system will access the entries in the table in key operations. It uses a linear search for standard tables, a binary search for sorted tables, and a search using a hash algorithm for hashed tables.

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.

The program defines a table type ITAB. It is a sorted table, with line type of the structure LINE and a unique key of the component COLUMN1.

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.

The program defines a table type VECTOR with type hashed table, the elementary line type I and a unique key of the entire table line. The second table type is the same as in the previous example. The structure DEEPLINE contains the internal table as a component. The table type DEEPTABLE has the line type DEEPLINE. Therefore, the elements of this internal table are themselves internal tables. The key is the default key - in this case the column FIELD. The key is non-unique, since the table is a standard table.

Standard table

We recommend using standard tables if you plan to access your data through

an index – that is, when the sequence of the records is important and when

sorting and uniqueness are not essential. Sorting and binary search are

also available when using a standard table, but you have to program these

functions by hand.

Managing rankings is a typical example application.

Moreover, you will often have to use this table type in order to ensure

compatibility.

Sorted table

When you choose to use a sorted table, it will normally be because you want

to define a unique key. If you decide you need to sort the table or access

it using a binary search, you can always program these functions by hand,

like with standard tables. While hashed tables also provide unique keys, new

records are always added to sorted tables in the appropriate sort sequence.

Moreover, the initial dataset is set up more quickly.

Overall, if a table contains relatively few entries but has to deal with many

changing accesses, a sorted table can deliver better performance than a

hashed table.

A typical area of use here is the preparation and execution of mass database

changes. The most efficient way of doing this is to create a local copy of the

dataset in the program, make the changes to the copy, and then write all of its

data back to the database table. When you are dealing with large amounts of

data, this method both saves runtime and reduces the load on the database

server. Since the internal table represents a database table in this case, you

should use a unique key to ensure the records are unique as well. Automatic

sorting can also bring further advantages.

Hashed table

The hash algorithm calculates the address of an entry directly, based on

the key. This means that, with larger tables, the access time is reduced

significantly compared to a binary search.

In a loop, however, a hashed table always has to be searched completely

(table scan). Because the records are usually distributed without any sorting,

a sorted table might deliver better performance after all if you loop over the

first part of the key, or it could even make sense to sort the hashed table.

Therefore, using this table type only makes sense when you have to store

large amounts of data locally for mostly read access. At the same time,

the key of the hashed table has to be designed to enable unique access with

the full key.

Accordingly, hashed tables are generally used for the following situations:

To buffer or compose large quantities of data from several different database

tables where Dictionary views or nested SELECT statements are not possible.

(Open SQL joins bypass the table buffer of the database interface anyway.)

[Former Member]

Hi,

You can look for the book "ABAP in 21 days".THe e-book is available free on internet.

Data :Begin of itab occurs 0,

fieldname TYPE <dtab>,

fieldname TYPE <dtab>,

End of itab.

The above mentioned syntax will create an internal table with header line.

There are many other ways to declare it.You can search in the forum for the link of the book mentioned above.

Thanks,

Mohit

[Former Member]

First create a table type containing all the fields required in your internal table.

TYPES:

begin of ty_itab,

xyz(2) type c,

abc(2) type n,

.....

.......

end of ty_itab.

Then with data statement create internal table of that type declared above.

<b>Data</b>: itab type standard table of ty_itab,

Also create a work area for the same type.

wa_itab1 type t_itab1. ""work area.

Or if you want internal table with header line use the method below

TYpes:begin of itab occurs 0.

xyz(2) type c,

abc(2) type n,

.....

.......

end of itab.

[Former Member]

check this link:

http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3660358411d1829f0000e829fbfe/content.htm

regards,

anju

[Former Member]

HI,

see this link

u can get good material on internal tables

http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/ABAP_tutorial.html

rgds,

bharat.

[Former Member]

hai

thanks for everyone supported me