How to define a hashed table?

Hi..
I want to know that how we can define a hash table in ABAB.
And what are the advantages of that table?
Thanks

once you have data in your internal table, there is not much of a performance issue...unless of course it contains a huge number of entries...
i m not aware of such a possibility that an internal table can behave as both sorted and hashed...
if you go for a hashed table, the response time for your search will always be constant, regardless of the number of table entries....this is because the search uses a hash algorithm...u must specify the UNIQUE key for hashed tables.
just go thru this link for some more information...
http://www.sap-img.com/abap/what-are-different-types-of-internal-tables-and-their-usage.htm
read this...
Standard tables are managed system-internally by a logical index. New rows are either attached to the table or added at certain positions. The table key or the index identify individual rows.
Sorted tables are managed by a logical index (like standard tables). The entries are listed in ascending order according to table key.
Hashed tables are managed by a hash algorithm. There is no logical index. The entries are not ordered in the memory. The position of a row is calculated by specifying a key using a hash function.
Sorted tables store records in a "sorted" fashion at all times. It is faster to search through a sorted table vs a standard table. But performance is dictated by the amount of records in the internal table.
A hashed table's performance in reads is NOT dependent on the number of records. However, it is intended for reads that will return only and only one record. It uses a "side-table" with a hash algorithm to store off the physical location of the record in the actual internal table. It is not NECESSARILY sorted/organized in an meaningful order (like a sorted table is). Please note that changes to a hashed tables records must be managed carefully. Review SAP's on-help in SE38/80 about managing hashed tables.
TYPES: BEGIN OF TY_ITAB,
FIELD1 TYPE I,
FIELD2 TYPE I,
END OF TY_ITAB.
TYPES ITAB TYPE SORTED TABLE OF TY_ITAB WITH UNIQUE KEY FIELD1.....
FOR PROPER SYNTEX F1 HELP....

Similar Messages

How to use one hash table inside another hash table

Hi everyone,
Any example of hash table inside another hash table.
Can one here help me how to write one hash table inside another with repeating keys for the first hash table.
Thanks,
kanty.

Do you mean you want the 'value' entries in a hash table to themselves be hash tables? Easy but this often indicates a design flaw.
Hashtable<String,<Hashtable<String,Value>> fred = new Hashtable<String,<Hashtable<String,Value>> ();But what do you mean by "with repeating keys for the first hash table"?
Edited by: sabre150 on Jul 2, 2010 10:11 PM
Looks like you have already handled the declaration side in your other thread. I suspect you should be writing your own beans that hold the information and these beans would then be stored in a Map. The problem I have is that your description is too vague so I can't be certain.

How to define an internal table which have to be dynamic

Hallo,
here's a problem that i have to solve (but how ?).
I defined an internal Table with 2 columns:
col1: tablename
col2: fieldname
This table is filled with an unknown number of datasets like this:
dataset1: A001 KAPPL
dataset2: A001 KNUMH
dataset3: A903 KUNNR and so on.
I don't know which tablenames and fieldnames are contained.
Now i have to read those fields (e.g. KAPPL) from those tables (e.g. A001) into an internal table.
But i don't know how to define this internal table.
Could anyone help me please ?
Thanks a lot.
Silvio

Hi Wirth
DATA:
w_tabname TYPE w_tabname,
w_dref TYPE REF TO data,
table_name TYPE tadir-obj_name.
FIELD-SYMBOLS: <t_itab> TYPE ANY TABLE.
READ YOUR INTERNAL TABLE (DATA SET) AND GET THE TABLE NAME,
AND PASS IT TO W_TABNAME.
w_tabname = A001.
CREATE DATA w_dref TYPE TABLE OF (w_tabname).
ASSIGN w_dref->* TO <t_itab>.
Now use <t_itab> as your internal table to fetch data .
<t_itab> will have the structure of A001.
SELECT *
FROM (w_tabname) UP TO 10 ROWS
INTO TABLE <t_itab>.
Regards
Hareesh Menon

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

How to fill a hashed table structure

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

