Internal Table Types (Standard, Sorted, Hashed)

Hi all,
I wonder about using internal table types. I always work with standard table type. I don't know when i have to use the standard, sorted or hashed itab type. Is there limits for line counts of types, like over 200.000 lines use hashed table type etc. ? I need performance improvements for itabs.
Thx,

the terminology of internal tables is unfortunately quite confusing:
internal tables use 'index' for the row number of the line in the table, if you know then you can access it directly. It is actually the sy-tabix variable which you have to know.
Things which are called index on the database are called keys, i.e. the sorted primary key of a SORTED table or the hashed primary key of a HASHED table (the technical realization is actually called index).
With the newest basis release (7.02 or 7.20) there are also secondary keys possible on internal tables, for all 3 types.
Siegfried

Similar Messages

Senarious for using different internal table types

please give scenarios for using different internal table types?

Refer to the following.
Internal table types
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
You can specify the table type <tabkind> as follows:
Generic table types
INDEX TABLE
For creating a generic table type with index access.
ANY TABLE
For creating a fully-generic table type.
Data types defined using generic types can currently only be used for field symbols and for interface parameters in procedures . The generic type INDEX TABLE includes standard tables and sorted tables. These are the two table types for which index access is allowed. You cannot pass hashed tables to field symbols or interface parameters defined in this way. The generic type ANY TABLE can represent any table. You can pass tables of all three types to field symbols and interface parameters defined in this way. However, these field symbols and parameters will then only allow operations that are possible for all tables, that is, index operations are not allowed.
Fully-Specified Table Types
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.
Line type
For the line type <linetype>, you can specify:
Any data type if you are using the TYPE addition. This can be a predefined ABAP type, a local type in the program, or a data type from the ABAP Dictionary. If you specify any of the generic elementary types C, N, P, or X, any attributes that you fail to specify (field length, number of decimal places) are automatically filled with the default values. You cannot specify any other generic types.
Any data object recognized within the program at that point if you are using the LIKE addition. The line type adopts the fully-specified data type of the data object to which you refer. Except for within classes, you can still use the LIKE addition to refer to database tables and structures in the ABAP Dictionary (for compatibility reasons).
All of the lines in the internal table have the fully-specified technical attributes of the specified data type.
Key
You can specify the key <key> of an internal table as follows:
[UNIQUE|NON-UNIQUE] KEY <col1> ... <col n>
In tables with a structured line type, all of the components <coli> belong to the key as long as they are not internal tables or references, and do not contain internal tables or references. Key fields can be nested structures. The substructures are expanded component by component when you access the table using the key. The system follows the sequence of the key fields.
[UNIQUE|NON-UNIQUE] KEY TABLE LINE
If a table has an elementary line type (C, D, F, I, N, P, T, X), you can define the entire line as the key. If you try this for a table whose line type is itself a table, a syntax error occurs. If a table has a structured line type, it is possible to specify the entire line as the key. However, you should remember that this is often not suitable.
[UNIQUE|NON-UNIQUE] DEFAULT KEY
This declares the fields of the default key as the key fields. If the table has a structured line type, the default key contains all non-numeric columns of the internal table that are not and do not contain references or internal tables. If the 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.
Specifying a key is optional. If you do not specify a key, the system defines a table type with an arbitrary key. You can only use this to define the types of field symbols and the interface parameters of procedures . For exceptions, refer to Special Features of Standard Tables.
The optional additions UNIQUE or NON-UNIQUE determine whether the key is to be unique or non-unique, that is, whether the table can accept duplicate entries. If you do not specify UNIQUE or NON-UNIQUE for the key, the table type is generic in this respect. As such, it can only be used for specifying types. When you specify the table type simultaneously, you must note the following restrictions:
You cannot use the UNIQUE addition for standard tables. The system always generates the NON-UNIQUE addition automatically.
You must always specify the UNIQUE option when you create a hashed table.
Initial Memory Requirement
You can specify the initial amount of main memory assigned to an internal table object when you define the data type using the following addition:
INITIAL SIZE <n>
This size does not belong to the data type of the internal table, and does not affect the type check. You can use the above addition to reserve memory space for <n> table lines when you declare the table object.
When this initial area is full, the system makes twice as much extra space available up to a limit of 8KB. Further memory areas of 12KB each are then allocated.
You can usually leave it to the system to work out the initial memory requirement. The first time you fill the table, little memory is used. The space occupied, depending on the line width, is 16 <= <n> <= 100.
It only makes sense to specify a concrete value of <n> if you can specify a precise number of table entries when you create the table and need to allocate exactly that amount of memory (exception: Appending table lines to ranked lists). This can be particularly important for deep-structured internal tables where the inner table only has a few entries (less than 5, for example).
To avoid excessive requests for memory, large values of <n> are treated as follows: The largest possible value of <n> is 8KB divided by the length of the line. If you specify a larger value of <n>, the system calculates a new value so that n times the line width is around 12KB.
Examples
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.
http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb35de358411d1829f0000e829fbfe/content.htm

