Swing and hash table

i have program that reveived the input through JTextField ,
then i want it to search for that value in hash table and display it in an JTextArea,
i only don't know how to search the value of input in the hash table and display it in JTextArea?

xtremliep wrote:
Hi dapim,
have a look at the example here:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Hashtable.html
If your Hashtable looks like this:
Hashtable numbers = new Hashtable();
numbers.put("one", new Integer(1));
numbers.put("two", new Integer(2));
numbers.put("three", new Integer(3));You could access it like this
Integer n = (Integer)numbers.get(JTextField.getText());
- use the interface not the implementation as declaring type
- use HashMap not Hashtable if it's only accessed by a single thread
- use generics
- use autoboxing to allow the reuse of objects
So this code would look like this:
Map<String, Integer> numbers = new HashMap<String, Integer>();
numbers.put("one", 1);
numbers.put("two", 2);
numbers.put("three", 3);
int n = numbers.get(myTextField.getText());-Puce

Similar Messages

  • What is the difference between standard,sorted and hash table

    <b>can anyone say what is the difference between standard,sorted and hash tabl</b>

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

  • Sorted and hashed tables

    what happens when duplicate entries are present in sorted and hashed tables?

    Hi,
    Sorted internal tables can be of two types:
    unique or non unique.
    If u enter duplicate records in Sorted tables with unique  it will show error.
    If u enter duplicate records in Sorted tables with  non-unique key it will not show error.
    Hashed tables are with only unique key
    so no way to enter the duplicate records.
    for more information see the following link
    http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb35de358411d1829f0000e829fbfe/content.htm
    Reward if helpful.
    Jagadish

  • Operation with Hashed and Sorted Tables

    Hi,
    What are all the internal table operations are possible with sorted and Hashed table.
    Kindly let me know,

    Refer this help in case you have not done already.
    http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb35de358411d1829f0000e829fbfe/frameset.htm
    Regards,
    Ravi Kanth

  • How about use partial key to loop at a hashed table?

    Such as I want to loop a Internal table of BSID according to BKPF.
    data itab_bsid type hashed table of BSID with unique key bukrs belnr gjahr buzid.
    Loop at itab_bsid where bukrs = wa_bkpf-bukrs
                              and    belnr  = wa_bkpf-belnr
                              and    gjahr  = wa_bkpf-gjahr.
    endloop.
    I know if you use all key to access this hashed table ,it is certainly quick, and my question is when i use partial key of this internal hashed table to loop it, how about its performance.
    Another question is in this case(BSID have many many record) , Sorted table and Hashed table , Which is better in performance.

    You can't cast b/w data reference which l_tax is and object reference which l_o_tax_code is.
    osref is a generic object type and you store a reference to some object in it, right? So the question is: what kind of object you store there? Please note - this must be an object reference , not data reference .
    i.e
    "here goes some class
    class zcl_spfli definition.
    endclass.
    class zcl_spfli implementation.
    endclass.
    "here is an OBJECT REFERENCE for it, (so I refer to a class) i.e persistent object to table SPFLI
    data oref_spfli type ref to zcl_spfli.
    "but here I have a DATA REFERENCE (so I refer to some data object) i.e DDIC structure SPFLI
    data dref_spfli type ref to spfli.
    So my OSREF can hold only oref_spfli but it not intended for dref_spfli . That's why you get this syntax error. Once you have stored reference to zcl_spfli in osref then you will be able to dereference it and access this object's attributes.
    data: osref type osref.
    create object osref_spfli.
    osref = osref_spfli.
    "now osref holds reference to object, you can deference it
    oref_spfli ?= osref.
    osref_spfli->some_attribute = ....
    OSREFTAB is just a table whose line is of type OSREF (so can hold multiple object references - one in each line).
    Regards
    Marcin

  • Question about sorted, hashed tables, mindset when using OO concepts...

    Hello experts,
    I just want to make sure if my idea about sorted and hashed table is correct.Please give tips and suggestions.
    In one of my reports, I declared a structure and an itab.
    TYPES: BEGIN OF t_mkpf,
            mblnr           LIKE mkpf-mblnr,
            mjahr           LIKE mkpf-mjahr,
            budat           LIKE mkpf-budat,
            xblnr(10)       TYPE c,
            tcode2          LIKE mkpf-tcode2,
            cputm           LIKE mkpf-cputm,
            blart           LIKE mkpf-blart,
          END OF t_mkpf.
    it_mkpf       TYPE SORTED   TABLE OF t_mkpf WITH HEADER LINE
                                       WITH NON-UNIQUE KEY mblnr mjahr.
    Now, I declared it as a sorted table with a non-unique key MBLNR and MJAHR. Now suppose I have 1000 records in my itab. how will it search for a particular record?
    2. Is it faster than sorting a standard table then reading it using binary search?
    3. How do I use a hashed table effectively? lets say that I want to use hashed type instead of sorted table in my example above.
    4. I am currently practicing ABAP Objects and my problem is that I think my mindset when programming a report is still the 'procedural one'. How do one use ABAP concepts effectively?
    Again, thank you guys and have a nice day!

    Hi Viray,
    <b>The different ways to fill an Internal Table:</b>
    <b>append&sort</b>
    This is the simplest one. I do appends on a standard table and then a sort.
    data: lt_tab type standard table of ...
    do n times.
    ls_line = ...
    append ls_line to lt_tab.
    enddo.
    sort lt_tab.
    The thing here is the fast appends and the slow sort - so this is interesting how this will compare to the following one.
    <b>read binary search & insert index sy-tabix</b>
    In this type I also use a standard table, but I read to find the correct insert index to get a sorted table also.
    data: lt_tab type standard table of ...
    do n times.
    ls_line = ...
    read table lt_tab transporting no fields with key ... binary search.
    if sy-subrc <> 0.
      insert ls_line into lt_tab index sy-tabix.
    endif.
    enddo.
    <b>sorted table with non-unique key</b>
    Here I used a sorted table with a non-unique key and did inserts...
    data: lt_tab type sorted table of ... with non-unique key ...
    do n times.
    ls_line = ...
    insert ls_line into table lt_tab.
    enddo.
    <b>sorted table with unique key</b>
    The coding is the same instead the sorted table is with a unique key.
    data: lt_tab type sorted table of ... with unique key ...
    do n times.
    ls_line = ...
    insert ls_line into table lt_tab.
    enddo.
    <b>hashed table</b>
    The last one is the hashed table (always with unique key).
    data: lt_tab type hashed table of ... with unique key ...
    do n times.
    ls_line = ...
    insert ls_line into table lt_tab.
    enddo.
    <b>You Can use this Program to Test:</b>
    types:
      begin of local_long,
        key1 type char10,
        key2 type char10,
        data1 type char10,
        data2 type char10,
        data3 type i,
        data4 type sydatum,
        data5 type numc10,
        data6 type char32,
        data7 type i,
        data8 type sydatum,
        data9 type numc10,
        dataa type char32,
        datab type i,
        datac type sydatum,
        datad type numc10,
        datae type char32,
        dataf type i,
        datag type sydatum,
        datah type numc10,
        datai type char32,
        dataj type i,
        datak type sydatum,
        datal type numc10,
        datam type char32,
        datan type i,
        datao type sydatum,
        datap type numc10,
        dataq type char32,
        datar type i,
        datas type sydatum,
        datat type numc10,
        datau type char32,
        datav type i,
        dataw type sydatum,
        datax type numc10,
        datay type char32,
        dataz type i,
        data11 type numc10,
        data21 type char32,
        data31 type i,
        data41 type sydatum,
        data51 type numc10,
        data61 type char32,
        data71 type i,
        data81 type sydatum,
        data91 type numc10,
        dataa1 type char32,
        datab1 type i,
        datac1 type sydatum,
        datad1 type numc10,
        datae1 type char32,
        dataf1 type i,
        datag1 type sydatum,
        datah1 type numc10,
        datai1 type char32,
        dataj1 type i,
        datak1 type sydatum,
        datal1 type numc10,
        datam1 type char32,
        datan1 type i,
        datao1 type sydatum,
        datap1 type numc10,
        dataq1 type char32,
        datar1 type i,
        datas1 type sydatum,
        datat1 type numc10,
        datau1 type char32,
        datav1 type i,
        dataw1 type sydatum,
        datax1 type numc10,
        datay1 type char32,
        dataz1 type i,
      end of local_long.
    data:
      ls_long type local_long,
      lt_binary type standard table of local_long,
      lt_sort_u type sorted table of local_long with unique key key1 key2,
      lt_sort_n type sorted table of local_long with non-unique key key1 key2,
      lt_hash_u type hashed table of local_long with unique key key1 key2,
      lt_apsort type standard table of local_long.
    field-symbols:
      <ls_long> type local_long.
    parameters:
      min1 type i default 1,
      max1 type i default 1000,
      min2 type i default 1,
      max2 type i default 1000,
      i1 type i default 100,
      i2 type i default 200,
      i3 type i default 300,
      i4 type i default 400,
      i5 type i default 500,
      i6 type i default 600,
      i7 type i default 700,
      i8 type i default 800,
      i9 type i default 900,
      fax type i default 1000.
    types:
      begin of measure,
        what(10) type c,
        size(6) type c,
        time type i,
        lines type i,
        reads type i,
        readb type i,
        fax_s type i,
        fax_b type i,
        fax(6) type c,
        iter type i,
      end of measure.
    data:
      lt_time type standard table of measure,
      lt_meantimes type standard table of measure,
      ls_time type measure,
      lv_method(7) type c,
      lv_i1 type char10,
      lv_i2 type char10,
      lv_f type f,
      lv_start type i,
      lv_end type i,
      lv_normal type i,
      lv_size type i,
      lv_order type i,
      lo_rnd1 type ref to cl_abap_random_int,
      lo_rnd2 type ref to cl_abap_random_int.
    get run time field lv_start.
    lo_rnd1 = cl_abap_random_int=>create( seed = lv_start min = min1 max = max1 ).
    add 1 to lv_start.
    lo_rnd2 = cl_abap_random_int=>create( seed = lv_start min = min2 max = max2 ).
    ls_time-fax = fax.
    do 5 times.
      do 9 times.
        case sy-index.
          when 1. lv_size = i1.
          when 2. lv_size = i2.
          when 3. lv_size = i3.
          when 4. lv_size = i4.
          when 5. lv_size = i5.
          when 6. lv_size = i6.
          when 7. lv_size = i7.
          when 8. lv_size = i8.
          when 9. lv_size = i9.
        endcase.
        if lv_size > 0.
          ls_time-iter = 1.
          clear lt_apsort.
          ls_time-what = 'APSORT'.
          ls_time-size = lv_size.
          get run time field lv_start.
          do lv_size times.
            perform fill.
            append ls_long to lt_apsort.
          enddo.
          sort lt_apsort by key1 key2.
          get run time field lv_end.
          ls_time-time = lv_end - lv_start.
          ls_time-reads = 0.
          ls_time-readb = 0.
          ls_time-lines = lines( lt_apsort ).
          get run time field lv_start.
          do.
            add 1 to ls_time-readb.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_apsort
              assigning <ls_long>
              with key key1 = lv_i1
                       key2 = lv_i2
              binary search.
            if sy-subrc = 0.
              <ls_long>-data11 = sy-index.
            endif.
            get run time field lv_end.
            subtract lv_start from lv_end.
            if lv_end >= ls_time-time.
              exit.
            endif.
          enddo.
          get run time field lv_start.
          do.
            add 1 to ls_time-reads.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_apsort
              assigning <ls_long>
              with key key2 = lv_i1
                       key1 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data11 = sy-index.
            endif.
            get run time field lv_end.
            subtract lv_start from lv_end.
            if lv_end >= ls_time-time.
              exit.
            endif.
          enddo.
          get run time field lv_start.
          do fax times.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_apsort
              assigning <ls_long>
              with key key1 = lv_i1
                       key2 = lv_i2
              binary search.
            if sy-subrc = 0.
              <ls_long>-data21 = sy-index.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-fax_b = lv_end - lv_start.
          get run time field lv_start.
          do fax times.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_apsort
              assigning <ls_long>
              with key key2 = lv_i1
                       key1 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data21 = sy-index.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-fax_s = lv_end - lv_start.
          collect ls_time into lt_time.
          clear lt_binary.
          ls_time-what = 'BINARY'.
          ls_time-size = lv_size.
          get run time field lv_start.
          do lv_size times.
            perform fill.
            read table lt_binary
              transporting no fields
              with key key1 = ls_long-key1
                       key2 = ls_long-key2
              binary search.
            if sy-index <> 0.
              insert ls_long into lt_binary index sy-tabix.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-time = lv_end - lv_start.
          ls_time-reads = 0.
          ls_time-readb = 0.
          ls_time-lines = lines( lt_binary ).
          get run time field lv_start.
          do.
            add 1 to ls_time-readb.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_binary
              assigning <ls_long>
              with key key1 = lv_i1
                       key2 = lv_i2
              binary search.
            if sy-subrc = 0.
              <ls_long>-data11 = sy-index.
            endif.
            get run time field lv_end.
            subtract lv_start from lv_end.
            if lv_end >= ls_time-time.
              exit.
            endif.
          enddo.
          get run time field lv_start.
          do.
            add 1 to ls_time-reads.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_binary
              assigning <ls_long>
              with key key2 = lv_i1
                       key1 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data11 = sy-index.
            endif.
            get run time field lv_end.
            subtract lv_start from lv_end.
            if lv_end >= ls_time-time.
              exit.
            endif.
          enddo.
          get run time field lv_start.
          do fax times.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_binary
              assigning <ls_long>
              with key key1 = lv_i1
                       key2 = lv_i2
              binary search.
            if sy-subrc = 0.
              <ls_long>-data21 = sy-index.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-fax_b = lv_end - lv_start.
          get run time field lv_start.
          do fax times.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_binary
              assigning <ls_long>
              with key key2 = lv_i1
                       key1 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data21 = sy-index.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-fax_s = lv_end - lv_start.
          collect ls_time into lt_time.
          clear lt_sort_n.
          ls_time-what = 'SORT_N'.
          ls_time-size = lv_size.
          get run time field lv_start.
          do lv_size times.
            perform fill.
            insert ls_long into table lt_sort_n.
          enddo.
          get run time field lv_end.
          ls_time-time = lv_end - lv_start.
          ls_time-reads = 0.
          ls_time-readb = 0.
          ls_time-lines = lines( lt_sort_n ).
          get run time field lv_start.
          do.
            add 1 to ls_time-readb.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_sort_n
              assigning <ls_long>
              with table key key1 = lv_i1
                             key2 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data11 = sy-index.
            endif.
            get run time field lv_end.
            subtract lv_start from lv_end.
            if lv_end >= ls_time-time.
              exit.
            endif.
          enddo.
          get run time field lv_start.
          do.
            add 1 to ls_time-reads.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_sort_n
              assigning <ls_long>
              with key key2 = lv_i1
                       key1 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data11 = sy-index.
            endif.
            get run time field lv_end.
            subtract lv_start from lv_end.
            if lv_end >= ls_time-time.
              exit.
            endif.
          enddo.
          get run time field lv_start.
          do fax times.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_sort_n
              assigning <ls_long>
              with table key key1 = lv_i1
                             key2 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data21 = sy-index.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-fax_b = lv_end - lv_start.
          get run time field lv_start.
          do fax times.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_sort_n
              assigning <ls_long>
              with key key2 = lv_i1
                       key1 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data21 = sy-index.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-fax_s = lv_end - lv_start.
          collect ls_time into lt_time.
          clear lt_sort_u.
          ls_time-what = 'SORT_U'.
          ls_time-size = lv_size.
          get run time field lv_start.
          do lv_size times.
            perform fill.
            insert ls_long into table lt_sort_u.
          enddo.
          get run time field lv_end.
          ls_time-time = lv_end - lv_start.
          ls_time-reads = 0.
          ls_time-readb = 0.
          ls_time-lines = lines( lt_sort_u ).
          get run time field lv_start.
          do.
            add 1 to ls_time-readb.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_sort_u
              assigning <ls_long>
              with table key key1 = lv_i1
                             key2 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data11 = sy-index.
            endif.
            get run time field lv_end.
            subtract lv_start from lv_end.
            if lv_end >= ls_time-time.
              exit.
            endif.
          enddo.
          get run time field lv_start.
          do.
            add 1 to ls_time-reads.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_sort_u
              assigning <ls_long>
              with key key2 = lv_i1
                       key1 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data11 = sy-index.
            endif.
            get run time field lv_end.
            subtract lv_start from lv_end.
            if lv_end >= ls_time-time.
              exit.
            endif.
          enddo.
          get run time field lv_start.
          do fax times.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_sort_u
              assigning <ls_long>
              with table key key1 = lv_i1
                             key2 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data21 = sy-index.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-fax_b = lv_end - lv_start.
          get run time field lv_start.
          do fax times.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_sort_u
              assigning <ls_long>
              with key key2 = lv_i1
                       key1 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data21 = sy-index.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-fax_s = lv_end - lv_start.
          collect ls_time into lt_time.
          clear lt_hash_u.
          ls_time-what = 'HASH_U'.
          ls_time-size = lv_size.
          get run time field lv_start.
          do lv_size times.
            perform fill.
            insert ls_long into table lt_hash_u.
          enddo.
          get run time field lv_end.
          ls_time-time = lv_end - lv_start.
          ls_time-reads = 0.
          ls_time-readb = 0.
          ls_time-lines = lines( lt_hash_u ).
          get run time field lv_start.
          do.
            add 1 to ls_time-readb.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_hash_u
              assigning <ls_long>
              with table key key1 = lv_i1
                             key2 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data11 = sy-index.
            endif.
            get run time field lv_end.
            subtract lv_start from lv_end.
            if lv_end >= ls_time-time.
              exit.
            endif.
          enddo.
          get run time field lv_start.
          do.
            add 1 to ls_time-reads.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_hash_u
              assigning <ls_long>
              with key key2 = lv_i1
                       key1 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data11 = sy-index.
            endif.
            get run time field lv_end.
            subtract lv_start from lv_end.
            if lv_end >= ls_time-time.
              exit.
            endif.
          enddo.
          get run time field lv_start.
          do fax times.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_hash_u
              assigning <ls_long>
              with table key key1 = lv_i1
                             key2 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data21 = sy-index.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-fax_b = lv_end - lv_start.
          get run time field lv_start.
          do fax times.
            lv_i1 = lo_rnd1->get_next( ).
            lv_i2 = lo_rnd2->get_next( ).
            read table lt_hash_u
              assigning <ls_long>
              with key key2 = lv_i1
                       key1 = lv_i2.
            if sy-subrc = 0.
              <ls_long>-data21 = sy-index.
            endif.
          enddo.
          get run time field lv_end.
          ls_time-fax_s = lv_end - lv_start.
          collect ls_time into lt_time.
        endif.
      enddo.
    enddo.
    sort lt_time by what size.
    write: / ' type      | size   | time        | tab-size    | directread  | std read    | time direct | time std read'.
    write: / sy-uline.
    loop at lt_time into ls_time.
      write: / ls_time-what, '|', ls_time-size, '|', ls_time-time, '|', ls_time-lines, '|', ls_time-readb, '|', ls_time-reads, '|', ls_time-fax_b, '|', ls_time-fax_s.
    endloop.
    form fill.
      lv_i1 = lo_rnd1->get_next( ).
      lv_i2 = lo_rnd2->get_next( ).
      ls_long-key1 = lv_i1.
      ls_long-key2 = lv_i2.
      ls_long-data1 = lv_i1.
      ls_long-data2 = lv_i2.
      ls_long-data3 = lv_i1.
      ls_long-data4 = sy-datum + lv_i1.
      ls_long-data5 = lv_i1.
      ls_long-data6 = lv_i1.
      ls_long-data7 = lv_i1.
      ls_long-data8 = sy-datum + lv_i1.
      ls_long-data9 = lv_i1.
      ls_long-dataa = lv_i1.
      ls_long-datab = lv_i1.
      ls_long-datac = sy-datum + lv_i1.
      ls_long-datad = lv_i1.
      ls_long-datae = lv_i1.
      ls_long-dataf = lv_i1.
      ls_long-datag = sy-datum + lv_i1.
      ls_long-datah = lv_i1.
      ls_long-datai = lv_i1.
      ls_long-dataj = lv_i1.
      ls_long-datak = sy-datum + lv_i1.
      ls_long-datal = lv_i1.
      ls_long-datam = lv_i1.
      ls_long-datan = sy-datum + lv_i1.
      ls_long-datao = lv_i1.
      ls_long-datap = lv_i1.
      ls_long-dataq = lv_i1.
      ls_long-datar = sy-datum + lv_i1.
      ls_long-datas = lv_i1.
      ls_long-datat = lv_i1.
      ls_long-datau = lv_i1.
      ls_long-datav = sy-datum + lv_i1.
      ls_long-dataw = lv_i1.
      ls_long-datax = lv_i1.
      ls_long-datay = lv_i1.
      ls_long-dataz = sy-datum + lv_i1.
      ls_long-data11 = lv_i1.
      ls_long-data21 = lv_i1.
      ls_long-data31 = lv_i1.
      ls_long-data41 = sy-datum + lv_i1.
      ls_long-data51 = lv_i1.
      ls_long-data61 = lv_i1.
      ls_long-data71 = lv_i1.
      ls_long-data81 = sy-datum + lv_i1.
      ls_long-data91 = lv_i1.
      ls_long-dataa1 = lv_i1.
      ls_long-datab1 = lv_i1.
      ls_long-datac1 = sy-datum + lv_i1.
      ls_long-datad1 = lv_i1.
      ls_long-datae1 = lv_i1.
      ls_long-dataf1 = lv_i1.
      ls_long-datag1 = sy-datum + lv_i1.
      ls_long-datah1 = lv_i1.
      ls_long-datai1 = lv_i1.
      ls_long-dataj1 = lv_i1.
      ls_long-datak1 = sy-datum + lv_i1.
      ls_long-datal1 = lv_i1.
      ls_long-datam1 = lv_i1.
      ls_long-datan1 = sy-datum + lv_i1.
      ls_long-datao1 = lv_i1.
      ls_long-datap1 = lv_i1.
      ls_long-dataq1 = lv_i1.
      ls_long-datar1 = sy-datum + lv_i1.
      ls_long-datas1 = lv_i1.
      ls_long-datat1 = lv_i1.
      ls_long-datau1 = lv_i1.
      ls_long-datav1 = sy-datum + lv_i1.
      ls_long-dataw1 = lv_i1.
      ls_long-datax1 = lv_i1.
      ls_long-datay1 = lv_i1.
      ls_long-dataz1 = sy-datum + lv_i1.
    endform.".
    Thanks & Regards,
    YJR.

  • 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.

  • Actual difference between a standard , sorted and hashed atble

    hi ,
    1. what is the actual difference between a
       standard,sorted and hashed table ? and
    2. where and when these are actually used and applied ?
       provide explanation with an example ....

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

  • How do I use Get-ADUser to get just the Managers attribute? And then get rid of duplicates in my array/hash table?

    Hello,
          I am trying to just get the Managers of my users in Active Directory. I have gotten it down to the user and their manager, but I don't need the user. Here is my code so far:
    Get-ADUser-filter*-searchbase"OU=REDACTED,
    OU=Enterprise Users, DC=REDACTED, DC=REDACTED"-PropertiesManager|SelectName,@{N='Manager';E={(Get-ADUser$_.Manager).Name}}
    |export-csvc:\managers.csv-append 
    Also, I need to get rid of the duplicate values in my hash table. I tried playing around with -sort unique, but couldn't find a place it would work. Any help would be awesome.
    Thanks,
    Matt

    I would caution that, although it is not likely, managers can also be contact, group, or computer objects. If this is possible in your situation, use Get-ADObject in place of Get-ADUser inside the curly braces.
    Also, if you only want users that have a manager assigned, you can use -LDAPFilter "(manager=*)" in the first Get-ADUser.
    Finally, if you want all users that have been assigned the manager for at least one user, you can use:
    Get-ADUser
    -LDAPFilter "(directReports=*)" |
    Select @{N='Manager';E={ (Get-ADUser
    $_.sAMAccountName).Name }}
    -Unique | Sort Manager |
    Export-Csv .\managerList.csv -NoTypeInformation
    This works because when you assign the manager attribute of a user, this assigns the user to the directReports attribute of the manager. The directReports atttribute is multi-valued (an array in essence).
    Again, if managers can be groups or some other class of object (not likely), then use Get-ADObect throughout and identify by distinguishedName instead of sAMAccountName (since contacts don't have sAMAccountName).
    Richard Mueller - MVP Directory Services

  • Using JHS tables and hashing with salt algorithms for Weblogic security

    We are going to do our first enterprise ADF/JHeadstart application. For security part, we are going to do the following:
    1. We will use JHS tables as authentication for ADF security.
    2. We will use JAAS as authentication and Custom as authorization.
    2. We need to use JHeadStart security service screen in our application to manage users, roles and permission, instead of doing users/groups management within Weblogic.
    3. We will create new Weblogic SQL Authentication Provider.
    4. We will store salt with password in the database table.
    5. We will use Oracle MDS.
    There are some blogs online giving detail steps on how to create Weblogic SQL Authentication Provider and use JHS tables as authentication for ADF security. I am not sure about the implementation of hashing with salt algorithms, as ideally we'd like to use JHS security service screen in the application to manage users, roles and permission, not using Weblogic to do the users/groups management. We are going to try JMX client to interact with Weblogic API, looks like it is a flexiable approach. Does anybody have experience on working with JMX, SQL Authentication Provider and hashing with salt algorithms? Just want to make sure we are on the right track.
    Thanks,
    Sarah

    To be clear, we are planning on using a JMX client at the Entity level using custom JHS entitiy classes.
    BradW working with Sarah

  • Header, Line Item and Cache Techniques Using Hashed Tables

    Hi,
    How can I work with header, line item, and a cache techniques using hashed tables?
    Thanks,
    Shah.

    Hi,
    Here is an example to clarify the ideas:
    In general, every time you have a header-> lines structure you have a unique key for the lines that has at least header key plus one or more fields. I'll make use of this fact.
    I'll try to put an example of how to work with header -> line items and a cache technique using hashed tables.
    Just suppose that you need a list of all the material movements '101'-'901' for a certain range of dates in mkpf-budat. We'll extract these fields:
    mkpf-budat
    mkpf-mblnr,
    mseg-lifnr,
    lfa1-name1,
    mkpf-xblnr,
    mseg-zeile
    mseg-charg,
    mseg-matnr,
    makt-maktx,
    mseg-erfmg,
    mseg-erfme.
    I'll use two cache: one for maintaining lfa1 related data and the other to maintain makt related data. Also I'll only describe the data gathering part. The showing of the data is left to your own imagination.
    The main ideas are:
    1. As this is an example I won't use inner join. If properly desingned may be faster .
    2. I'll use four hashed tables: ht_mkpf, ht_mseg, ht_lfa1 and ht_makt to get data into memory. Then I'll collect all the data I want to list into a fifth table ht_lst.
    3. ht_mkpf should have (at least) mkpf's primary key fields : mjahr, mblnr.
    4. ht_mseg should have (at least) mseg primary key fields: mjahr mblnr and zeile.
    5. ht_lfa1 should have an unique key by lifnr.
    6. ht_makt should have an unique key by matnr.
    7. I prefer using with header line because makes the code easier to follow and understand. The waste of time isn't quite significant (in my experience at least).
    Note: When I've needed to work from header to item lines then I added a counter in ht_header that maintains the count of item lines, and I added an id in the ht_lines so I can read straight by key a given item line. But this is very tricky to implement and to follow. (Nevertheless I've programmed it and it works well.)
    The data will be read in this sequence:
    select data from mkpf into table ht_mkpf
    select data from mseg int table ht_mseg having in count all the data in ht_mkpf
    loop at ht_mseg (lines)
    filter unwanted records
    read cache for lfa1 and makt
    fill in ht_lst and collect data
    endloop.
    tables
    tables: mkpf, mseg, lfa1, makt.
    internal tables:
    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.
    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.
    data: begin of wa_makt,
    matnr like makt-matnr,
    maktx like makt-maktx,
    end of wa_makt.
    data: ht_makt like hashed table of wa_makt
    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_mseg,
    data: ht_lst like hashed table of wa_lst
    with unique key mblnr mjahr zeile
    with header line.
    data: g_lines type i.
    select-options: so_budat for mkpf-budat default sy-datum.
    select-options: so_matnr for mseg-matnr.
    form get_data.
    select mblnr mjahr budat xblnr
    into table ht_mkfp
    from mkpf
    where budat in so_budat.
    describe table ht_mkpf lines g_lines.
    if lines > 0.
    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_mjahr.
    endif.
    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_makt using ht_mseg-matnr changing ht_lst-maktx.
    insert table ht_lst.
    endloop.
    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 makt
    form read_makt using p_matnr changing p_maktx.
    read table ht_makt with table key matnr = p_matnr
    transporting maktx.
    if sy-subrc <> 0.
    ht_makt-matnr = p_matnr.
    select single maktx into ht_matk-maktx
    from makt
    where spras = sy-langu
    and matnr = p_matnr.
    if sy-subrc <> 0. ht_makt-maktx = 'n/a in makt'. endif.
    insert table ht_makt.
    endif.
    p_maktx = ht_makt-maktx.
    endform.
    Reward points if found helpfull...
    Cheers,
    Siva.

  • Creation of Sorted and Standard and Hashed Internal Tables ..

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

    Standard tables
    This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.
    Sorted tables
    This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.
    Hashed tables
    This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
    Special Features of Standard Tables
    Unlike sorted tables, hashed tables, and key access to internal tables, which were only introduced in Release 4.0, standard tables already existed several releases previously. Defining a line type, table type, and tables without a header line have only been possible since Release 3.0. For this reason, there are certain features of standard tables that still exist for compatibility reasons.
    Standard Tables Before Release 3.0
    Before Release 3.0, internal tables all had header lines and a flat-structured line type. There were no independent table types. You could only create a table object using the OCCURS addition in the DATA statement, followed by a declaration of a flat structure:
    DATA: BEGIN OF <itab> OCCURS <n>,
    <fi> ...
    END OF <itab>.
    This statement declared an internal table <itab> with the line type defined following the OCCURS addition. Furthermore, all internal tables had header lines.
    The number <n> in the OCCURS addition had the same meaning as in the INITIAL SIZE addition from Release 4.0. Entering ‘0’ had the same effect as omitting the INITIAL SIZE addition. In this case, the initial size of the table is determined by the system.
    The above statement is still possible in Release 4.0, and has roughly the same function as the following statements:
    TYPES: BEGIN OF <itab>,
    <fi> ...,
    END OF <itab>.
    DATA <itab> TYPE STANDARD TABLE OF <itab>
    WITH NON-UNIQUE DEFAULT KEY
    INITIAL SIZE <n>
    WITH HEADER LINE.
    In the original statement, no independent data type <itab> is created. Instead, the line type only exists as an attribute of the data object <itab>.
    Standard Tables From Release 3.0
    Since Release 3.0, it has been possible to create table types using
    TYPES <t> TYPE|LIKE <linetype> OCCURS <n>.
    and table objects using
    DATA <itab> TYPE|LIKE <linetype> OCCURS <n> WITH HEADER LINE.
    The effect of the OCCURS addition is to construct a standard table with the data type <linetype>. The line type can be any data type. The number <n> in the OCCURS addition has the same meaning as before Release 3.0. Before Release 4.0, the key of an internal table was always the default key, that is, all non-numeric fields that were not themselves internal tables.
    The above statements are still possible in Release 4.0, and have the same function as the following statements:
    TYPES|DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
    WITH NON-UNIQUE DEFAULT KEY
    INITIAL SIZE <n>
    WITH HEADER LINE.
    They can also be replaced by the following statements:
    Standard Tables From Release 4.0
    When you create a standard table, you can use the following forms of the TYPES and DATA statements. The addition INITIAL SIZE is also possible in all of the statements. The addition WITH HEADER LINE is possible in the DATA statement.
    Standard Table Types
    Generic Standard Table Type:
    TYPES <itab> TYPE|LIKE STANDARD TABLE OF <linetype>.
    The table key is not defined.
    Fully-Specified Standard Table Type:
    TYPES <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
    WITH NON-UNIQUE <key>.
    The key of a fully-specified standard table is always non-unique.
    Standard Table Objects
    Short Forms of the DATA Statement :
    DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>.
    DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
    WITH DEFAULT KEY.
    Both of these DATA statements are automatically completed by the system as follows:
    DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
    WITH NON-UNIQUE DEFAULT KEY.
    The purpose of the shortened forms of the DATA statement is to keep the declaration of standard tables, which are compatible with internal tables from previous releases, as simple as possible. When you declare a standard table with reference to the above type, the system automatically adopts the default key as the table key.
    Fully-Specified Standard Tables:
    DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
    WITH NON-UNIQUE <key>.
    The key of a standard table is always non-unique.
    Internal table objects
    Internal tables are dynamic variable data objects. Like all variables, you declare them using the DATA statement. You can also declare static internal tables in procedures using the STATICS statement, and static internal tables in classes using the CLASS-DATA statement. This description is restricted to the DATA statement. However, it applies equally to the STATICS and CLASS-DATA statements.
    Reference to Declared Internal Table Types
    Like all other data objects, you can declare internal table objects using the LIKE or TYPE addition of the DATA statement.
    DATA <itab> TYPE <type>|LIKE <obj> WITH HEADER LINE.
    Here, the LIKE addition refers to an existing table object in the same program. The TYPE addition can refer to an internal type in the program declared using the TYPES statement, or a table type in the ABAP Dictionary.
    You must ensure that you only refer to tables that are fully typed. Referring to generic table types (ANY TABLE, INDEX TABLE) or not specifying the key fully is not allowed (for exceptions, refer to Special Features of Standard Tables).
    The optional addition WITH HEADER line declares an extra data object with the same name and line type as the internal table. This data object is known as the header line of the internal table. You use it as a work area when working with the internal table (see Using the Header Line as a Work Area). When you use internal tables with header lines, you must remember that the header line and the body of the table have the same name. If you have an internal table with header line and you want to address the body of the table, you must indicate this by placing brackets after the table name (<itab>[]). Otherwise, ABAP interprets the name as the name of the header line and not of the body of the table. You can avoid this potential confusion by using internal tables without header lines. In particular, internal tables nested in structures or other internal tables must not have a header line, since this can lead to ambiguous expressions.
    TYPES VECTOR TYPE SORTED TABLE OF I WITH UNIQUE KEY TABLE LINE.
    DATA: ITAB TYPE VECTOR,
    JTAB LIKE ITAB WITH HEADER LINE.
    MOVE ITAB TO JTAB. <- Syntax error!
    MOVE ITAB TO JTAB[].
    The table object ITAB is created with reference to the table type VECTOR. The table object JTAB has the same data type as ITAB. JTAB also has a header line. In the first MOVE statement, JTAB addresses the header line. Since this has the data type I, and the table type of ITAB cannot be converted into an elementary type, the MOVE statement causes a syntax error. The second MOVE statement is correct, since both operands are table objects.
    plz reward if useful

  • 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

  • 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

  • Differences between Standard , sorted and hashed internal tables

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

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

Maybe you are looking for

  • CS5.5 hangs on file import

    I have been using PP for several versions and have never experienced any major issues until now.  At some point in the last few weeks (cannot link it to a recent PP update, but that may be the case) I have started having extreme problems when importi

  • BAPI/Function Module for CA02 - Change Routing

    Dear Experts, I have an requirement to do material assignment for an existing Group Number like we do manually with t-code CA02. Can anybody know any BAPI/FM that can do Material Assignment in CA02 transaction? Regards, Rick

  • QR Code reader issues

    I've been getting more and more business cards with qr codes on them. I bought a couple of different qr code reader apps, but none of them seem to work. In order to get the code large enough for the code reader to recognize it, I have to hold it so c

  • Invalid XML generated

    I thought I was figuring this stuff out, but I guess not. I've generated an xml instance using xmlBeans. When I check it with the validate() method, it comes back 'true' or valid. But if I run the Xerces sample app, counter, against it, I get the fol

  • Documentation of Geometry validity in Oracle Spatial?

    Is there anywhere in the 10g Spatial documentation where the geometric conditions required for a geometry to be valid are defined? I've found a few sentences spread through the document, but I would have expected that such an important concept would