Hello,
I will recommend you to use the program 'RSDRD_DELETE_FACTS'. This is easier and is generated for individual cubes and u can specify condition for the same with help of variants. Just follow the below steps
Goto SA38 and execute the program RSDRD_DELETE_FACTS. Then give your cube name and select the generate selection program radiobutton and give the name for the program. Execute and the program for selective deletion will be generated for that cube.
Now goto SE38 and select ur generated program for editing. You will see at the end that individual characteristic have a set of code as below:
IF NOT C011[] IS INITIAL.
CLEAR L_SX_SEL.
L_SX_SEL-IOBJNM = '0CALDAY'.
LOOP AT C011 .
    CLEAR L_S_RANGE.
    MOVE C011-SIGN TO L_S_RANGE-SIGN.
    MOVE C011-OPTION TO L_S_RANGE-OPTION.
    MOVE C011-LOW TO L_S_RANGE-LOW.
    MOVE C011-HIGH TO L_S_RANGE-HIGH.
    MOVE RS_C_TRUE TO L_S_RANGE-KEYFL.
    APPEND L_S_RANGE TO L_SX_SEL-T_RANGE.
ENDLOOP.
INSERT L_SX_SEL INTO TABLE L_THX_SEL.
ENDIF.
You need to search for 0CALDAY Code. It will look like above.
Now above all this IFs for characteristics, you can write the code for selective deletion.
The code will be like below.
DATA: date TYPE D,
      date1 TYPE D,
      RUN_MN1 TYPE /BI0/OICALDAY,
      LE_CO11 LIKE LINE OF C011.
date = sy-datum.
date1 = date - 30.
RUN_MN1 = date1.
LE_CO11-SIGN = 'I'.
LE_CO11-OPTION = 'LT'.
LE_CO11-LOW = RUN_MN1.
CLEAR C011.
APPEND LE_CO11 TO C011.
Hope this helps.
Regds,
Shashank

How can I use Hash Table when processing the data from cdpos and cdhdr

Hello Guru,
I've a question,
I need to reduce the access time to both cdhdr and cdpos.
Because may be I'll get a huge number of entries.
It looks like that by processing cdhdr and cdpos data will take many secondes,
it depends on how many data you need to find.
Hints : Putting instructions inside a form will slow down the program?
Also, I just want use Hash table and I need to put a loop-instruction going on the hash-table in form.
I know that it's no possible but I can declare an index inside my customized hash table.
For example :
DO
READ TABLE FOR specific_hash_table WITH KEY TABLE oindex = d_oindex.
Process data
d_oindex += 1.
UNTIL d_oindex = c_max_lines + 1.
Doing this would actually not necessary improve the performance.
Because It looks like I'm having a standard table, may be there's a hash function, but it could be a bad function.
Also I need to use for example COUNT (*) to know how many lines I get with the select.
FORM find_cdpos_data_with_loop
TABLES
    i_otf_objcs TYPE STANDARD TABLE
USING
    i_cdhdr_data TYPE HASHED TABLE
    i_objcl TYPE j_objnr
*    i_obj_lst TYPE any
    i_option TYPE c
CHANGING
    i_global TYPE STANDARD TABLE.
" Hint: cdpos is a cluster-table
CONSTANTS : objectid TYPE string VALUE 'objectid = i_obj_lst-objectid',
              changenr TYPE string VALUE 'changenr = i_obj_lst-changenr',
              tabname TYPE string VALUE 'tabname = i_otf_objcs-tablename',
              tabnameo1 TYPE string VALUE 'tabname NE ''''',
              tabnameo2 TYPE string VALUE 'tabname NE ''DRAD''',
              fname TYPE string VALUE 'fname = i_otf_objcs-fieldname'.
DATA : BEGIN OF i_object_list OCCURS 0,
            objectclas LIKE cdpos-objectclas,
            objectid LIKE cdpos-objectid,
            changenr LIKE cdpos-changenr,
         END OF i_object_list.
DATA : i_cdpos LIKE TABLE OF i_object_list WITH HEADER LINE,
         i_obj_lst LIKE LINE OF i_cdpos.
DATA : tabnamev2 TYPE string.
IF i_option EQ 'X'.
    MOVE tabnameo2 TO tabnamev2.
ELSE.
    MOVE tabnameo1 TO tabnamev2.
