Hashed table -- Operations on it.

Hi,
tell me any one way of inserting data in to hashed table,
and operations possible on the hashed table.

Hi Kranthi,
You can only access a hashed table using the generic key operations or other generic operations (SORT, LOOP, and so on). Explicit or implicit index operations (such as LOOP ... FROM to INSERT itab within a LOOP) are not allowed."
Hashed table is useful when your have to work with very big internal table and to read it with
"READ TABLE WITH KEY ..."
And,
http://If its possible to declare a standard table with same type as hashed table.
Move your data to a standard table with the same Type as your dynamic hashed table.
tb_stand] = tb_hash[.
And access the records of the standard table.
kindly reward if found helpful.
cheers,
Hema.

Similar Messages

Question about comparing an array of names to a hash table

I'm still learning Powershell but feel like I have the basics now. I have a new project I'm working on and want some input as the best way to do this:
The Problem:
Let's say you have a list of several hundred video game titles and the dollar value of each in a text or two column CSV file.
The example CSV file looks likes this:
Game, Price
Metroid, $15.00
The Legend of Zelda!, $12.00
Mike Tyson's Punch-Out!, $18.00
Super Mario Bros., $16.00
Kung Fu, $7.00
You have another list of just the video game titles, this most likely is just a text file with each title listed on its own line.
The example text file looks like this:
Kung Fu
Metroid
Mike Tysons Punch-Out
Legend of Zelda
What I think would happen in the Script:
Use import-csv and create a hash table that will contain a key = Title and the value = the price.
Use import-csv and create an array for the title names.
Foreach loop through each Game Title and match the value against the Hash Table, if there's a match found, put that into another array that will later add all prices of each item and give you a total sum.
The challenge:
So far when I try and do one line examples of comparing names against the hash table it seems to only work with exact name matches. In the above example I've purposely made the game titles slightly different because in the real world people just write things
differently.
With that said, I've tried using the following single line to match things up and it only seems to work if the values match exactly.
$hash_table.ContainsKey("Game Title")
Is there a regex I should use to change the input of the game titles before creating the hash table or doing the compare? Is there another matching operator that is better and matching with String values that have slightly different grammar. An example would
be the game "The Legend of Zelda". Sometimes people just put "Legend of Zelda", that's close but not exact. I think using a regex to remove extra spaces and symbols would work, but what about for matching of words or letters??
Any ideas would be very helpful and thanks!

There's no pat answer for this.
You can create an array from the hash table keys:
$hashtable = @{"The Legend of Zelda" = 15.00}
$titles = $hashtable.getenumerator() | select -ExpandProperty Name
And then test that using a wildcard match:
$titles -like "*Game Title*"
and see if it returns just one match. If it does then use that match to do your lookup in the hash table. If it returns 0, or more than one match then you need to check the spelling or qualify the title search some more.
[string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

Hash tables in combination with data references to the line type.

I'm having an issue with hash tables - in combination with reference variables.
Consider the following: (Which is part of a class) - it attempts to see if a particular id exists in a table; if not add it; if yes change it.
types: BEGIN OF TY_MEASUREMENT,
 perfid TYPE zgz_perf_metric_id,
 rtime TYPE zgz_perf_runtime,
 execount TYPE zgz_perf_execount,
 last_start TYPE timestampl,
 END OF TY_MEASUREMENT.
METHOD START.
DATA: ls_measurement TYPE REF TO ty_measurement.
READ TABLE gt_measurements WITH TABLE KEY perfid = i_perfid reference into ls_measurement.
if sy-subrc <> 0.
 "Didn't find it.
 create data ls_measurement.
 ls_measurement->perfid = i_perfid.
 insert ls_measurement->* into gt_measurements.
endif.
GET TIME STAMP FIELD ls_measurements-last_start.
ls_measurement->execount = ls_measurement->execount + 1.
ENDMETHOD.
I get compile errors on the insert statement - either "You cannot use explicit index operations on tables with types HASHED TABLE" or "ANY TABLE". It is possible that.
If I don't dereference the type then I get the error LS_MEASUREMENT cannot be converted to the line type of GT_MEASUREMENTS.
I'm not looking to solve this with a combination of references and work ares - want a reference solution.
Thanks!
_Ryan
Moderator message - Moved to the correct forum
Edited by: Rob Burbank on Apr 22, 2010 4:43 PM

I think it might work when you change it for
insert ls_measurement->* into TABLE gt_measurements.
For hashed table a new line here will be inserted according to given table key.
Regards
Marcin

How to fill a hashed table ?

Hi,
In my last thread i had asked about the ways of deleting the cube contents selectively using a job/FM and i was suggested this by one of you.
CALL FUNCTION 'RSDRD_SEL_DELETION'
EXPORTING
I_DATATARGET = 'YOUR_CUBE'
I_THX_SEL = L_THX_SEL
I_AUTHORITY_CHECK = 'X'
I_THRESHOLD = '1.0000E-01'
I_MODE = 'C'
I_NO_LOGGING = ''
I_PARALLEL_DEGREE = 1
I_NO_COMMIT = ''
CHANGING
C_T_MSG = L_T_MSG.
Although the FM is the correct one the structure L_THX_SEL is a hashed table structure and i am not aware how to fill values into it. My requirement is to give a condition for the 0CALDAY info-object i.e 0CALDAY < 30 days. Please suggest me.
Regadrs,
Pramod M

HI,
Internal Tables
Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.
Data Type of an Internal Table
The data type of an internal table is fully specified by its line type, key, and table type.
Line Type
The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.
Key
The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.
At tables with structured row type, the standard key is formed from all character-type columns of the internal table. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty. At tables with non-structured row type, the standard key consists of the entire row. If the row type is also a table, an empty key is defined.
The user-defined key can contain any columns of the internal table that are no internal table themselves, and do not contain internal tables. References are allowed as table keys. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.
Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be UNIQUE or NON-UNIQUE. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
Generic Internal Tables
Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data objects.
Internal Tables as Dynamic Data Objects
Internal tables are always completely specified regarding row type, key and access type. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.
Choosing a Table Type
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.
Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPENDstatement), 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 (BINARY) 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 INSERTstatement. 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 WHEREcondition.
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.
If help full please give me max Reward

Hash Table -Runtime error.

Hi,
i am defining internal table as hash table but it is giving runtime error like bolow. some times it is executing properly or giving dump.please give me some suggestions to come out of this problem.
Ex:
What happened?
    Error in the ABAP Application Program
    The current ABAP program "SAPLZGIT_MED" had to be terminated because it has
    come across a statement that unfortunately cannot be executed.
Error analysis
    An entry was to be entered into the table
     "\FUNCTION=ZBAPI_GIT_MED_HD_BOTELLAS_RPT\DATA=T_THERAPY_INFO" (which should
     have
    had a unique table key (UNIQUE KEY)).
    However, there already existed a line with an identical key.
    The insert-operation could have ocurred as a result of an INSERT- or
    MOVE command, or in conjunction with a SELECT ... INTO.
    The statement "INSERT INITIAL LINE ..." cannot be used to insert several
     initial lines into a table with a unique key.
Code: .....................................
TYPES: BEGIN OF X_THERAPY_INFO,
                GIT_THERAPY_ID     TYPE ZGIT_VBELN_GIT,
                CHO_THERAPY_ID     TYPE VBELN,
                SERVICE_ID         TYPE MATNR,
                SERVICE_DESC       TYPE ARKTX,
                FLOW               TYPE ZGIT_ZFLOW,
                DURATION           TYPE ZGIT_ZDURATION,
                GIT_PAT_ID         TYPE ZGIT_KUNNR_GIT,
                CHORUS_PAT_ID      TYPE KUNNR,
           END OF X_THERAPY_INFO,
DATA:
T_THERAPY_INFO           TYPE HASHED TABLE OF X_THERAPY_INFO WITH UNIQUE KEY        GIT_THERAPY_ID,                " Internal table for extracting the therapy Informamtion
Extract the Therapy Details
SELECT   VBELN_GIT
           VBELN
           MATNR
           ARKTX
           ZFLOW
           ZDURATION
           KUNNR_GIT
           KUNNR
INTO     TABLE     T_THERAPY_INFO
FROM     ZGIT_T_VBAK
WHERE    KUNNR_GIT   NE SPACE
AND      KVGR2       IN TR_KVGR2
AND      ZDOCTOR     IN TR_DOC_SEL_ID
AND      ZHOSPITAL   IN TR_HOSPITAL_ID
AND    ( ZSTATUS_ID NE C_HIDDEN
AND      ZSTATUS_ID NE C_DISABLED
AND      ZSTATUS_ID NE C_OTHERS )
AND      VBELN       IN TR_VBELN.
IF SY-SUBRC NE C_0.
Thanks in advance,
Srinivas P

When you are using hashed tables, you cannot have duplicate records (considering it's key). So DELETE ADJACENT DUPLICATES won't solve it. It will dump before that.
Find if you are inserting records with the same fields you inserted in the key.
Example.
If your key is VBELN, you cannot make it like this:
SELECT a~vbeln b~matnr
   INTO TABLE hashed_itab
FROM vbak AS a INNER JOIN vbap as b
   ON a~vbeln = b~vbeln
WHERE ...
It will dump if your vbeln has 2 lines in vbap.
Two solutions:
1 - expand the itab key to VBELN and POSNR (for example) or
2
SELECT DISTINCT a~vbeln b~matnr
   INTO TABLE hashed_itab
FROM vbak AS a INNER JOIN vbap as b
   ON a~vbeln = b~vbeln
WHERE ...
Regards,
Valter Oliveira.

Urgent: how to add additional records to hashed table

Hi,
I want to add records to a hashed table.
my code is:
data: ipn_pc_zoba type hashed table of tpn_pc_zoba with unique key vbeln.
loop at izoba into wzoba.
clear wpn_pc_zoba .
read table ipn_pc_zoba into wpn_pc_zoba with key vbeln = wzoba-LS_KDAUF.
if sy-subrc ne 0.
wpn_pc_zoba-vbeln = wzoba-LS_KDAUF.
append wpn_pc_zoba to ipn_pc_zoba.
endif.
endloop.
The Error is : You cannot use explicit or implicit index operations on tables with types "HASHED TABLE" or "ANY TABLE". "IPN_PC_ZOBA" has the type "HASHED TABLE". It is possible that .
How to solve this?
Please reply ASAP.
Regards,
SRI

In your code you should use
INSERT WPN_PC_ZOBA INTO IPN_PC_ZOBA.
This is the only way to append data to a hashed table. It will also only work as long as wpn_pc_zoba-vbeln is unique in the hashed table.
If you are getting an error, what does the error say?
Michael

Hash table and function module input

Hi ABAP Expert,
Please advise what happening if i am passing the intertal table (hashtable) become input of function module (table).
so insite the function module is this table still hashtable type or just normal internal table ?
Thank you and Regards
Fernand

Typing of such parameter should be either generic (i.e ANY TABLE) or fully specified (HASHED/SORTED/STANDARD TABLE). In both cases when you pass i.e. HASHED table to that formal parameter the dynamic type will be inherited by the actual paremeter.
This means that inside the function module you will not be able to use HASHED table "banned" statement i.e. not appending to this table. The system must be fully convinced about the type of passed parameter to allow certain access. Without that knowledge it won't pass you through the syntax checker or will trigger runtime error.
I.e
"1) parameter is typed
CHANGING
C_TAB type ANY TABLE
"here you can't use STANDARD/SORTED table specific statements as the dynamic type of param might be HASHED TABLE
append ... to c_tab. "error during runtime
"2) parameter is typed
CHANGING
C_TAB type HASHED TABLE
"here system explicitly knows that dynamic type is the same as static one so you can append to this table too
append ... to c_tab. "syntax error before runtime
So the anwser to your question
so insite the function module is this table still hashtable type or just normal internal table ?
is...
During syntax check system takes static type of table and shouts if table related operation is not allowed for this kind.
During runtime system takes dynamic type of the table and checks whether particular statement is allowed for this kind of table, if not triggers an exception.
Regards
Marcin

Problem FIELD-SYMBOL with HASHED TABLE

Hello gurus,
I have a problem with the following code. It is called in method MB_DOCUMENT_BEFORE_UPDATE of badi MB_DOCUMENT_BADI. I need to read the serial numbers of all items. I tried to do it with a field symbol. The information I need is stored in the hased table (SAPLMIGO)LCL_MIGO_GLOBALS=>KERNEL->PT_GOSERIAL_KERNEL. The systems returns sy-subrc = 4 after the assign. Can anyone help me? Thanks!
TYPES: BEGIN OF ty_s_goserial,
 selected TYPE xfeld,
 serialno TYPE gernr,
 END OF ty_s_goserial,
 ty_t_goserial TYPE STANDARD TABLE OF ty_s_goserial WITH
 NON-UNIQUE DEFAULT KEY.
TYPES: BEGIN OF ty_s_goserial_kernel,
 global_counter TYPE migo_global_counter,
 t_goserial TYPE ty_t_goserial,
 END OF ty_s_goserial_kernel.
types: tyt_goserial TYPE HASHED TABLE OF ty_s_goserial_kernel
 WITH UNIQUE KEY global_counter.
 fs_l_serialno = '(SAPLMIGO)LCL_MIGO_GLOBALS=>KERNEL->PT_GOSERIAL_KERNEL'.
 FIELD-SYMBOLS: <fs_serialno> type tyt_goserial.
 ASSIGN (fs_l_serialno) TO <fs_serialno>.
 IF sy-subrc = 4.
 WRITE: / 'Ouch...'.
 ENDIF.

Hi,
Try adding body operator..at the end as it is an internal table..
(SAPLMIGO)LCL_MIGO_GLOBALS=>KERNEL->PT_GOSERIAL_KERNEL[]'.
Thanks
Naren

Problem - Inserting Records into Hashed Tables

Help for an ABAP Newbie...
How do I insert records into a hashed table?
I am trying the following, but get the error message,
*You cannot use explicit or implicit index operations with types "HASHED TABLE" or "ANY TABLE". "LT_UNIQUE_NAME_KEYS" has the type "HASHED TABLE".
TYPES: BEGIN OF idline,
    id TYPE i,
    END OF idline.
DATA: lt_unique_name_keys TYPE HASHED TABLE OF idline WITH UNIQUE KEY id,
        ls_unique_name_key LIKE LINE OF lt_unique_name_keys.
" Create a record and attempt to insert it into the internal table.
" Why does this cause a compilation error message?
ls_unique_name_key-id = 1.
INSERT ls_unique_name_key INTO lt_unique_name_keys.
Thanks,
Walter

INSERT ls_unique_name_key INTO TABLE lt_unique_name_keys.

Isuue in adding additional records to hashed table

Hi,
I want to add records to a hashed table.
my code is:
data: ipn_pc_zoba type hashed table of tpn_pc_zoba with unique key vbeln,
wpn_pc_zoba like line of ipn_pc_zoba.
loop at izoba into wzoba.
clear wpn_pc_zoba .
read table ipn_pc_zoba into wpn_pc_zoba with key vbeln = wzoba-LS_KDAUF.
if sy-subrc ne 0.
wpn_pc_zoba-vbeln = wzoba-LS_KDAUF.
append wpn_pc_zoba to ipn_pc_zoba.
endif.
endloop.
The Error is : You cannot use explicit or implicit index operations on tables with types "HASHED TABLE" or "ANY TABLE". "IPN_PC_ZOBA" has the type "HASHED TABLE". It is possible that .
How to solve this?
Please reply ASAP.
Regards,
SRI

Hi,
use
insert wpn_pc_zoba into table ipn_pc_zoba.
to insert the new record into the hashed table.
Regards,
Thomas Langen

Cluster tables , pool tables ,hashed tables?

give me the examles of cluster and pool tables & hashed tables ?

I. Transparent tables (BKPF, VBAK, VBAP, KNA1, COEP)
Allows secondary indexes (SE11->Display Table->Indexes)
Can be buffered (SE11->Display Table->technical settings) Heavily updated tables should not be buffered.

II. Pool Tables (match codes, look up tables)
Should be accessed via primary key or
Should be buffered (SE11->Display Table->technical settings)
No secondary indexes
Select * is Ok because all columns retrieved anyway
III. Cluster Tables (BSEG,BSEC)
Should be accessed via primary key - very fast retrieval otherwise very slow
No secondary indexes
Select * is Ok because all columns retrieved anyway. Performing an operation on multiple rows is more efficient than single row operations. Therefore you still want to select into an internal table. If many rows are being selected into the internal table, you might still like to retrieve specific columns to cut down on the memory required.
Statistical SQL functions (SUM, AVG, MIN, MAX, etc) not supported
Can not be buffered
IV. Buffered Tables (includes both Transparent & Pool Tables)
While buffering database tables in program memory (SELECT into internal table) is generally a good idea for performance, it is not always necessary. Some tables are already buffered in memory. These are mostly configuration tables. If a table is already buffered, then a select statement against it is very fast. To determine if a table is buffered, choose the 'technical settings' soft button from the data dictionary display of a table (SE12). Pool tables should all be buffered.
regards,
srinivas
*reward for useful answers*

ABAP hash table

Hi Guys,
I have an internal table with employee name and its attributes, like address, family etc. Each employee can have multiple records in the table.
I want to create a table of tables with key as employee ID and rest of the employee attributes inside the table.
So each employee then will have one row in the main table and all its attributes will be in the inner table.
Can someone please share a sample code to achieve this?
Regards,
~Mark

Hi,
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.
Example:
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.
Regards,
Bhaskar

Comparing String values against a collection of Names in a Hash Table

Objective:
Is to make a script that will import a csv file containing two values: "Name" and "Price". This would ideally be stored in a hash table with the key name of "Name" and the value being "Price". The second part would be
importing a second csv file that has a list of names to compare too. If it finds a similar match to a key name in the hash table and then it will add that to a new array with the price. At the end it would add all the prices and give you a total value.
The Problem to Solve:
In the real world people have a tendency to not write names exactly the same way, for example I am looking at a list of books to buy in an eBay auction. In the auction they provide a text list of all the names of books for sale. In my price guide it has all
the names and dollar values of each book. The wording of the way each book is named could differ from the person who writes it and what is actually in my reference pricing list. An example might be "The Black Sheep" vs "Black Sheep" or
"Moby-Dick" vs "Moby Dick".
I've tried making a script and comparing these values using the -like operator and have only had about 70% accuracy. Is there a way to increase that by
comparing the characters instead of likeness of words? I'm not really sure how to solve this issue as it's very hard to do quality check on the input when your talking about hundreds of names in the list. Is there a better way to compare values in power-shell
then the "like" operator? Do I need to use a database instead of a hash table? In the real world I feel like a search engine would know the differences in these variations and still provide the desired results so why not for this type of application?
In other words, create a bit more intelligence to say well it's not a 100% match but 90% so that is close enough, add it to the array as a match and add the price etc..
I'd be curious as to any thoughts on this? Maybe a scripting language with better matching for text?

Have you considered setting up a manual correction process that "learns" as you make corrections, automatically building a look up table of possible spellings of each Name? If you get an exact match, use it. If not, go to the look up
table and see if there's been a previous entry with the same spelling and what it was corrected to.
[string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

SORTED & HASHED tables

Hi all
what exactly are the SORTED & HASHED tables??
Regards
Srini

Internal tables are the core of ABAP. They are like soul of a body. For any program we use
internal tables extensively. We can use Internal tables like normal data base tables only, but the
basic difference is the memory allocated for internal tables is temporary. Once the program is
closed the memory allocated for internal tables will also be out of memory.
But while using the internal tables, there are many performance issues to be considered. i.e which
type of internal table to be used for the program..like standard internal table, hashed internal
table or sorted internal table etc..
Internal tables
Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by
line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data
objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables
whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for
storing and formatting data from a database table within a program. They are also a good way of including very complicated data
structures in an ABAP program.
Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract
description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The
data type is also an attribute of an existing data object.
Internal Tables as Data Types
Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type,
key, and table type.
Line type
The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the
structure is a column in the internal table. However, the line type may also be elementary or another internal table.
Key
The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify
whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness
depends on the table access method.
If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves
internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type
is an internal table, the default key is empty.
The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables
with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember
this, for example, if you intend to sort the table according to the key.
Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In
this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access
records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table.
The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled
very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the
table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system
uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether
the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of
table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique.
When you define the table, you must specify the key as UNIQUE.
Generic Internal Tables
Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a
generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic
internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data
objects.
Internal Tables as Dynamic Data Objects
Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in
respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects,
since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are
the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration)
is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more
than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The
individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the
internal table.
Choosing a Table Type
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most
frequently executed.
Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest
possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by
specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship
with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in
separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key
access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries
are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add
them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always
uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the
table key in the WHERE condition.
Hashed tables
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index.
The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always
have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for
processing large amounts of data.
Creating Internal Tables
Like other elements in the ABAP type concept, you can declare internal tables as abstract data
types in programs or in the ABAP Dictionary, and then use them to define data objects.
Alternatively, you can define them directly as data objects. When you create an internal table as a
data object, you should ensure that only the administration entry which belongs to an internal
table is declared statically. The minimum size of an internal table is 256 bytes. This is important if an
internal table occurs as a component of an aggregated data object, since even empty internal
tables within tables can lead to high memory usage. (In the next functional release, the size of the
table header for an initial table will be reduced to 8 bytes). Unlike all other ABAP data objects, you
do not have to specify the memory required for an internal table. Table rows are added to and
deleted from the table dynamically at runtime by the various statements for adding and deleting
records.
You can create internal tables in different types.
You can create standard internal table and then make it sort in side the program.
The same way you can change to hashed internal tables also.
There will be some performance issues with regard to standard internal tables/ hashed internal
tables/ sorted internal tables.
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.
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.
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
<tabkind> OF <linetype> WITH <key>
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.

Why append opration will not perform for hashed table???

could you pls explain why append is not working for hashed table while it is working for sort and hashed.......
Moderator Message: Interview-type questions are not allowed. Read the Rules of Engagement of these forum to avoid getting your ID deleted.
Edited by: kishan P on Mar 1, 2012 11:25 AM

Hello,
See the hashed tables does not support index operations like in standard and sorted tables rather its individual entries are accessed by key. The hashed internal table has been developed specifically using hashing algorithm. In other words, APPEND statement will not work in hashed internal tables but only in standard tables.
The processing of hashed tables are undertaken by using a KEY whereas for the standard table you may use the key to access it contents or not.
For more info you can refer to following link below -
[http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb35de358411d1829f0000e829fbfe/content.htm]
Hope this helps !

Hashed table -- Operations on it.

Similar Messages

Maybe you are looking for