How to pass data from dynamic internal table to standard internal table

hi experts,
below is the piece of code which i have used in my requirement but the data is not moved.
LOOP AT <tab> ASSIGNING <tab1>.
MOVE-CORRESPONDING <tab1> TO wa.
append wa TO gt_outtab.
ENDLOOP.
here
<tab> - dynamic internal table.
<tab1>-dynamic internal table work area.
gt_outtab - standard internal table.
wa- standard internal table work area.
i am not getting what additional thing i have to write.
pls help me in this regard.
thankx in advance.
soham.p.

Hello soham p ,
I am also using the same logic but in my program it is working fine so you declare the fieldsymols like this and try and also check the dynamic internal contain the data or not.
FIELD-SYMBOLS : <y_i_table> TYPE STANDARD TABLE,
 <y_wa_table> TYPE ANY.
LOOP AT <y_i_table> ASSIGNING <y_wa_table>.
 MOVE-CORRESPONDING <y_wa_table> TO y_wa_vfscaid.
 APPEND y_wa_vfscaid TO y_i_vfscaid.
 CLEAR y_wa_vfscaid.
ENDLOOP.

Getting dynamically the internal table type

Hello all,
is there a standard function to get the internal table type name.like if a internal table is based on sflight,by using the function i pass the internal table and get the type sflight.
regards
kaushik

for this we have the CL_ABAP_TYPEDESCR class, subclasses and all of their methods.
Coding should look something like this:
DATA: dref TYPE REF TO data.
FIELD-SYMBOLS: <table> TYPE STANDARD TABLE,
 <line> TYPE ANY.
DATA: lr_reference TYPE REF TO cl_abap_typedescr.
DATA: lr_tab TYPE REF TO cl_abap_tabledescr.
DATA: lr_data TYPE REF TO cl_abap_datadescr.
PARAMETERS: pa_tab TYPE tabname DEFAULT 'BUT000'.
CREATE DATA dref TYPE STANDARD TABLE OF (pa_tab).
ASSIGN dref->* TO <table>.
SELECT * FROM but000 INTO TABLE <table>
 UP TO 10 ROWS.
CALL METHOD cl_abap_typedescr=>describe_by_data
EXPORTING
 p_data = <table>
RECEIVING
 p_descr_ref = lr_reference.
lr_tab ?= lr_reference.
lr_data = lr_tab->get_table_line_type( ).
WRITE lr_data->absolute_name.
Edited by: Micky Oestreich on Jan 19, 2009 8:09 AM
Edited by: Micky Oestreich on Jan 19, 2009 8:44 AM

Exporting An message Internal table to Standard program Internal Table

Hi,
In T-code VOFM, We have Goods issue routine 113, Now in Custmizing 913 is Configured. we are Checking the status of each handling unit of the Delivery. So I am getting the status Incomeplete Message for Multipe HU's. hence AM storing into One internal Table and Now I want To Export That Internal Table to Standard Program Internal Table 'WAT'.
If I raise

Elaborate your questions Please.

