creating internal tables....

Former Member · ‎2006 May 19

how to created a internal table itab..(with a sample code.)

to exibhit drill lists...

Former Member · ‎2006 May 19

Hi

What Are Internal Tables?

Internal tables are a way to store datasets of a fixed structure in the working memory of ABAP. The data is stored on a row-by-row basis, where each row has the same structure. The individual components of a row are also referred to as the columns of the internal table.

There are two kinds of internal tables in ABAP: data types and data objects. A data type returns the abstract description of an internal table and is used to create concrete data objects.

Data Types

Structures and internal tables represent the two structured data types available in ABAP (see ABAP Type Concept). The data type of an internal table is fully specified by:

Row type

The row type of an internal table can be any ABAP data type (that is, it can also be an internal table).

Key

The key is used to identify table rows. There are two possible keys for internal tables, the standard key and a user-defined key. The key can be defined as unique (UNIQUE) or non-unique (NON-UNIQUE). If a key is unique, no multiple entries exist in internal tables. The uniqueness depends on the table type (see below).

The standard key is made up of all non-numeric components of the associated row type that are no internal tables themselves or do not contain internal tables.

The user-defined key can be made up of any components that are no internal tables themselves or do not contain internal tables, that is, do not have a deeply structured type. Internal tables with a user-defined key are called key tables. When you define the key, you must pay attention to the order of the key fields, which is important, for example, for sorting the data based on the key.

Table type

The table type determines how ABAP accesses individual table rows. Based on the table type, internal tables can be subdivided into the following three categories:

In standard tables, a logical index is set up internally. The data can be accessed using the table index or the key. If the data is accessed using the key, the response time depends linearly on the number of table entries. The key of a standard table is always non-unique. When you define the table, you must not specify uniqueness for the key.

Sorted tables are always stored sorted by the key. Also for sorted tables, a logical index is set up internally. The data can be accessed using the table index or the key. If the data is accessed using the key, the response time depends logarithmically on the number of table entries since the data is accessed through a binary search. The key of sorted tables can be unique or non-unique. When you define the table, you must specify whether the key is UNIQUE or NON-UNIQUE.

Standard tables and sorted tables are also commonly referred to as index tables.

In hash tables, no logical index is set up internally. Hash tables can only be accessed by specifying the key. The response time in this case is constant irrespective of the number of table entries since the data is accessed through a hash algorithm. The key of hash tables must be unique. When you define the table, you must specify the key as UNIQUE.

Unlike other user-defined ABAP data types, the data type of an internal table does not need to be fully specified but can be set up generically. This means that if you create a data type for an internal table, you can either leave the key or the row type and the key unspecified.

Data Objects

Data objects created with the data type of an internal table or directly as an internal table are always specified fully with regard to row type, key, and table type. However, they can have any number of rows. Internal tables are consequently dynamical data objects that can contain any number of rows of a fixed type. The number of rows of an internal table is only restricted by the capacity limits of the actual system installation. The row types of internal tables are any ABAP data types and can therefore be elementary, structured, or internal tables themselves. The individual rows of an internal table are called table rows or table entries.

Using Internal Tables

Internal tables offer the functionality of dynamic arrays in ABAP and free the programmer from having to control dynamic memory management in the program. Internal tables are generally used if datasets of a fixed structure are processed internally in the program, for example, if contents of database tables are stored and edited internally in the program. Internal tables are also the most important means to implement highly complex data structures in an ABAP program.

Data Exchange with Internal Tables

There are two ways to handle internal tables. You can either address the entire internal table data object, also called the table body, or you can address individual table entries.

If you access the entire table body, you can use the table name like an elementary field in appropriate ABAP statements such as MOVE and execute the corresponding operation for the entire data object.

When accessing individual table entries, you do not directly operate on the data in the table but use another data object as the work area. The work area is used as an interface to the entries of the internal table and must be at least convertible into the row type of the internal table. Usually, however, you use work areas of the same data type as the rows of the internal table. When data is read from table rows, the contents of the work area are overwritten with the contents of the table row addressed. The contents of the work area can then be used in the program. When data is written into table rows, you must first enter the data into the work area. The system then transfers the data from the work area into the table row.

You can create internal tables with a socalled header line that has the same data type as a table row. The header line can be used as the table work area. This table work area and the internal table itself have the same name. ABAP statements for accessing individual table entries can implicitly use the header line as the work area. In ABAP statements that do not implicitly access the entire table body, you must distinguish the work area from the header line by adding angle brackets after the name (for example itab[]). The reason for this is that the system generally interprets the name in such statements as the name of the work area and not as the internal table. So that the table can be distinguished from the work area, you should create internal tables without header lines, if possible. In particular, internal tables must not have header lines if they are part of structures or other internal tables since this would result in ambiguous expressions.

Operations on Internal Tables

When individual table entries are accessed, the following table operations are common:

Filling using the ABAP statements:

INSERT

APPEND

COLLECT

Reading using the ABAP statements:

READ

LOOP

Modifying using the ABAP statement:

MODIFY

Deleting using the ABAP statement:

DELETE

Which ABAP statement you use, depends on the table type of the internal table. While you use the APPEND statement to fill a standard table, you use INSERT for filling hash tables. Besides these statements, there is a set of generic operations that can be applied to any kind of table. These generic operations are as follows:

INSERT ... INTO TABLE ...

MODIFY TABLE ...

READ TABLE ... [FROM ...|WITH TABLE KEY ...]

DELETE TABLE ... [FROM ...|WITH TABLE KEY ...]

These statements are valid for all table types and are executed by the system in a type-adequate manner for each table.

Selecting a Table Type

Which table type you choose for an individual table depends on how the above mentioned typical operations on individual table entries are applied to the table most frequently.

Standard tables:

Use this table type if the individual entries are addressed through an index. Index-based access is the quickest way to access table entries. You should fill standard tables by appending rows ( APPEND), and read, modify and delete them using an index (INDEX addition of the relevant ABAP statement). The response time for key-based access to standard tables increases linearly with the number of table entries. If key-based access is necessary, it makes particular sense to use standard tables if filling the table can be isolated from the other processing steps. For example, you can fill a standard table by appending rows and sort it afterwards. If you then use key-based access with the option for binary search (BINARY SEARCH addition), the response time depends only logarithmically on the number of the table entries.