ENDIF.
*LOOP AT i_cdhdr_data TO i_obj_lst.
SELECT objectclas objectid changenr
    INTO TABLE i_cdpos
    FROM cdpos
    FOR ALL ENTRIES IN i_otf_objcs
    WHERE objectclas = i_objcl AND
          (objectid) AND
          (changenr) AND
          (tabname) AND
          (tabnamev2) AND
          (fname).
LOOP AT i_cdpos.
    APPEND i_cdpos-objectid TO i_global.
ENDLOOP.
*ENDLOOP.
ENDFORM.                    "find_cdpos_data

Hey Mart,
This is what I met, unfortunately I get the same performance with for all entries.
But with a lot of more code.
FORM find_cdpos_data
TABLES
    i_otf_objcs TYPE STANDARD TABLE
USING
    i_objcl TYPE j_objnr
    i_obj_lst TYPE any
    i_option TYPE c
CHANGING
    i_global TYPE STANDARD TABLE.
" Hint: cdpos is a cluster-table
CONSTANTS : objectid TYPE string VALUE 'objectid = i_obj_lst-objectid',
              changenr TYPE string VALUE 'changenr = i_obj_lst-changenr',
              tabname TYPE string VALUE 'tabname = i_otf_objcs-tablename',
              tabnameo1 TYPE string VALUE 'tabname NE ''''',
              tabnameo2 TYPE string VALUE 'tabname NE ''DRAD''',
              fname TYPE string VALUE 'fname = i_otf_objcs-fieldname'.
* DATA : BEGIN OF i_object_list OCCURS 0,
*            objectclas LIKE cdpos-objectclas,
*            objectid LIKE cdpos-objectid,
*            changenr LIKE cdpos-changenr,
*         END OF i_object_list.
** complete modified code [begin]
DATA : BEGIN OF i_object_list OCCURS 0,
            objectclas LIKE cdpos-objectclas,
            objectid LIKE cdpos-objectid,
            changenr LIKE cdpos-changenr,
            tabname LIKE cdpos-tabname,
            fname LIKE cdpos-fname,
         END OF i_object_list.
** complete modified code [end]
DATA : i_cdpos LIKE TABLE OF i_object_list WITH HEADER LINE.
DATA : tabnamev2 TYPE string.
** complete modified code [begin]
FIELD-SYMBOLS : <otf> TYPE ANY,
                <otf_field_tabname>,
                <otf_field_fname>.
** complete modified code [end]
IF i_option EQ 'X'.
    MOVE tabnameo2 TO tabnamev2.
ELSE.
    MOVE tabnameo1 TO tabnamev2.
ENDIF.
** SELECT objectclas objectid changenr
**    INTO TABLE i_cdpos
* SELECT objectid
*      APPENDING CORRESPONDING FIELDS OF TABLE i_global
*      FROM cdpos
*      FOR ALL ENTRIES IN i_otf_objcs
*      WHERE objectclas = i_objcl AND
*            (objectid) AND
*            (changenr) AND
*            (tabname) AND
*            (tabnamev2) AND
*            (fname).
** complete modified code [begin]
SELECT objectid tabname fname
      INTO CORRESPONDING FIELDS OF TABLE i_cdpos
      FROM cdpos
      WHERE objectclas = i_objcl AND
            (objectid) AND
            (changenr) AND
            (tabnamev2).
ASSIGN LOCAL COPY OF i_otf_objcs TO <otf>.
LOOP AT i_cdpos.
LOOP AT i_otf_objcs INTO <otf>.
   ASSIGN COMPONENT 'TABLENAME' OF STRUCTURE <otf> TO <otf_field_tabname>.
   ASSIGN COMPONENT 'FIELDNAME' OF STRUCTURE <otf> TO <otf_field_fname>.
    IF ( <otf_field_tabname> EQ i_cdpos-tabname ) AND ( <otf_field_fname> EQ i_cdpos-fname ).
      APPEND i_cdpos-objectid TO i_global.
      RETURN.
    ENDIF.
ENDLOOP.
ENDLOOP.
** complete modified code [end]
** LOOP AT i_cdpos.
**    APPEND i_cdpos-objectid TO i_global.
** ENDLOOP.
ENDFORM.                    "find_cdpos_data