Getting the internal table of standard program to my custom program

Hi All,
I have a requirement in which i have to get the data from internal table ALV_ITAB from program HKBRO20. As this is the standard program, i have copied this program into Z custom program and using export parameter i am getting the data from internal table ALV_ITAB to my custom program (Using submit of the Z of the standard program). Can any one pls tell me whether the process i am following is correct if not pls tell me how to get the internal table from standard program to our custom program.
the process i am following
submit ZHBRO20 and return. IMPORT ALV_ITAB FROM MEMORY ID 'ABC'.
copied HBRO20 to ZHBRO20.
Thanks,
Raju

Hi,
you could also try
FIELD-SYMBOLS: <fc> .
CONSTANTS: c_table(21) VALUE '(PROGRAM_NAME)INTERNAL_TABLENAME[]'.
ASSIIGN (c_table) TO <fc>.
Depends on the process, of course.
Cheers,
Stefan.

Internal table types

hi all,
whn we are going to use standard , sorted and harshed table...
wht are the examples for the same..
regards
suprith

Standard Internal Tables
Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.
This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to
the number of table entries.
Sorted Internal Tables
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship 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, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of
table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.
Hashed Internal Tables
Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.
This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.
Index Tables
Index table is only used to specify the type of generic parameters in a FORM or FUNCTION. That means that you can't create a table of type INDEX.
Internal tables are not DB tables. Standard and Sorted tables in combined are basically called as Index tables and there nothing else. Here is the hierarchy
                                 ANY TABLE
                                            |
                     |                                                    |
             Index Tables                                    Hashed Table
                     |
    |                                                     |
Standard Table                      Sorted Table

[internal tables] TYPES or DATA

Hi,
starting with ABAP and try to understand internal tables. The structure
of an internal table isn't quiet clear. They have a work area and a table body,
but why do I need a additionally type of line?
Is this content, my tutorial uses DATA to define the itab and TYPES to define
the workarea (type of line). I don't really understand the different between those
commands.
Does anyone got a good web blog to understand internal tables completly?
thx
chris

Hi,
The Statements TYPES and DATA
Each ABAP program define its own data types using the statement.
TYPES dtype TYPE type ...
and declare its own variables or instance attributes of classes using the statement
DATA var {TYPE type} ...
Within the program or a class, you can also define local data types and variables within procedures. Local variables in procedures obscure identically-named variables in the main program or class.
When creating data types and data objects, there are a number of naming convention that also apply for other local program definitions, such as procedures. These are described in detail in the keyword documentation.
The Additions TYPE and LIKE
The additions TYPE type and LIKE dobj are used in various ABAP statements. The additions can have various meanings, depending on the syntax and context.
·        Definition of local types in a program
·        Declaration of data objects
·        Dynamic creation of data objects
·        Specification of the type of formal parameters in subroutines
·        Specification of the type of formal parameters in methods
·        Specification of the type of field symbols
Constructing New Data Types
The TYPE addition allows you to construct new data types in the TYPES, DATA; CONSTANTS; and STATICSstatements. In the TYPES statement, these are local data types in the program. In the other statements, they are attributes of new data objects, meaning that the newly defined data types are not free-standing. Rather, they are linked to database objects.This means that you can refer to them using the LIKEaddition, but not using TYPE.
To construct new data types, the addition TYPE can be used with the following type constructors:
·        Construction of reference types
REF TO type|dobj
·        Construction of structured data types
BEGIN OF struc_type.
END OF struc_type.
·        Construction of table types
tabkind OF linetype
These data types only exist during the runtime of the ABAP program.
Referring to Known Data Types or Data Objects
Using the additions TYPE or LIKE in the TYPESstatement, local data types in a program can be referred to known data types or data objects. This is mainly the case with user-defined elementary data types. If you declare variables using the additions TYPE type or LIKE dobj with statement DATA, the data type of var is already fully defined before the declaration is made.
The known types or data that are referred to must be visible at the point where the data type or variable is declared.
A known data type can be any of the following:
·        A predefined ABAP type to which you refer using the TYPE addition
·        An existing local data type in the program to which you refer using the TYPE addition
·        The data type of a local data object in the program to which you refer using the LIKE addition
·        A data type in the ABAP Dictionary to which you refer using the TYPE addition. To ensure compatibility with earlier releases, it is still possible to use the LIKE addition to refer to database tables and flat structures in the ABAP Dictionary. However, you should use the TYPE addition in new programs.
The LIKE addition takes its technical attributes from a visible data object. As a rule, you can use LIKE to refer to any object that has been declared using DATA or a similar statement, and is visible in the current context. The data object only has to have been declared. It is irrelevant whether the data object already exists in memory when you make the LIKE reference.
·        In principle, the local data objects in the same program are visible. As with local data types, there is a difference between local data objects in procedures and global data objects. Data objects defined in a procedure obscure other objects with the same name that are declared in the global declarations of the program.
·        You can also refer to the data objects of other visible ABAP programs. These might be, for example, the visible attributes of global classes in class pools. If a global class cl_lobal has a public instance attribute or static attribute attr, you can refer to it as follows in any ABAP program:
DATA dref TYPE REF TO cl_global.
DATA: f1 LIKE cl_global=>attr,
       f2 LIKE dref->attr.