Sorted tables

You use this table type if the table must be available in sorted form when it is set up. The table is then filled by inserting rows ( INSERT ... INTO TABLE) based on the sort order defined by the table key. The response time for key-based access depends logarithmically on the number of table entries, since a binary search is performed automatically. Sorted tables are also particularly useful for the partially sequential processing of a LOOP loop if the first parts of the table key are specified in the WHERE condition.

Hash tables

You use this table type if key-based access constitutes the central operation on table entries. Index-based access to hash tables is not possible. The response time for key-based access is always constant and does not depend on the number of table entries. As with database tables, the key of hash tables is always unique. Hash tables can therefore also be used to set up database-type internal tables and use them accordingly.

Declaring Internal Tables

Like any other ABAP data object, internal tables can first be created as a data type ( TYPES statement) and subsequently as a data object, or they can be directly declared as a fully specified data object ( DATAstatement). When you create an internal table as a data object, bear in mind that this only declares the administrative entry for an internal table as static. Unlike with all other ABAP data objects, the size of the memory space required is, however, not yet determined. The actual table rows are dynamically generated at runtime through operational fill statements and removed through delete statements.

When declaring an internal table, you can control the memory requirements of the table using the OCCURS and INITIALSIZE additions. This may affect the response times for filling the internal table (see the Performance Notes for Internal Tables).

Internal Tables as Parameters for Routines

Like any other parameter, internal tables can be passed by value or reference to subroutines and function modules.

If you want to pass a table together with its header line to a subroutine, you must pass it by reference using the TABLES addition. However, only STANDARDtables are allowed as TABLES parameters.

If a STANDARD table without a header line is passed as an actual parameter to a formal parameter with a header line (TABLES), the system automatically creates a header line in the routine. If you want to pass the body of a table with a header line as an actual parameter to a formal parameter without a header line, however, you can do this by using angle brackets after the name as described above.

TYPES - Defining an Internal Table Type

Variants:

1. TYPES itabtype

{TYPE tabkind OF linetype| LIKE

tabkind OF lineobj}

[WITH [UNIQUE|NON-UNIQUE] keydef]

[INITIAL SIZE n].

2. TYPES itabtype {TYPE RANGE OF type| TYPES itabtype LIKE RANGE

OF f}.

3. TYPES itabtype {TYPE linetype|LIKE lineobj} OCCURS n.

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See New naming convention and LIKE reference for ABAP Dictionary types not allowed.

Effect

Defines a user-defined type (ABAP type concept) for an internal table.

Variant 1

TYPES itabtype {TYPE tabkind OF linetype|

LIKE tabkind OF lineobj}

[WITH [UNIQUE|NON-UNIQUE] keydef] [INITIAL SIZE n].

Effect

Defines the type itabtype for an internal table without header line in a program with table type tabkind and line type linetype (if you use a TYPE reference) or the type of the referred object lineobj (if you use a LIKE reference). Internal tables without a header line consist of any number of table lines, each of which has the structure defined by the line type.

You may also define a table key. If you do not, the system creates a generic table type with any key. You can use generic types to specify the type of generic subroutine parameters.

The UNIQUE and NON-UNIQUE additions allow you to specify whether a table with type itabtype may contain two or more records with the same key or not. The following rules apply:

STANDARD TABLE:

The key is always NON-UNIQUE by default. You cannot use the UNIQUE addition with a standard table.

SORTED TABLE:

There is no default setting for sorted tables. If you do not specify UNIQUE or NON-UNIQUE, the system creates a generic table type without a particular uniqueness attribute. You can use generic types to specify the types of generic subroutine parameters.

HASHED TABLE:

There is no default setting for hashed tables. However, you must define a UNIQUE key. The NON-UNIQUE addition is not permitted.

The optional INITIAL SIZE addition allows you to specify how much memory should be allocated to the table when you create it. This corresponds to the OCCURS specification in variant 2 (see also Performance Notes for Internal Tables). The value n is not taken into consideration in the type check.

Example

The following type definitions define tables using the line type STRUC and the key NAME:

TYPES: BEGIN OF STRUC,

NAME(10) TYPE C,

AGE TYPE I,

END OF STRUC.

TYPES: TAB1 TYPE STANDARD TABLE OF STRUC WITH DEFAULT KEY,

TAB2 TYPE SORTED TABLE OF STRUC

WITH NON-UNIQUE KEY NAME,

TAB3 TYPE HASHED TABLE OF STRUC WITH UNIQUE KEY NAME.

Unlike the above types, the following types are generic. This means that you can use them to specify the type of a generic subroutine parameter, but not to create a table object uisng the DATA statement. The only exception to this is that the system allows you to use a generic standard table type in a DATA statement - the type description is completed automatically by the system according to the rules described under DATA.

TYPES: GEN_TAB1 TYPE STANDARD TABLE OF STRUC,

GEN_TAB2 TYPE SORTED TABLE OF STRUC WITH KEY NAME,

GEN_TAB3 TYPE HASHED TABLE OF STRUC.

The following example shows the definition of a sorted table using a LIKE reference to the ABAP Dictionary structure SFLIGHT:

TYPES: FLTAB LIKE SORTED TABLE OF SFLIGHT

WITH NON-UNIQUE KEY CARRID CONNID FLDATE.

Variant 2

TYPES itabtype {TYPE RANGE OF type| TYPES

itabtype LIKE RANGE OF f}.

Addition:

... INITIAL SIZE n

Effect

Creates a table type itab with table type STANDARD. The line type is a structure, made up as follows:

SIGN(1) TYPE C

OPTION(2) TYPE C

LOW TYPE type or LIKE f

HIGH TYPE type or LIKE f

The table has the same structure as a RANGES table and can be used in the same way. Tables defined using TYPE|LIKE RANGE OF have no headers, in contrast to tables defined using RANGES. You can declare a suitable work area by including a TYPE|LIKE LINE OF itab addition in a TYPES or DATA statement.