How to define perform with table statement in ECC6.0

Hi all,
I am working on ECC6.0 version. I m using a perform to populate an internal table like this:-
    PERFORM explode TABLES li_zmpsdtl
                            USING gs_matnr.
& its forms is defined as: -
FORM treat_one_item TABLES   li_zmpsdtl STRUCTURE zmpsdtl
                     USING    gs_matnr TYPE matnr.
doing some action..............
endform.
While performing SLIN it shows an error message :-
" The current ABAP command is obsolete.
Within classes and interfaces, you can only use "TYPE" to refer to ABAP Dictionary types (not "LIKE" or "STRUCTURE"). "
If i use type in place of STRUCTURE then it is ok, but zmpsdtl should be defined as table type. :-
FORM treat_one_item TABLES   li_zmpsdtl type zmpsdtl
                     USING    gs_matnr TYPE matnr.
doing some action..............
endform.
is there any other option to do the same thing. i dont want to create any teable type.
Thanx in advance,
Sachin

You have to use a global structure instead of a ddic structure after the STRUCTURE statement:
<b>DATA: gs_zmpsdtl TYPE zmpsdtl.</b>
FORM treat_one_item TABLES li_zmpsdtl STRUCTURE <b>gs_zmpsdt</b>
USING gs_matnr TYPE matnr.
...[/code]

How to define width of table column by percentage?

I tried, but it doesn't work.
JDev: 11g
Thanks.
Kevin.

seems no way, also discussed in the following thread
Re: ADF <af:column> width attribute

How to create hashed table in runtime

hi experts
how to create hashed table in runtime, please give me the coading style.
please help me.
regards
subhasis

Hi,
Have alook at the code, and pls reward points.
Use Hashed Tables to Improve Performance :
report zuseofhashedtables.
Program: ZUseOfHashedTables                                        **
Author: XXXXXXXXXXXXXXXXXX                                 **
Versions: 4.6b - 4.6c                                              **
Notes:                                                             **
    this program shows how we can use hashed tables to improve     **
    the responce time.                                             **
    It shows,                                                      **
       1. how to declare hashed tables                             **
       2. a cache-like technique to improve access to master data **
       3. how to collect data using hashed tables                  **
       4. how to avoid deletions of unwanted data                  **
Results: the test we run read about 31000 rows from mkpf, 150000   **
         rows from mseg, 500 rows from makt and 400 from lfa1.     **
         it filled ht_lst with 24500 rows and displayed them in    **
         alv grid format.                                          **
         It needed about 65 seconds to perform this task (with     **
         all the db buffers empty)                                 **
         The same program with standard tables needed 140 seconds **
         to run with the same recordset and with buffers filled in **
Objetive: show a list that consists of all the material movements **
         '101' - '901' for a certain range of dates in mkpf-budat. **
the columns to be displayed are:                                   **
         mkpf-budat,                                               **
         mkpf-mblnr,                                               **
         mseg-lifnr,                                               **
         lfa1-name1,                                               **
         mkpf-xblnr,                                               **
         mseg-zeile                                                **
         mseg-charg,                                               **
         mseg-matnr,                                               **
         makt-maktx,                                               **
         mseg-erfmg,                                               **
         mseg-erfme.                                               **
or show a sumary list by matnr - menge                             **
You'll have to create a pf-status called vista -                   **
See form set_pf_status for details                                 **
tables used -
tables: mkpf,
        mseg,
        lfa1,
        makt.
global hashed tables used
data: begin of wa_mkpf, "header
      mblnr like mkpf-mblnr,
      mjahr like mkpf-mjahr,
      budat like mkpf-budat,
      xblnr like mkpf-xblnr,
      end of wa_mkpf.
data: ht_mkpf like hashed table of wa_mkpf
      with unique key mblnr mjahr
      with header line.
data: begin of wa_mseg, " line items
      mblnr like mseg-mblnr,
      mjahr like mseg-mjahr,
      zeile like mseg-zeile,
      bwart like mseg-bwart,
      charg like mseg-charg,
      matnr like mseg-matnr,
      lifnr like mseg-lifnr,
      erfmg like mseg-erfmg,
      erfme like mseg-erfme,
      end of wa_mseg.