You can access the technical properties of an instance attribute using the class name and a reference variable without first having to create an object. The properties of the attributes of a class are not instance-specific and belong to the static properties of the class.
TYPES: BEGIN OF struct,
         number_1 TYPE i,
         number_2 TYPE p DECIMALS 2,
       END OF struct.
DATA: wa_struct TYPE struct,
       number    LIKE wa_struct-number_2,
       date      LIKE sy-datum,
       time      TYPE t,
       text      TYPE string,
       company   TYPE s_carr_id.
This example declares variables with reference to the internal type STRUCT in the program, a component of an existing data object wa_struct, the predefined data object SY-DATUM, the predefined ABAP type t and STRING, and the data element S_CARR_ID from the ABAP Dictionary.
Referring to Generic Data Types
If you refer to one of the generic predefined ABAP types of fixed length (c, n, p, x) in the TYPES or DATA statement, you must specify the undefined technical attributes.
TYPES|DATA var[(length)] TYPE type ...
TYPES|DATA var TYPE type ...
DATA: text1,
      text2 LENGTH 2,
      text3 TYPE c LENGTH 3,
      pack TYPE p DECIMALS 2 VALUE '1.225'.
This example creates three character variables with field lengths of one, two, and three bytes respectively, and a packed number variable with field length 8 bytes and two decimal places. If the attribute Fixed point arithmetic is set, the value of pack is 1.23.
This example shows how to declare elementary data objects with reference to predefined ABAP types.
PROGRAM demo_elementary_data_objects.
DATA text1 TYPE c LENGTH 20.
DATA text2 TYPE string.
DATA number TYPE i.
text1 = 'The number'.
number = 100.
text2 = 'is an integer.'.
WRITE: text1, number, text2.
This program produces the following output on the screen:
The number              100 is an integer.
In this example, the data objects text1, text2 and number are declared with the DATA statement. The technical attributes are determined by referring to the predefined ABAP types c, string, and I. Values from unnamed literals are assigned to the data objects. The contents of the named data objects are displayed on the list.
Specifying a Start Value
When you declare an elementary fixed-length variable, the DATAstatement automatically fills it with the type-specific initial value as listed in the table in the Predefined ABAP Types section.
However, you can also specify a starting value of a fixed-length elementary variable (also within a structure declaration) using the VALUE addition in the DATAstatement:
DATA var ... VALUE val|{IS INITIAL}.
Specifying start values:
DATA: counter TYPE p VALUE 1,
      date    TYPE d VALUE '19980601',
      flag    TYPE n VALUE IS INITIAL.
After this data declaration, the character string flag contains its type specific
Initial value 0.
Regarsd

One Example program required on All types of internal tables