Addition

...INITIAL SIZE n

Effect

INITIAL SIZE specifies how many lines of the table are created along with the table. The table size increases dynamically as required - for further information, refer to Performance Notes for Internal Tables. The INITIAL SIZE value has no semantic meaning except in the APPEND SORTED BY statement. If you do not specify an INITIAL SIZE, the system uses 0 as the default value.

Variant 3

TYPES itabtype {TYPE linetype|LIKE lineobj} OCCURS n.

This variant is not allowed in an ABAP Objects context. See Declaration with OCCURS not allowed.

Effect

Defines the type itabtype as the type for a standard table without a header line. The key is the default key for internal tables.

This variant is the same as the following type definition:

TYPES itabtype {TYPE STANDARD TABLE OF linetype|

LIKE STANDARD TABLE OF lineobj}

WITH DEFAULT KEY INITIAL SIZE n.

Note

Type names

A type name can be up to 30 characters long. The name may only consist of alphanumeric characters and the underscore character. It may not consist entirely of digits. Special characters such as German umlauts are not allowed. As well as these characters, certain special characters are used internall. However, these should not be used in application programs. SPACE is a reserved name, and cannot therefore be used. Furthermore, you should not use a field in a statement if it has the same name as one of the additions of the keyword (for example: PERFORM SUB USING CHANGING.).

Recommendations for Type Names:

Always start the name with a letter.