data ht_mseg like hashed table of wa_mseg
      with unique key mblnr mjahr zeile
      with header line.
cache structure for lfa1 records
data: begin of wa_lfa1,
      lifnr like lfa1-lifnr,
      name1 like lfa1-name1,
      end of wa_lfa1.
data ht_lfa1 like hashed table of wa_lfa1
      with unique key lifnr
      with header line.
cache structure for material related data
data: begin of wa_material,
      matnr like makt-matnr,
      maktx like makt-maktx,
      end of wa_material.
data: ht_material like hashed table of wa_material
        with unique key matnr
        with header line.
result table
data: begin of wa_lst, "
      budat like mkpf-budat,
      mblnr like mseg-mblnr,
      lifnr like mseg-lifnr,
      name1 like lfa1-name1,
      xblnr like mkpf-xblnr,
      zeile like mseg-zeile,
      charg like mseg-charg,
      matnr like mseg-matnr,
      maktx like makt-maktx,
      erfmg like mseg-erfmg,
      erfme like mseg-erfme,
      mjahr like mseg-mjahr,
      end of wa_lst.
data: ht_lst like hashed table of wa_lst
        with unique key mblnr mjahr zeile
        with header line.
data: begin of wa_lst1, " sumary by material
      matnr like mseg-matnr,
      maktx like makt-maktx,
      erfmg like mseg-erfmg,
      erfme like mseg-erfme,
      end of wa_lst1.
data: ht_lst1 like hashed table of wa_lst1
        with unique key matnr
        with header line.
structures for alv grid display.
itabs
type-pools: slis.
data: it_lst            like standard table of wa_lst with header line,
      it_fieldcat_lst   type slis_t_fieldcat_alv with header line,
      it_sort_lst       type slis_t_sortinfo_alv,
      it_lst1           like standard table of wa_lst1 with header line,
      it_fieldcat_lst1 type slis_t_fieldcat_alv with header line,
      it_sort_lst1      type slis_t_sortinfo_alv.
structures
data: wa_sort         type slis_sortinfo_alv,
      ls_layout       type slis_layout_alv.
global varialbes
data: g_lines type i.
data: g_repid like sy-repid,
      ok_code       like sy-ucomm.
selection-screen
"text: Dates:
select-options: so_budat for mkpf-budat default sy-datum.
"text: Material numbers.
select-options: so_matnr for mseg-matnr.
selection-screen uline.
selection-screen skip 1.
"Text: show summary by material.
parameters: gp_bymat as checkbox default ''.
start-of-selection.
perform get_data.
perform show_data.
end-of-selection.
      FORM get_data                                                 *
form get_data.
        select mblnr mjahr budat xblnr
            into table ht_mkpf
           from mkpf
          where budat in so_budat. " make use of std index.
have we retrieved data from mkpf?
describe table ht_mkpf lines g_lines.
if g_lines > 0.
if true then retrieve all related records from mseg.
Doing this way we make sure that the access is by primary key
of mseg.
The reason is that is faster to filter them in memory
than to allow the db server to do it.
    select mblnr mjahr zeile bwart charg
             matnr lifnr erfmg erfme
      into table ht_mseg
      from mseg
        for all entries in ht_mkpf
     where mblnr = ht_mkpf-mblnr
       and mjahr = ht_mkpf-mjahr.
endif.
fill t_lst or t_lst1 according to user's choice.
if gp_bymat = ' '.
    perform fill_ht_lst.
else.
    perform fill_ht_lst1.
endif.
endform.
form fill_ht_lst.
refresh ht_lst.
Example: how to discard unwanted data in an efficient way.
loop at ht_mseg.
filter unwanted data
    check ht_mseg-bwart = '101' or ht_mseg-bwart = '901'.
    check ht_mseg-matnr in so_matnr.
read header line.
    read table ht_mkpf with table key mblnr = ht_mseg-mblnr
    mjahr = ht_mseg-mjahr.
    clear ht_lst.