Hi All
Good Morning and Good day to you. I know that there are three types of internal tables like standard, sorted and hashed. I would request you to please send me one small example program on each type, so that i can understand better about the usage of different types.
Hoping for positive reply.
Thanks in advance.
Regards
Nagaraju

hi,
data: begin of struct,
 v_id type i,
 v_name(10) type c,
 v_phn type i,
 end of struct.
 "STANDARD TABLE.
data itab like standard table of struct with default key .
 write 'standard table'.
 struct-v_id = 1.
 struct-v_name = 'subash'.
 struct-v_phn = 234567.
 "INSERT struct into ITAB.
 append struct to itab.
 struct-v_id = 3.
 struct-v_name = 'sanchana'.
 struct-v_phn = 2378499.
 INSERT struct into ITAB index 1.
 "append struct to itab.
 struct-v_id = 2.
 struct-v_name = 'sanchith'.
 struct-v_phn = 2455667.
 INSERT struct into ITAB index 2 .
 loop at itab into struct.
 write: / struct-v_id , struct-v_name,struct-v_phn.
 endloop.
 skip.
 uline.
 "sorted table.
data itab1 like sorted table of struct with non-unique key v_id.
 write 'sorted table'.
 struct-v_id = 3.
 struct-v_name = 'subash'.
 struct-v_phn = 234567.
 INSERT struct into TABLE ITAB1.
 "append struct to itab.
 struct-v_id = 2.
 struct-v_name = 'sanchana'.
 struct-v_phn = 2378499.
 INSERT struct into table ITAB1.
 "append struct to itab.
 struct-v_id = 1.
 struct-v_name = 'sanchith'.
 struct-v_phn = 2455667.
 INSERT struct into ITAB1 index 1.
 "append struct to itab.
 loop at itab1 into struct.
 write: / struct-v_id , struct-v_name, struct-v_phn.
 endloop.
 skip.
 uline.
 "hashed table
 data itab2 like hashed table of struct with unique key v_id.
 write 'hashed table'.
 struct-v_id = 1.
 struct-v_name = 'subash'.
 struct-v_phn = 234567.
 INSERT struct into TABLE ITAB2.
 struct-v_id = 3.
 struct-v_name = 'sanchana'.
 struct-v_phn = 2378499.
 INSERT struct into TABLE ITAB2.
 struct-v_id = 2.
 struct-v_name = 'sanchith'.
 struct-v_phn = 2455667.
 INSERT struct into TABLE ITAB2.
&--SORTED USING SORT STATEMENT--
 loop at itab2 into struct.
 write:'non-sorted table' , / struct-v_id , struct-v_name, struct-v_phn.
 endloop.
 sort itab2 by v_id.
SKIP.
 loop at itab2 into struct.
 write: 'sorted hash table', / struct-v_id , struct-v_name, struct-v_phn.
 endloop.
 SKIP.
 ULINE.
Reward Useful Points
Siva

Is there any other option for using internal table in badi

hi
i know we cannot use internal table in badi
but is der any other option
plz write in d codez too
with Regards
Rohan Shetty
Edited by: Rohan Shetty on May 6, 2008 2:14 PM

of course you can use internal table in BAdi, do like this.
data: itab type table of ....
data: wa type ...
Example:
data: itab type (standard, sorted, hashed) table of mara.
data: wa type mara.
Or create your own type within the badi.
types: begin of ty_xxx,
            fielda type c,
            fieldb type n,
            fieldc type d.
types: end   of ty_xxx
data: itab type table of ty_xxx.
data: wa type ty_xxx.
Edited by: Micky Oestreich on May 6, 2008 2:16 PM

Internal table and work area

Hi,
can anybody explain the concepts of Internal table and work area.Thanks in advance.