Use the underscore to separate compound names (for example, NEW_PRODUCT.

Additional help

Internal Table Types

DATA - Defining an Internal Table

Variants:

1. DATA itab TYPE itabtype [WITH HEADER LINE].

2. DATA itab {TYPE tabkind OF linetype| LIKE

tabkind OF lineobj}

WITH [UNIQUE|NON-UNIQUE] keydef

[INITIAL SIZE n] [WITH HEADER LINE].

3. DATA itab {TYPE TABLE OF linetype|LIKE TABLE OF lineobj}.

4. DATA itab {TYPE RANGE OF type|DATA itab LIKE RANGE OF f}.

5. DATA itab [TYPE linetype|LIKE lineobj] OCCURS n [WITH HEADER LINE].

6. DATA: BEGIN OF itab OCCURS n, ...

END OF itab [VALID BETWEEN f1 AND f2].

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See New Naming Conventions und Cannot Use LIKE Reference to Dictionary Types.

Effect

Defines an internal table.

You fill and edit internal tables using the following statements: INSERT, APPEND, READ TABLE, LOOP, SORT.

The OCCURS and INITIAL SIZE additions (hereafter called the OCCURS value), determine the initial number of table lines created. The table is enlarged by the system when necessary. For more details about this, see performance notes for internal tables. The OCCURS value has no semantic meaning apart from an exception with APPEND SORTED BY. If you do not specify the INITIAL SIZE, the system sets the OCCURS value to 0 by default.

If you specify WITH HEADER LINE, the table is created with a header line - a field with the same name as the table. Its type is the same as the line type of the internal table.

This addition is not allowed in an ABAP Objects context. See Cannot Use Tables with a Header.

Variant 1

DATA itab TYPE itabtype [WITH HEADER LINE].

Effect

itabtype must be an internal table type, defined using TYPES. The system creates an internal table with the specified type.

The type declaration for the table object must be complete. The only exception to this rule is that, if you declare a generic type for a standard table (where only the key definition can be missing), the system completes it using the standard key.

Example

Creating a hashed table by referring to an existing table type.

TYPES: BEGIN OF STRUC, NAME(10), AGE TYPE I, END OF STRUC,

HTAB TYPE HASHED TABLE OF STRUC WITH UNIQUE KEY NAME.

DATA : PERSONS TYPE HTAB.

Variant 2

DATA itab {TYPE tabkind OF linetype|LIKE tabkind OF lineobj}

WITH [UNIQUE|NON-UNIQUE] keydef

[INITIAL SIZE n] [WITH HEADER LINE].

Effect

The system creates an internal table with table type tabkind. Since there is no generic field definition, you cannot use the table types ANY TABLE or SORTED TABLE.

The construction of the table lines is defined by linetype (if you are using a TYPE reference) or by the type of the referred object lineobj (if you are using a LIKE reference). If you specify the line type, you can also use REF TO to refer to a reference type.

The same rules apply to UNIQUE and NON-UNIQUE as apply to the TYPES definition. You may only omit this specification with standard tables.

If you do not specify an INITIAL SIZE, the system assumes a default value of INITIAL SIZE 0.

Variant 3

DATA itab {TYPE TABLE OF linetype|LIKE TABLE OF lineobj}.

Effect

This variant is a shortened form of the internal table definition. It corresponds to

DATA itab {TYPE STANDARD TABLE OF linetype|

LIKE STANDARD TABLE OF lineobj} WITH DEFAULT KEY.

or the old definition (see variant 4) with

DATA itab {TYPE linetype|LIKE lineobj} OCCURS 0.

Variant 4

DATA itab {TYPE RANGE OF type|DATA itab LIKE RANGE OF f}.

Extras:

1. ... INITIAL SIZE n

2. ... WITH HEADER LINE

Effect

Defines an internal table itab of the table type STANDARD. The line type is a structure made up of the following:

SIGN(1) TYPE C

OPTION(2) TYPE C

LOW TYPE type bzw. LIKE f

HIGH TYPE type bzw. LIKE f

Thus, the structure of the table corresponds to a RANGES table and can be used in the same way. Unlike tables that were created using the RANGES statement, a table defined using TYPE|LIKE RANGE OF has no header. You can declare an appropriate work area using the TYPE|LIKE LINE OF itab addition of the TYPES statement.

Addition 1

...INITIAL SIZE n

Effect

INITIAL SIZE specifies how many table lines are to be created initially. The number of table lines can then be increased as needed. For more information, see Performance: Notes for Internal Tables. The value of INITIAL SIZE has no semantic significance except in the case of APPEND SORTED BY. If INITIAL SIZE is not declared, its value is set to 0.

Addition 2

... WITH HEADER LINE

This addition is not allowed in an ABAP Objects context.

See Cannot Use Tables with a Header Line.

Effect

WITH HEADER LINE creates a header line with the table - that is, a field with the same name, whose type corresponds to the line type of the table.

Variant 5

DATA itab [TYPE linetype|LIKE lineobj] OCCURS n

[WITH HEADER LINE].

This variant is not allowed in an ABAP Objects context.

See Cannot Use OCCURS with Declarative Statements.

Effect

This variant exists for reasons of compatibility with Release 3.x. If this declaration is missing, the type C with a length of 1 is used. Otherwise the variant is synonymous with

DATA itab {TYPE STANDARD TABLE OF linetype|

LIKE STANDARD TABLE OF lineobj}

INITIAL SIZE n [WITH HEADER LINE].

Example

TYPES: BEGIN OF LINE_TYPE,

NAME(20) TYPE C,

AGE TYPE I,

END OF LINE_TYPE.

DATA: PERSONS TYPE LINE_TYPE OCCURS 20,

PERSONS_WA TYPE LINE_TYPE.

PERSONS_WA-NAME = 'Michael'. PERSONS_WA-AGE = 25.

APPEND PERSONS_WA TO PERSONS.

PERSONS_WA-NAME = 'Gabriela'. PERSONS_WA-AGE = 22.

APPEND PERSONS_WA TO PERSONS.

The internal table PERSONS now contains two entries:

Variant 6

DATA: BEGIN OF itab OCCURS n,

...

END OF itab [VALID BETWEEN f1 AND f2].

This variant is not allowed in an ABAP Objects context.

See Cannot Use OCCURS with Declarative Statements.

Effect

Defines an internal table itab with table type STANDARD and a header line. The line type consists of the fields between "BEGIN OF itab OCCURS n" and "END OF itab".

You can use the addition VALID BETWEEN f1 AND f2 to specify that subfields f1 and f2 of the internal table itab contain the validity range. This addition is only relevant in conjunction with the PROVIDE statement.

Example

DATA: BEGIN OF PERSONS OCCURS 20,

NAME(20),

AGE TYPE I,

END OF PERSONS.

PERSONS-NAME = 'Michael'.

PERSONS-AGE = 25.

APPEND PERSONS.

PERSONS-NAME = 'Gabriela'.

PERSONS-AGE = 22.

APPEND PERSONS.

The internal table now has two entries. It also has a header line (work area), which you use to work with the table itself.

Additional help

Internal Table Objects

Please close the thread if solved ; Mark Hellful answers

Regards

Message was edited by: Manoj Gupta

Former Member · ‎2006 May 19

Hi,

chk out the sample progs:

DEMO_LIST_AT_LINE_SELECTION

DEMO_LIST_AT_PF

DEMO_LIST_AT_USER_COMMAND

DEMO_LIST_INTERACTIVE_1

DEMO_LIST_INTERACTIVE_2

DEMO_LIST_INTERACTIVE_3

DEMO_LIST_INTERACTIVE_4

rgds,

latheesh

Former Member · ‎2006 May 19

REPORT ZTEST.

data: begin of itab occurs 0 ,

f1(10),

f2(20),

end of itab.

start-of-selection.

itab-f1 = 'Field1'.

itab-f2 = 'Description Field1'.

append itab.

itab-f1 = 'Field2'.

itab-f2 = 'Description Field2'.

append itab.

itab-f1 = 'Field3'.

itab-f2 = 'Description Field3'.

append itab.

end-of-selection.

loop at itab.

write:/ itab-f1, itab-f2.

hide: itab-f1, itab-f2.

endloop.

at line-selection.

write:/ 'This is secondary list', sy-lsind, 'writing', itab-f1.

Former Member · ‎2006 May 19

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[].

The table object ITAB is created with reference to the table type VECTOR. The table object JTAB has the same data type as ITAB. JTAB also has a header line. In the first MOVE statement, JTAB addresses the header line. Since this has the data type I, and the table type of ITAB cannot be converted into an elementary type, the MOVE statement causes a syntax error. The second MOVE statement is correct, since both operands are table objects.

Declaring New Internal Tables

You can use the DATA statement to construct new internal tables as well as using the LIKE or TYPE addition to refer to existing types or objects. The table type that you construct does not exist in its own right; instead, it is only an attribute of the table object. You can refer to it using the LIKE addition, but not using TYPE. The syntax for constructing a table object in the DATA statement is similar to that for defining a table type in the TYPES statement.

DATA <itab> TYPE|LIKE <tabkind> OF <linetype> WITH <key>

[INITIAL SIZE <n>]

[WITH HEADER LINE].

As when you define a table type , the type constructor

defines the table type <tabkind>, the line type <linekind>, and the key <key> of the internal table <itab>. Since the technical attributes of data objects are always fully specified, the table must be fully specified in the DATA statement. You cannot create generic table types (ANY TABLE, INDEX TABLE), only fully-typed tables (STANDARD TABLE, SORTED TABLE, HASHED TABLE). You must also specify the key and whether it is to be unique (for exceptions, refer to Special Features of Standard Tables).

As in the TYPES statement, you can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition. You can create an internal table with a header line using the WITH HEADER LINE addition. The header line is created under the same conditions as apply when you refer to an existing table type.

DATA ITAB TYPE HASHED TABLE OF SPFLI

WITH UNIQUE KEY CARRID CONNID.

The table object ITAB has the type hashed table, a line type corresponding to the flat structure SPFLI from the ABAP Dictionary, and a unique key with the key fields CARRID and CONNID. The internal table ITAB can be regarded as an internal template for the database table SPFLI. It is therefore particularly suitable for working with data from this database table as long as you only access it using the key.

other way

Special Features of Standard Tables

Unlike sorted tables, hashed tables, and key access to internal tables, which were only introduced in Release 4.0, standard tables already existed several releases previously. Defining a line type, table type, and tables without a header line have only been possible since Release 3.0. For this reason, there are certain features of standard tables that still exist for compatibility reasons.

Standard Tables Before Release 3.0

Before Release 3.0, internal tables all had header lines and a flat-structured line type. There were no independent table types. You could only create a table object using the OCCURS addition in the DATA statement, followed by a declaration of a flat structure:

DATA: BEGIN OF <itab> OCCURS <n>,

...

<fi> ...,

...

END OF <itab>.

This statement declared an internal table <itab> with the line type defined following the OCCURS addition. Furthermore, all internal tables had header lines.

The number <n> in the OCCURS addition had the same meaning as in the INITIAL SIZE addition from Release 4.0. Entering ‘0’ had the same effect as omitting the INITIAL SIZE addition. In this case, the initial size of the table is determined by the system.

The above statement is still possible in Release 4.0, and has roughly the same function as the following statements:

TYPES: BEGIN OF <itab>,

...

<fi> ...,

...

END OF <itab>.

DATA <itab> TYPE STANDARD TABLE OF <itab>

WITH NON-UNIQUE DEFAULT KEY

INITIAL SIZE <n>

WITH HEADER LINE.

In the original statement, no independent data type <itab> is created. Instead, the line type only exists as an attribute of the data object <itab>.

Standard Tables From Release 3.0

Since Release 3.0, it has been possible to create table types using

TYPES <t> TYPE|LIKE <linetype> OCCURS <n>.

and table objects using

DATA <itab> TYPE|LIKE <linetype> OCCURS <n> [WITH HEADER LINE].

The effect of the OCCURS addition is to construct a standard table with the data type <linetype>. The line type can be any data type. The number <n> in the OCCURS addition has the same meaning as before Release 3.0. Before Release 4.0, the key of an internal table was always the default key, that is, all non-numeric fields that were not themselves internal tables.

The above statements are still possible in Release 4.0, and have the same function as the following statements:

TYPES|DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>

WITH NON-UNIQUE DEFAULT KEY

INITIAL SIZE <n>

[WITH HEADER LINE].

They can also be replaced by the following statements:

Standard Tables From Release 4.0

When you create a standard table, you can use the following forms of the TYPES and DATA statements. The addition INITIAL SIZE is also possible in all of the statements. The addition WITH HEADER LINE is possible in the DATA statement.

Standard Table Types

Generic Standard Table Type:

TYPES <itab> TYPE|LIKE [STANDARD] TABLE OF <linetype>.

The table key is not defined.

Fully-Specified Standard Table Type:

TYPES <itab> TYPE|LIKE [STANDARD] TABLE OF <linetype>

WITH [NON-UNIQUE] <key>.

The key of a fully-specified standard table is always non-unique.

Standard Table Objects

Short Forms of the DATA Statement

DATA <itab> TYPE|LIKE [STANDARD] TABLE OF <linetype>.

DATA <itab> TYPE|LIKE [STANDARD] TABLE OF <linetype>

WITH DEFAULT KEY.

Both of these DATA statements are automatically completed by the system as follows:

DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>

WITH NON-UNIQUE DEFAULT KEY.

The purpose of the shortened forms of the DATA statement is to keep the declaration of standard tables, which are compatible with internal tables from previous releases, as simple as possible. When you declare a standard table with reference to the above type, the system automatically adopts the default key as the table key.

Fully-Specified Standard Tables:

DATA <itab> TYPE|LIKE [STANDARD] TABLE OF <linetype>

WITH [NON-UNIQUE] <key>.

The key of a standard table is always non-unique.

regards

srikanth

Former Member · ‎2006 May 19

Def 1.

data : begin of itab occurs 0,

f1 type mara-matnr,

*--and so on..

end of itab.

this defines an internal table ITAB with header line.

if you omit "OCCURS 0" in the above definition, it creates a work area/structure to hold 1 record.

Def 2.

data : itab type table of mara with header line.

this definition creates internal table ITAB with the structure of MARA & without header line.

regards

srikanth.

Former Member · ‎2006 May 19

Hai Swaminathan

REPORT ZWRITEDOC LINE-SIZE 124 NO STANDARD PAGE HEADING.

TABLES: DD03L, "

DD04T, "R/3-DD: Textos de los elementos de datos

DD02T. "R/3-DD: Textos de tablas SAP

Tabla temporal con las lineas de cada tabla

DATA: BEGIN OF I_LINEAS OCCURS 100,

LINEA(80),

END OF I_LINEAS.

Tabla con las caracteristicas de la tabla

DATA: BEGIN OF I_TABLA OCCURS 100,

CAMPO(12),

TIPO(4),

LONG(5) TYPE I,

REF(20),

DESCR(40),

END OF I_TABLA.

DATA: D_NOMBRE(80),

D_DESCRIPCION(80).

DATA : BEGIN OF SOURCE OCCURS 1000,

LINE(72),

END OF SOURCE.

PARAMETERS: PROGRAM LIKE SY-REPID DEFAULT SY-REPID.

AT USER-COMMAND.

CASE SY-UCOMM.

WHEN 'GRAB'.

PERFORM GRABAR.

ENDCASE.

START-OF-SELECTION.

SET PF-STATUS 'ZSTATUS1'.

READ REPORT PROGRAM INTO SOURCE.

DATA L_GRAB.

CLEAR L_GRAB.

LOOP AT SOURCE.

translate source to upper case.

IF L_GRAB IS INITIAL.

D_DESCRIPCION = I_LINEAS-LINEA.

ENDIF.

I_LINEAS = SOURCE.

SEARCH I_LINEAS-LINEA FOR 'BEGIN OF'.

IF SY-SUBRC = 0.

SEARCH I_LINEAS-LINEA FOR 'DATA'.

IF SY-SUBRC = 0.

L_GRAB = 'X'.

FREE I_LINEAS.

ENDIF.

IF L_GRAB = 'X'.

I_LINEAS = SOURCE.

APPEND I_LINEAS.

SEARCH I_LINEAS-LINEA FOR 'END OF'.

IF SY-SUBRC = 0.

CLEAR L_GRAB.

PERFORM PROCESAR_FICHERO.

PERFORM IMPRIMIR.

FREE I_LINEAS.

CLEAR D_DESCRIPCION.

ENDIF.

SEARCH I_LINEAS-LINEA FOR 'WITH HEADER LINE'.

IF SY-SUBRC = 0.

APPEND I_LINEAS.

PERFORM PROCESAR_FICHERO.

PERFORM IMPRIMIR.

ENDIF.

ENDLOOP.

&----

*& Form GRABAR

&----

Graba el fichero en c:\temp\p.rtf y lo abre con word.

----

FORM GRABAR.

CALL FUNCTION 'LIST_DOWNLOAD'

EXPORTING

LIST_INDEX = SLIST_INDEX_DEFAULT

METHOD = 'RTF'

EXCEPTIONS

OTHERS = 1.

CALL FUNCTION 'EXECUTE_WINWORD'

EXPORTING

I_FILE = 'C:\TEMP\P.RTF'

EXCEPTIONS

OTHERS = 1.

ENDFORM. " GRABAR

&----

*& Form PROCESAR_FICHERO

&----

FORM PROCESAR_FICHERO.

DATA: L_AUX1(80),

L_AUX2(80).

FREE I_TABLA.

LOOP AT I_LINEAS.

CLEAR I_TABLA.

translate i_lineas-linea to upper case.

SEARCH I_LINEAS-LINEA FOR 'BEGIN OF'.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT 'BEGIN OF' INTO L_AUX1 D_NOMBRE.

SPLIT D_NOMBRE AT 'OCCURS' INTO D_NOMBRE L_AUX1.

ENDIF.

SEARCH I_LINEAS-LINEA FOR '('.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT '(' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

I_TABLA-CAMPO = L_AUX1.

SPLIT L_AUX2 AT ')' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

IF L_AUX1 CO '0123456789 '.

I_TABLA-LONG = L_AUX1.

ENDIF.

I_TABLA-TIPO = 'CHAR'.

ENDIF.

SEARCH I_LINEAS-LINEA FOR 'LIKE'.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT 'LIKE' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

I_TABLA-CAMPO = L_AUX1.

SPLIT L_AUX2 AT ',' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

I_TABLA-REF = L_AUX1.

ENDIF.

SEARCH I_LINEAS-LINEA FOR 'TYPE'.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT 'TYPE' INTO L_AUX1 L_AUX2.

IF I_TABLA-CAMPO IS INITIAL.

CONDENSE L_AUX1.

I_TABLA-CAMPO = L_AUX1.

ENDIF.

SPLIT L_AUX2 AT ',' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

CASE L_AUX1.

WHEN 'I'.

I_TABLA-TIPO = 'INT'.

I_TABLA-LONG = 4.

WHEN 'C'.

I_TABLA-TIPO = 'CHAR'.

WHEN 'N'.

I_TABLA-TIPO = 'NUMC'.

WHEN 'T'.

I_TABLA-TIPO = 'TIME'.

I_TABLA-LONG = 8.

WHEN OTHERS.

I_TABLA-TIPO = L_AUX1.

ENDCASE.

ENDIF.

SEARCH I_LINEAS-LINEA FOR '"'.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT '"' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX2.

I_TABLA-DESCR = L_AUX2.

ENDIF.

SEARCH I_LINEAS-LINEA FOR 'INCLUDE STRUCTURE'.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT 'INCLUDE STRUCTURE' INTO L_AUX1 L_AUX2.

SPLIT L_AUX2 AT '.' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

I_TABLA-CAMPO = 'INCLUDE STR'.

I_TABLA-REF = L_AUX1.

ENDIF.

SEARCH I_LINEAS-LINEA FOR 'WITH HEADER LINE'.

IF SY-SUBRC = 0.

IF NOT I_LINEAS-LINEA CA '"'.

SPLIT I_LINEAS-LINEA AT 'OCCURS' INTO L_AUX1 L_AUX2.

IF SY-SUBRC = 0.

SPLIT L_AUX1 AT 'LIKE' INTO L_AUX1 L_AUX2.

IF SY-SUBRC = 0.

CONDENSE L_AUX2.

IF NOT L_AUX2 IS INITIAL.

I_TABLA-CAMPO = '...'.

I_TABLA-TIPO = 'TABI'.

I_TABLA-REF = L_AUX2.

SELECT SINGLE * FROM DD02T

WHERE TABNAME = L_AUX2

AND DDLANGUAGE = SY-LANGU.

IF SY-SUBRC = 0.

I_TABLA-TIPO = 'TABE'.

I_TABLA-DESCR = DD02T-DDTEXT.

ENDIF.

IF L_AUX1 CA ':'.

SPLIT L_AUX1 AT 'DATA:' INTO L_AUX1 L_AUX2.

ELSE.

SPLIT L_AUX1 AT 'DATA' INTO L_AUX1 L_AUX2.

ENDIF.

D_NOMBRE = L_AUX2.

ENDIF.

IF NOT I_TABLA-CAMPO IS INITIAL.

APPEND I_TABLA.

ENDIF.

ENDLOOP.

LOOP AT I_TABLA WHERE NOT REF IS INITIAL.

SPLIT I_TABLA-REF AT '-' INTO L_AUX1 L_AUX2.

SELECT SINGLE * FROM DD03L

WHERE TABNAME = L_AUX1

AND FIELDNAME = L_AUX2.

IF SY-SUBRC = 0.

I_TABLA-TIPO = DD03L-DATATYPE.

I_TABLA-LONG = DD03L-INTLEN.

IF I_TABLA-DESCR IS INITIAL.

SELECT SINGLE * FROM DD04T

WHERE ROLLNAME = DD03L-ROLLNAME

AND DDLANGUAGE = SY-LANGU.

IF SY-SUBRC = 0.

I_TABLA-DESCR = DD04T-DDTEXT.

ENDIF.

MODIFY I_TABLA.

ENDIF.

ENDLOOP.

ENDFORM. " PROCESAR_FICHERO

&----

*& Form IMPRIMIR

&----

FORM IMPRIMIR.

DATA L_AUX(80).

FORMAT COLOR COL_NORMAL INTENSIFIED ON.

ULINE AT 1(80).

WRITE: / SY-VLINE,

(76) D_NOMBRE CENTERED,

SY-VLINE.

SPLIT D_DESCRIPCION AT '*' INTO L_AUX D_DESCRIPCION.

WRITE: / SY-VLINE,

(76) D_DESCRIPCION CENTERED,

SY-VLINE.

NEW-LINE.

ULINE AT 1(80).

DETAIL.

FORMAT COLOR OFF.

WRITE: /

SY-VLINE,

(10) 'CAMPO',

SY-VLINE,

(4) 'TIPO',

SY-VLINE,

(4) 'LONG',

SY-VLINE,

(16) 'REFERENCIA',

SY-VLINE,

(30) 'DESCRIPCION',

SY-VLINE.

NEW-LINE.

ULINE AT 1(80).

DETAIL.

LOOP AT I_TABLA.

WRITE: /

SY-VLINE,

(10) I_TABLA-CAMPO,

SY-VLINE,

I_TABLA-TIPO,

SY-VLINE,

(4) I_TABLA-LONG,

SY-VLINE,

(16) I_TABLA-REF,

SY-VLINE,

(30) I_TABLA-DESCR,

SY-VLINE.

ENDLOOP.

NEW-LINE.

ULINE AT 1(80).

SKIP 2.

ENDFORM. " IMPRIMIR

Thanks & Regards

Sreenivasulu P

athavanraja · ‎2006 May 20

Come on Guys,

Dont copy/paste ABAP key word documentation here.

Regards

Raja

Former Member · ‎2006 May 22

Hai Swaminathan

REPORT ZWRITEDOC LINE-SIZE 124 NO STANDARD PAGE HEADING.

TABLES: DD03L, "

DD04T, "R/3-DD: Textos de los elementos de datos

DD02T. "R/3-DD: Textos de tablas SAP

Tabla temporal con las lineas de cada tabla

DATA: BEGIN OF I_LINEAS OCCURS 100,

LINEA(80),

END OF I_LINEAS.

Tabla con las caracteristicas de la tabla

DATA: BEGIN OF I_TABLA OCCURS 100,

CAMPO(12),

TIPO(4),

LONG(5) TYPE I,

REF(20),

DESCR(40),

END OF I_TABLA.

DATA: D_NOMBRE(80),

D_DESCRIPCION(80).

DATA : BEGIN OF SOURCE OCCURS 1000,

LINE(72),

END OF SOURCE.

PARAMETERS: PROGRAM LIKE SY-REPID DEFAULT SY-REPID.

AT USER-COMMAND.

CASE SY-UCOMM.

WHEN 'GRAB'.

PERFORM GRABAR.

ENDCASE.

START-OF-SELECTION.

SET PF-STATUS 'ZSTATUS1'.

READ REPORT PROGRAM INTO SOURCE.

DATA L_GRAB.

CLEAR L_GRAB.

LOOP AT SOURCE.

translate source to upper case.

IF L_GRAB IS INITIAL.

D_DESCRIPCION = I_LINEAS-LINEA.

ENDIF.

I_LINEAS = SOURCE.

SEARCH I_LINEAS-LINEA FOR 'BEGIN OF'.

IF SY-SUBRC = 0.

SEARCH I_LINEAS-LINEA FOR 'DATA'.

IF SY-SUBRC = 0.

L_GRAB = 'X'.

FREE I_LINEAS.

ENDIF.

IF L_GRAB = 'X'.

I_LINEAS = SOURCE.

APPEND I_LINEAS.

SEARCH I_LINEAS-LINEA FOR 'END OF'.

IF SY-SUBRC = 0.

CLEAR L_GRAB.

PERFORM PROCESAR_FICHERO.

PERFORM IMPRIMIR.

FREE I_LINEAS.

CLEAR D_DESCRIPCION.

ENDIF.

SEARCH I_LINEAS-LINEA FOR 'WITH HEADER LINE'.

IF SY-SUBRC = 0.

APPEND I_LINEAS.

PERFORM PROCESAR_FICHERO.

PERFORM IMPRIMIR.

ENDIF.

ENDLOOP.

&----

*& Form GRABAR

&----

Graba el fichero en c:\temp\p.rtf y lo abre con word.

----

FORM GRABAR.

CALL FUNCTION 'LIST_DOWNLOAD'

EXPORTING

LIST_INDEX = SLIST_INDEX_DEFAULT

METHOD = 'RTF'

EXCEPTIONS

OTHERS = 1.

CALL FUNCTION 'EXECUTE_WINWORD'

EXPORTING

I_FILE = 'C:\TEMP\P.RTF'

EXCEPTIONS

OTHERS = 1.

ENDFORM. " GRABAR

&----

*& Form PROCESAR_FICHERO

&----

FORM PROCESAR_FICHERO.

DATA: L_AUX1(80),

L_AUX2(80).

FREE I_TABLA.

LOOP AT I_LINEAS.

CLEAR I_TABLA.

translate i_lineas-linea to upper case.

SEARCH I_LINEAS-LINEA FOR 'BEGIN OF'.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT 'BEGIN OF' INTO L_AUX1 D_NOMBRE.

SPLIT D_NOMBRE AT 'OCCURS' INTO D_NOMBRE L_AUX1.

ENDIF.

SEARCH I_LINEAS-LINEA FOR '('.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT '(' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

I_TABLA-CAMPO = L_AUX1.

SPLIT L_AUX2 AT ')' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

IF L_AUX1 CO '0123456789 '.

I_TABLA-LONG = L_AUX1.

ENDIF.

I_TABLA-TIPO = 'CHAR'.

ENDIF.

SEARCH I_LINEAS-LINEA FOR 'LIKE'.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT 'LIKE' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

I_TABLA-CAMPO = L_AUX1.

SPLIT L_AUX2 AT ',' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

I_TABLA-REF = L_AUX1.

ENDIF.

SEARCH I_LINEAS-LINEA FOR 'TYPE'.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT 'TYPE' INTO L_AUX1 L_AUX2.

IF I_TABLA-CAMPO IS INITIAL.

CONDENSE L_AUX1.

I_TABLA-CAMPO = L_AUX1.

ENDIF.

SPLIT L_AUX2 AT ',' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

CASE L_AUX1.

WHEN 'I'.

I_TABLA-TIPO = 'INT'.

I_TABLA-LONG = 4.

WHEN 'C'.

I_TABLA-TIPO = 'CHAR'.

WHEN 'N'.

I_TABLA-TIPO = 'NUMC'.

WHEN 'T'.

I_TABLA-TIPO = 'TIME'.

I_TABLA-LONG = 8.

WHEN OTHERS.

I_TABLA-TIPO = L_AUX1.

ENDCASE.

ENDIF.

SEARCH I_LINEAS-LINEA FOR '"'.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT '"' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX2.

I_TABLA-DESCR = L_AUX2.

ENDIF.

SEARCH I_LINEAS-LINEA FOR 'INCLUDE STRUCTURE'.

IF SY-SUBRC = 0.

SPLIT I_LINEAS-LINEA AT 'INCLUDE STRUCTURE' INTO L_AUX1 L_AUX2.

SPLIT L_AUX2 AT '.' INTO L_AUX1 L_AUX2.

CONDENSE L_AUX1.

I_TABLA-CAMPO = 'INCLUDE STR'.

I_TABLA-REF = L_AUX1.

ENDIF.

SEARCH I_LINEAS-LINEA FOR 'WITH HEADER LINE'.

IF SY-SUBRC = 0.

IF NOT I_LINEAS-LINEA CA '"'.

SPLIT I_LINEAS-LINEA AT 'OCCURS' INTO L_AUX1 L_AUX2.

IF SY-SUBRC = 0.

SPLIT L_AUX1 AT 'LIKE' INTO L_AUX1 L_AUX2.

IF SY-SUBRC = 0.

CONDENSE L_AUX2.

IF NOT L_AUX2 IS INITIAL.

I_TABLA-CAMPO = '...'.

I_TABLA-TIPO = 'TABI'.

I_TABLA-REF = L_AUX2.

SELECT SINGLE * FROM DD02T

WHERE TABNAME = L_AUX2

AND DDLANGUAGE = SY-LANGU.

IF SY-SUBRC = 0.

I_TABLA-TIPO = 'TABE'.

I_TABLA-DESCR = DD02T-DDTEXT.

ENDIF.

IF L_AUX1 CA ':'.

SPLIT L_AUX1 AT 'DATA:' INTO L_AUX1 L_AUX2.

ELSE.

SPLIT L_AUX1 AT 'DATA' INTO L_AUX1 L_AUX2.

ENDIF.

D_NOMBRE = L_AUX2.

ENDIF.

IF NOT I_TABLA-CAMPO IS INITIAL.

APPEND I_TABLA.

ENDIF.

ENDLOOP.

LOOP AT I_TABLA WHERE NOT REF IS INITIAL.

SPLIT I_TABLA-REF AT '-' INTO L_AUX1 L_AUX2.

SELECT SINGLE * FROM DD03L

WHERE TABNAME = L_AUX1

AND FIELDNAME = L_AUX2.

IF SY-SUBRC = 0.

I_TABLA-TIPO = DD03L-DATATYPE.

I_TABLA-LONG = DD03L-INTLEN.

IF I_TABLA-DESCR IS INITIAL.

SELECT SINGLE * FROM DD04T

WHERE ROLLNAME = DD03L-ROLLNAME

AND DDLANGUAGE = SY-LANGU.

IF SY-SUBRC = 0.

I_TABLA-DESCR = DD04T-DDTEXT.

ENDIF.

MODIFY I_TABLA.

ENDIF.

ENDLOOP.

ENDFORM. " PROCESAR_FICHERO

&----

*& Form IMPRIMIR

&----

FORM IMPRIMIR.

DATA L_AUX(80).

FORMAT COLOR COL_NORMAL INTENSIFIED ON.

ULINE AT 1(80).

WRITE: / SY-VLINE,

(76) D_NOMBRE CENTERED,

SY-VLINE.

SPLIT D_DESCRIPCION AT '*' INTO L_AUX D_DESCRIPCION.

WRITE: / SY-VLINE,

(76) D_DESCRIPCION CENTERED,

SY-VLINE.

NEW-LINE.

ULINE AT 1(80).

DETAIL.

FORMAT COLOR OFF.

WRITE: /

SY-VLINE,

(10) 'CAMPO',

SY-VLINE,

(4) 'TIPO',

SY-VLINE,

(4) 'LONG',

SY-VLINE,

(16) 'REFERENCIA',

SY-VLINE,

(30) 'DESCRIPCION',

SY-VLINE.

NEW-LINE.

ULINE AT 1(80).

DETAIL.

LOOP AT I_TABLA.

WRITE: /

SY-VLINE,

(10) I_TABLA-CAMPO,

SY-VLINE,

I_TABLA-TIPO,

SY-VLINE,

(4) I_TABLA-LONG,

SY-VLINE,

(16) I_TABLA-REF,

SY-VLINE,

(30) I_TABLA-DESCR,

SY-VLINE.

ENDLOOP.

NEW-LINE.

ULINE AT 1(80).

SKIP 2.

ENDFORM. " IMPRIMIR

go through the following Links

1) http://www.sapgenie.com/abap/code/chap1201.txt

2) http://www.sapgenie.com/abap/code/chap0407.txt

3) http://www.sapgenie.com/abap/code/chap0103.txt

4) http://www.sapgenie.com/abap/code/chap1203.txt

5) http://www.sapgenie.com/abap/code/chap1202.txt

6) http://www.sapgenie.com/abap/code/chap1112.txt

7) http://www.sapgenie.com/abap/code/chap1103.txt

Thanks & regards

Sreeni

By Category

Related Content

Activity Groups

Industry Groups

Influence and Feedback Groups

Interest Groups

Location Groups

Customer Only Groups

Forums

Related Resources

Products

Learning and Support

About

My Account

My Account

creating internal tables....