* note : this may be faster if you specify field by field.
    move-corresponding ht_mkpf to ht_lst.
    move-corresponding ht_mseg to ht_lst.
    perform read_lfa1 using ht_mseg-lifnr changing ht_lst-name1.
    perform read_material using ht_mseg-matnr changing ht_lst-maktx.
    insert table ht_lst.
endloop.
endform.
form fill_ht_lst1.
refresh ht_lst1.
Example: how to discard unwanted data in an efficient way.
         hot to simulate a collect in a faster way
loop at ht_mseg.
filter unwanted data
    check ht_mseg-bwart = '101' or ht_mseg-bwart = '901'.
    check ht_mseg-matnr in so_matnr.
* note : this may be faster if you specify field by field.
    read table ht_lst1 with table key matnr = ht_mseg-matnr
    transporting erfmg.
    if sy-subrc <> 0. " if matnr doesn't exist in sumary table
    " insert a new record
      ht_lst1-matnr = ht_mseg-matnr.
      perform read_material using ht_mseg-matnr changing ht_lst1-maktx.
      ht_lst1-erfmg = ht_mseg-erfmg.
      ht_lst1-erfme = ht_mseg-erfme.
      insert table ht_lst1.
    else." a record was found.
    " collect erfmg. To do so, fill in the unique key and add
    " the numeric fields.
      ht_lst1-matnr = ht_mseg-matnr.
      add ht_mseg-erfmg to ht_lst1-erfmg.
      modify table ht_lst1 transporting erfmg.
    endif.
endloop.
endform.
implementation of cache for lfa1.
form read_lfa1 using p_lifnr changing p_name1.
        read table ht_lfa1 with table key lifnr = p_lifnr
        transporting name1.
if sy-subrc <> 0.
    clear ht_lfa1.
    ht_lfa1-lifnr = p_lifnr.
    select single name1
       into ht_lfa1-name1
      from lfa1
    where lifnr = p_lifnr.
    if sy-subrc <> 0. ht_lfa1-name1 = 'n/a in lfa1'. endif.
    insert table ht_lfa1.
endif.
p_name1 = ht_lfa1-name1.
endform.
implementation of cache for material data
form read_material using p_matnr changing p_maktx.
read table ht_material with table key matnr = p_matnr
transporting maktx.
if sy-subrc <> 0.
    ht_material-matnr = p_matnr.
    select single maktx into ht_material-maktx
      from makt
     where spras = sy-langu
       and matnr = p_matnr.
    if sy-subrc <> 0. ht_material-maktx = 'n/a in makt'. endif.
    insert table ht_material.
endif.
p_maktx = ht_material-maktx.
endform.
form show_data.
if gp_bymat = ' '.
    perform show_ht_lst.
else.
    perform show_ht_lst1.
endif.
endform.
form show_ht_lst.
"needed because the FM can't use a hashed table.
it_lst[] = ht_lst[].
perform fill_layout using 'full display'
                       changing ls_layout.
perform fill_columns_lst.
perform sort_lst.
g_repid = sy-repid.
call function 'REUSE_ALV_GRID_DISPLAY'
       exporting
            i_callback_program       = g_repid
            i_callback_pf_status_set = 'SET_PF_STATUS'
            is_layout                = ls_layout
            it_fieldcat              = it_fieldcat_lst[]
           it_sort                  = it_sort_lst
       tables
            t_outtab                 = it_lst
       exceptions
            program_error            = 1
            others                   = 2.
endform.
form show_ht_lst1.
"needed because the FM can't use a hashed table.
it_lst1[] = ht_lst1[].
perform fill_layout using 'Sumary by matnr'
                       changing ls_layout.
perform fill_columns_lst1.
perform sort_lst.
g_repid = sy-repid.
call function 'REUSE_ALV_GRID_DISPLAY'
       exporting
            i_callback_program       = g_repid
            i_callback_pf_status_set = 'SET_PF_STATUS'
            is_layout                = ls_layout
            it_fieldcat              = it_fieldcat_lst1[]
           it_sort                  = it_sort_lst
       tables
            t_outtab                 = it_lst1
       exceptions
            program_error            = 1
            others                   = 2.
endform.
form fill_layout using p_window_titlebar
               changing cs_layo type slis_layout_alv.