hai,
This may help u.
WORKAREA is a structure that can hold only one record at a time. It is a collection of fields. We use workarea as we cannot directly read from a table. In order to interact with a table we need workarea. When a Select Statement is executed on a table then the first record is read and put into the header of the table and from there put into the header or the workarea(of the same structure as that of the table)of the internal table and then transferred top the body of the internal table or directly displayed from the workarea.
Each row in a table is a record and each column is a field.
While adding or retrieving records to / from internal table we have to keep the record temporarily.
The area where this record is kept is called as work area for the internal table. The area must have the same structure as that of internal table. An internal table consists of a body and an optional header line.
Header line is a implicit work area for the internal table. It depends on how the internal table is declared that the itab will have the header line or not.
e.g.
data: begin of itab occurs 10,
ab type c,
cd type i,
end of itab. " this table will have the header line.
data: wa_itab like itab. " explicit work area for itab
data: itab1 like itab occurs 10. " table is without header line.
Internal tables are used for storing records which are obtained as a result when we use select statement on database. internal tables are run time entities and doesn't occupy any memory. they are dynamic.
internal tables are of types.
1. internal tables with header line. [header and body]
2. internal tables with out header line. [only body]
Workarea is the concept which is mainly useful when working with internal tables with out header line.
at any point of time we can access only one record through header of a internal table. every thing should be done [inserting,modifying, reading ] through header only.
ex: data: itab like standard table of mara with header line.
for internal tables with out header line we will create a work area [explicit header] as type of table for storing data into internal table.
ex: data: itab like mara,
wa like mara.
more about internal table types:
Standard table:
The key access to a standard table uses a sequential search. The time required for an access is linearly dependent on the number of entries in the internal table.
You should usually access a standard table with index operations.
Sorted table:
The table is always stored internally sorted by its key. Key access to a sorted table can therefore use a binary search. If the key is not unique, the entry with the lowest index is accessed. The time required for an access is logarithmically dependent on the number of entries in the internal table.
Index accesses to sorted tables are also allowed. You should usually access a sorted table using its key.
Hash table:
The table is internally managed with a hash procedure. All the entries must have a unique key. The time required for a key access is constant, that is it does not depend on the number of entries in the internal table.
You cannot access a hash table with an index. Accesses must use generic key operations (SORT, LOOP, etc.).
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.
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.
DATA ITAB TYPE HASHED TABLE OF SPFLI
WITH UNIQUE KEY CARRID CONNID.
with regards,
B.Sowjanya,
reward points if helpful.

Creation of Sorted and Standard and Hashed Internal Tables ..

Hi ..
Pls specify me.. how to create .. sorted ,Standard and Hashed Internal Tables...
pls give me the full code regarding ...this ..
Thnks

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.
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.
Internal table objects
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.
plz reward if useful

Differences between Standard , sorted and hashed internal tables

Can any body please tell me what are the main Differences between
1) Standard internal table
2) Hashed internal table
3) Sorted internal table
Please give me a clear idea about these Three.
Thanks
Prabhudutta

Hi,
Standard Internal Tables
Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.
This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to
the number of table entries.
Sorted Internal Tables
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship 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, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of
table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.
Hashed Internal Tables
Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.
This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.
Regards
Sudheer

Types of internal tables with regard to EFFICIENCY

Will any one tell me syntax to define each type of internal table (standard, sorted , hashed , database) . how to compare their efficincy ( access time which is more effficent) is there any documantation or programme of such type exist then please tell . i want to declare each type of above table and also to compare them w.r.t to efficeny thanks want urgent reply

Hi,
There are 3 types of Internal tables.
Standard Internal Tables:
Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.
This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to the number of table entries.
Sorted Internal Tables:
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship 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, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.
Hashed Internal Tables:
Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.
This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.
http://help.sap.com/saphelp_470/helpdata/EN/fc/eb35de358411d1829f0000e829fbfe/frameset.htm
Regards,
Kiran Sure

Hi I want to know the difference between the type of internal tables.

I know the types of internal table but i dont know the difference between them can any one explain me in simple sentence.

Hi,
Standard Internal Tables
Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.
This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to
the number of table entries.
Sorted Internal Tables
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship 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, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of
table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.
Hashed Internal Tables
Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.
This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.

Internal Table Types (Standard, Sorted, Hashed)

Similar Messages

Maybe you are looking for