clear cs_layo.
cs_layo-window_titlebar        = p_window_titlebar.
cs_layo-edit                   = 'X'.
cs_layo-edit_mode              = space.
endform.                    " armar_layout_stock
form set_pf_status using rt_extab type slis_t_extab.
create a new status
and then select extras -> adjust template -> listviewer
set pf-status 'VISTA'.
endform.        "set_pf_status
define add_lst.
clear it_fieldcat_lst.
it_fieldcat_lst-fieldname     = &1.
it_fieldcat_lst-outputlen     = &2.
it_fieldcat_lst-ddictxt       = 'L'.
it_fieldcat_lst-seltext_l       = &1.
it_fieldcat_lst-seltext_m       = &1.
it_fieldcat_lst-seltext_m       = &1.
if &1 = 'MATNR'.
    it_fieldcat_lst-emphasize = 'C111'.
endif.
append it_fieldcat_lst.
end-of-definition.
define add_lst1.
clear it_fieldcat_lst.
it_fieldcat_lst1-fieldname     = &1.
it_fieldcat_lst1-outputlen     = &2.
it_fieldcat_lst1-ddictxt       = 'L'.
it_fieldcat_lst1-seltext_l       = &1.
it_fieldcat_lst1-seltext_m       = &1.
it_fieldcat_lst1-seltext_m       = &1.
append it_fieldcat_lst1.
end-of-definition.
form fill_columns_lst.
set columns for output.
refresh it_fieldcat_lst.
add_lst 'BUDAT' 10.
add_lst   'MBLNR' 10.
add_lst 'LIFNR' 10.
add_lst 'NAME1' 35.
add_lst 'XBLNR' 15.
add_lst    'ZEILE' 5.
add_lst    'CHARG' 10.
add_lst   'MATNR' 18.
add_lst   'MAKTX' 30.
add_lst   'ERFMG' 17.
add_lst   'ERFME' 5.
add_lst   'MJAHR' 4.
endform.
form fill_columns_lst1.
set columns for output.
refresh it_fieldcat_lst1.
add_lst1 'MATNR' 18.
add_lst1 'MAKTX' 30.
add_lst1 'ERFMG' 17.
add_lst1 'ERFME' 5..
endform.
Regards,
Ameet

Define hashed table using database table

Hi,
I have a database table and would want to define a hashed table using this table structure, how would I do that?
Thanks
RT

Hi Rob,
The syntax is as follows,
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.

Experimenting with hashed table.

Hello experts,
I am currently experementing with using hashed table for my report and this is my first time to try this. Below is my code:
DATA: it_iloa type hashed TABLE OF t_iloa
WITH unique KEY iloan.
Now here is my problem, Originally I am reading it_iloa using its header line. Now, how can I define my hashed table to have a work area/header line?
Again, thanks guys and have a nice day!

Hi,
The SORTED table / HASH table are best used along with a LEY definition of the table, meaning you will declare a key for the internal table.
So, while declare the table add the WITH UNIQUE KEY column1.
This will create a HASH index on the column1 and when you are reading the table, make sure you have column1 in the where clause so that HASH index is used and the performance is improved.
However, unless the table has got huge data you will not be able to see the difference.
Regards,
Ravi

Hash table reallocation (rehashing)

Hello!
I use embedded Berkeley DB to store millions of small items (key ~ 16 byte, value ~ 16 byte). The exact number of items couldn't be known at the time of hash table allocation, so i push to set_h_nelem amount about 100 millions. After some period of time hash table becomes full and i need to rebuild (reallocate) it to avoid lacks in performance.
Does anyone know how to initiate manual hash table reallocation (to expand it) (C/C++ API is prefered)?

Hi,
Just go thro' this.
1. Types of internal tables
1.1 STANDARD table
Key access to a standard table uses a linear search. This means that the time required for a search is in linear relation to the number of table entries.
You should use index operations to access standard tables.
1.2 SORTED table
Defines the table as one that is always saved correctly sorted.
Key access to a sorted table uses a binary key. If the key is not unique, the system takes the entry with the lowest index. The runtime required for key access is logarithmically related to the number of table entries.
1.3 HASHED table
Defines the table as one that is managed with an internal hash procedure
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 oe INSERT itab within a LOOP) are not allowed.
1.4 INDEX table
A table that can be accessed using an index.
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.
Standard tables and sorted tables are index tables.
1.5 ANY table
Any 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 ANY.
Standard, sorted and hashed tables belongs to ANY tables.

How to declare a internal table in start routine i.e. transformations

Hi Gurus,
How to define an internal table in a start rotuine?
any help greatly appreciated.
Best Regards,
Reddy.

Hi,
types: begin of str,
field1 type c,
field2 type c,
end of str.
data : itab type table of str with header line.
the above code should be inserted where it says insert code below this. this will be like a global decleration. this table will be available for all the routines that you write in the transformation.
All the best !!
Regards
Aparna

What is HASH Table?

Hi all,
Can anyone explain me what is HASH table?
Thanks in Advance.......

An internal table of type HASHED can be used to improve performance. Hashed tables have no linear index. You can only access hashed tables by specifying
the key. The system has its own hash algorithm for managing the table.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.A restriction for hashed tables is that they may not contain more than 2 million entries.
You can also chk the links
http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb2fcc358411d1829f0000e829fbfe/content.htm
http://help.sap.com/saphelp_47x200/helpdata/en/90/8d7328b1af11d194f600a0c929b3c3/frameset.htm
If you have an internal table in your program which is used solely for lookup, it is good programming practice to use a hash table. The example below shows this, in combination with a method for buffering SELECT SINGLE results.
Code
*&      Form select_dispo
      Get MRP controller and in-house production time from material
      and plant
     --> MATNR Material
     --> RESWK Plant
     <-- DISPO MRP controller
     <-- DZEIT In-house production time
form select_from_marc using matnr werks dispo dzeit.
types: begin of mrp_lookup_type,
           matnr like marc-matnr,
           werks like marc-werks,
           dispo like marc-dispo,
           dzeit like marc-dzeit,
         end of mrp_lookup_type.
Define static hashed table to hold results
statics: st_mrp type hashed table of mrp_lookup_type
                  with unique key matnr werks.
data: l_wa_mrp type mrp_lookup_type.
clear dzeit.
See if data is in the table
read table st_mrp into l_wa_mrp with table key matnr = matnr
                                                 werks = werks.
If not in table, get it from the database
if not sy-subrc is initial.
    select single dispo dzeit from marc
        into corresponding fields of l_wa_mrp-dispo
        where matnr eq matnr
          and werks eq werks.
Insert into table
    l_wa_mrp-matnr = matnr.
    l_wa_mrp-werks = werks.
    insert l_wa_mrp into table st_mrp.
endif.
dispo = l_wa_mrp-dispo.                      " MRP Controller
dzeit = l_wa_mrp-dzeit.                      " Inhouse production time
endform.                    " select_from_marc
reward points if helpful

How to define join in physical layer between cube and relational table

Hi
I have a aggregated data in essbase cube. I want to supplement the information in the cube with data from relational source.
I read article http://community.altiusconsulting.com/blogs/altiustechblog/archive/2008/10/24/are-essbase-and-oracle-bi-enterprise-edition-obiee-a-match-made-in-heaven.aspx which describes how to do it.
From this article I gather that I have to define a complex join between the cube imported from essbase to my relational table in physical layer.
But when I use Join Manager I am only able to define jooin between tables from relation source but not with the imported cube.
In My case I am trying to join risk dimension in the cube based on risk_type_code (Gen3 member) with risk_type_code in relation table dt_risk_type.
How can I create this join?
Regards
Dhwaj

Hi
This has worked the BI server has joined the member from the oracle database to cube. So Now for risk type id defined in the cube I can view the risk type code and risk type name from the relational db.
But now if I want to find aggregated risk amount against a risk type id it brings back nothing. If I remove the join in the logical model then I get correct values. Is there a way by which I can combine phsical cube with relational model and still get the aggregated values in the cube?
I have changed the column risk amount to be sum in place of aggr_external both in logical and phsical model.
Regards,
Dhwaj

How to define a hashed table?

Similar Messages

Maybe you are looking for