Iterarator for hash table.

im having problems implementing an iterator for a hash table. I have an int value called pointer, which would move down the table. when i try to call next() it returns the very first element at index 0 in the hash table. then it moves until it finds a next element and returns it. The problem is that the cursor should be at an element position when i call next() and not at index 0 which is null.
public class myIterator implements Iterator
          public int pointer;
          public myIterator()
               pointer = 0;
               while(hasNext() && table[pointer] != null)
                    pointer++;
public boolean hasNext()
               //System.out.println(cursor);
                    //System.out.println(table.length);
                    /*if(cursor > table.length-1)
                         return false;
                    return true;
                         if(cursor >= table.length)
                         return false;
                    return true;
          * This method returns the next element, if any.
          * @return the next element.
          public Object next()
               Object temp = null;
               if(!hasNext())
throw new NoSuchElementException();
               else
                    System.out.println("cursor " + cursor);
                    temp = table[cursor];
                    cursor++;
                    if(hasNext())
                         while(table[cursor] == null)
                              cursor++;
                    return temp;
          }

You haven't even provided something with valid syntax - where is this "cursor" variable defined? And in one method you are using and incrementing something called "pointer", and somewhere else "cursor", so maybe you're mixing two different variables but trying to use them for the same purpose and they are out of sync.

Similar Messages

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

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

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

  • Select for a hashed table

    Hi All,
    This is a repost but this time Ill be specific.
    How do I select from a table into a hashed table faster without using "select distinct"? my primary concern is the speed of the select statement, and im afraid I cannot get rid of the hashed table destination.
    Thanks,
    Kenny

    HI Kenny,
    HASHED TABLE:
    There is no default setting for hashed tables. However, you must define a UNIQUE key. The NON-UNIQUE addition is not permitted.
    You cannot avoid this statement. May be the alternative is You have to use SORTED table with NON-UNIQUE option and then apply DELETE ADJACENT DUPLICATES, in this way you can have unique values for your itab.
    Regards,
    Raghav

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

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

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

  • System Variable For Internal table count

    Can anybody tell me what the system variable for internal table count?
    I just wants to know how many recoreds are there in my internal table ?
    Regards,
    pandu.

    Hi ,
    DESCRIBE TABLE <itab> [LINES <l>] [OCCURS <n>] [KIND <k>].
    If you use the LINES parameter, the number of filled lines is written to the variable <lin>. If parameter, the you use the OCCURS value of the INITIAL SIZE of the table is returned to the variable <n>. If you use the KIND parameter, the table type is returned to the variable <k>: ‘T’ for standard table, ‘S’ for sorted table, and ‘H’ for hashed table.
    using variable
    SY-TFILL
    After the statements DESCRIBE TABLE, LOOP AT, and READ TABLE, SY-TFILL contains the number of lines in the relevant internal table.
    http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3798358411d1829f0000e829fbfe/content.htm
    <REMOVED BY MODERATOR>
    Edited by: Alvaro Tejada Galindo on Feb 21, 2008 4:53 PM

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

  • 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

  • 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

  • SORTED & HASHED tables

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

    Internal tables are the core of ABAP. They are like soul of a body. For any program we use
    internal tables extensively. We can use Internal tables like normal data base tables only, but the
    basic difference is the memory allocated for internal tables is temporary. Once the program is
    closed the memory allocated for internal tables will also be out of memory.
    But while using the internal tables, there are many performance issues to be considered. i.e which
    type of internal table to be used for the program..like standard internal table, hashed internal
    table or sorted internal table etc..
    Internal tables
    Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by
    line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data
    objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables
    whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for
    storing and formatting data from a database table within a program. They are also a good way of including very complicated data
    structures in an ABAP program.
    Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract
    description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The
    data type is also an attribute of an existing data object.
    Internal Tables as Data Types
    Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type,
    key, and table type.
    Line type
    The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the
    structure is a column in the internal table. However, the line type may also be elementary or another internal table.
    Key
    The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify
    whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness
    depends on the table access method.
    If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves
    internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type
    is an internal table, the default key is empty.
    The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables
    with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember
    this, for example, if you intend to sort the table according to the key.
    Table type
    The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
    Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In
    this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access
    records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table.
    The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled
    very quickly, since the system does not have to check whether there are already existing entries.
    Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the
    table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system
    uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether
    the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
    Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of
    table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique.
    When you define the table, you must specify the key as UNIQUE.
    Generic Internal Tables
    Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a
    generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic
    internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data
    objects.
    Internal Tables as Dynamic Data Objects
    Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in
    respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects,
    since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are
    the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration)
    is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more
    than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The
    individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the
    internal table.
    Choosing a Table Type
    The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most
    frequently executed.
    Standard tables
    This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest
    possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by
    specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship
    with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in
    separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key
    access, the response time is logarithmically proportional to the number of table entries.
    Sorted tables
    This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries
    are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add
    them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always
    uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the
    table key in the WHERE condition.
    Hashed tables
    This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index.
    The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always
    have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for
    processing large amounts of data.
    Creating Internal Tables
    Like other elements in the ABAP type concept, you can declare internal tables as abstract data
    types in programs or in the ABAP Dictionary, and then use them to define data objects.
    Alternatively, you can define them directly as data objects. When you create an internal table as a
    data object, you should ensure that only the administration entry which belongs to an internal
    table is declared statically. The minimum size of an internal table is 256 bytes. This is important if an
    internal table occurs as a component of an aggregated data object, since even empty internal
    tables within tables can lead to high memory usage. (In the next functional release, the size of the
    table header for an initial table will be reduced to 8 bytes). Unlike all other ABAP data objects, you
    do not have to specify the memory required for an internal table. Table rows are added to and
    deleted from the table dynamically at runtime by the various statements for adding and deleting
    records.
    You can create internal tables in different types.
    You can create standard internal table and then make it sort in side the program.
    The same way you can change to hashed internal tables also.
    There will be some performance issues with regard to standard internal tables/ hashed internal
    tables/ sorted internal tables.
    Internal table types
    This section describes how to define internal tables locally in a program. You can also define internal tables globally as data types in the
    ABAP Dictionary.
    Like all local data types in programs , you define internal tables using the TYPES statement. If you do not refer to an existing table type
    using the TYPE or LIKE addition, you can use the TYPES statement to construct a new local internal table in your program.
    TYPES <t> TYPE|LIKE <tabkind> OF <linetype> [WITH <key>]
    [INITIAL SIZE <n>].
    After TYPE or LIKE, there is no reference to an existing data type. Instead, the type constructor occurs:
    <tabkind> OF <linetype> [WITH <key>]
    The type constructor defines the table type <tabkind>, the line type <linetype>, and the key <key> of the internal table <t>.
    You can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
    Table type
    You can specify the table type <tabkind> as follows:
    Generic table types
    INDEX TABLE
    For creating a generic table type with index access.
    ANY TABLE
    For creating a fully-generic table type.
    Data types defined using generic types can currently only be used for field symbols and for interface parameters in procedures . The generic
    type INDEX TABLE includes standard tables and sorted tables. These are the two table types for which index access is allowed. You cannot
    pass hashed tables to field symbols or interface parameters defined in this way. The generic type ANY TABLE can represent any table. You
    can pass tables of all three types to field symbols and interface parameters defined in this way. However, these field symbols and
    parameters will then only allow operations that are possible for all tables, that is, index operations are not allowed.
    Fully-Specified Table Types
    STANDARD TABLE or TABLE
    For creating standard tables.
    <b>SORTED TABLE</b>
    For creating sorted tables.
    <b>HASHED TABLE</b>
    For creating hashed tables.
    Fully-specified table types determine how the system will access the entries in the table in key operations. It uses a linear search for
    standard tables, a binary search for sorted tables, and a search using a hash algorithm for hashed tables.
    Line type
    For the line type <linetype>, you can specify:
    Any data type if you are using the TYPE addition. This can be a predefined ABAP type, a local type in the program, or a data type from the
    ABAP Dictionary. If you specify any of the generic elementary types C, N, P, or X, any attributes that you fail to specify (field length, number
    of decimal places) are automatically filled with the default values. You cannot specify any other generic types.
    Any data object recognized within the program at that point if you are using the LIKE addition. The line type adopts the fully-specified data
    type of the data object to which you refer. Except for within classes, you can still use the LIKE addition to refer to database tables and
    structures in the ABAP Dictionary (for compatibility reasons).
    All of the lines in the internal table have the fully-specified technical attributes of the specified data type.
    Key
    You can specify the key <key> of an internal table as follows:
    [UNIQUE|NON-UNIQUE] KEY <col1> ... <col n>
    In tables with a structured line type, all of the components <coli> belong to the key as long as they are not internal tables or references,
    and do not contain internal tables or references. Key fields can be nested structures. The substructures are expanded component by
    component when you access the table using the key. The system follows the sequence of the key fields.
    [UNIQUE|NON-UNIQUE] KEY TABLE LINE
    If a table has an elementary line type (C, D, F, I, N, P, T, X), you can define the entire line as the key. If you try this for a table whose line
    type is itself a table, a syntax error occurs. If a table has a structured line type, it is possible to specify the entire line as the key. However,
    you should remember that this is often not suitable.
    [UNIQUE|NON-UNIQUE] DEFAULT KEY
    This declares the fields of the default key as the key fields. If the table has a structured line type, the default key contains all non-numeric
    columns of the internal table that are not and do not contain references or internal tables. If the table has an elementary line type, the
    default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
    Specifying a key is optional. If you do not specify a key, the system defines a table type with an arbitrary key. You can only use this to
    define the types of field symbols and the interface parameters of procedures . For exceptions, refer to Special Features of Standard Tables.
    The optional additions UNIQUE or NON-UNIQUE determine whether the key is to be unique or non-unique, that is, whether the table can
    accept duplicate entries. If you do not specify UNIQUE or NON-UNIQUE for the key, the table type is generic in this respect. As such, it can
    only be used for specifying types. When you specify the table type simultaneously, you must note the following restrictions:
    You cannot use the UNIQUE addition for standard tables. The system always generates the NON-UNIQUE addition automatically.
    You must always specify the UNIQUE option when you create a hashed table.
    Initial Memory Requirement
    You can specify the initial amount of main memory assigned to an internal table object when you define the data type using the following
    addition:
    INITIAL SIZE <n>
    This size does not belong to the data type of the internal table, and does not affect the type check. You can use the above addition to
    reserve memory space for <n> table lines when you declare the table object.
    When this initial area is full, the system makes twice as much extra space available up to a limit of 8KB. Further memory areas of 12KB each
    are then allocated.
    You can usually leave it to the system to work out the initial memory requirement. The first time you fill the table, little memory is used. The
    space occupied, depending on the line width, is 16 <= <n> <= 100.
    It only makes sense to specify a concrete value of <n> if you can specify a precise number of table entries when you create the table and
    need to allocate exactly that amount of memory (exception: Appending table lines to ranked lists). This can be particularly important for
    deep-structured internal tables where the inner table only has a few entries (less than 5, for example).
    To avoid excessive requests for memory, large values of <n> are treated as follows: The largest possible value of <n> is 8KB divided by the
    length of the line. If you specify a larger value of <n>, the system calculates a new value so that n times the line width is around 12KB.
    Examples
    TYPES: BEGIN OF LINE,
    COLUMN1 TYPE I,
    COLUMN2 TYPE I,
    COLUMN3 TYPE I,
    END OF LINE.
    TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
    The program defines a table type ITAB. It is a sorted table, with line type of the structure LINE and a unique key of the component
    COLUMN1.
    TYPES VECTOR TYPE HASHED TABLE OF I WITH UNIQUE KEY TABLE LINE.
    TYPES: BEGIN OF LINE,
    COLUMN1 TYPE I,
    COLUMN2 TYPE I,
    COLUMN3 TYPE I,
    END OF LINE.
    TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
    TYPES: BEGIN OF DEEPLINE,
    FIELD TYPE C,
    TABLE1 TYPE VECTOR,
    TABLE2 TYPE ITAB,
    END OF DEEPLINE.
    TYPES DEEPTABLE TYPE STANDARD TABLE OF DEEPLINE
    WITH DEFAULT KEY.
    The program defines a table type VECTOR with type hashed table, the elementary line type I and a unique key of the entire table line. The
    second table type is the same as in the previous example. The structure DEEPLINE contains the internal table as a component. The table
    type DEEPTABLE has the line type DEEPLINE. Therefore, the elements of this internal table are themselves internal tables. The key is the
    default key - in this case the column FIELD. The key is non-unique, since the table is a standard table.
    Internal table objects
    Internal tables are dynamic variable data objects. Like all variables, you declare them using the DATA statement. You can also declare static
    internal tables in procedures using the STATICS statement, and static internal tables in classes using the CLASS-DATA statement. This
    description is restricted to the DATA statement. However, it applies equally to the STATICS and CLASS-DATA statements.
    Reference to Declared Internal Table Types
    Like all other data objects, you can declare internal table objects using the LIKE or TYPE addition of the DATA statement.
    DATA <itab> TYPE <type>|LIKE <obj> [WITH HEADER LINE].
    Here, the LIKE addition refers to an existing table object in the same program. The TYPE addition can refer to an internal type in the
    program declared using the TYPES statement, or a table type in the ABAP Dictionary.
    You must ensure that you only refer to tables that are fully typed. Referring to generic table types (ANY TABLE, INDEX TABLE) or not
    specifying the key fully is not allowed (for exceptions, refer to Special Features of Standard Tables).
    The optional addition WITH HEADER line declares an extra data object with the same name and line type as the internal table. This data
    object is known as the header line of the internal table. You use it as a work area when working with the internal table (see Using the
    Header Line as a Work Area). When you use internal tables with header lines, you must remember that the header line and the body of the
    table have the same name. If you have an internal table with header line and you want to address the body of the table, you must indicate
    this by placing brackets after the table name (<itab>[]). Otherwise, ABAP interprets the name as the name of the header line and not of the
    body of the table. You can avoid this potential confusion by using internal tables without header lines. In particular, internal tables nested
    in structures or other internal tables must not have a header line, since this can lead to ambiguous expressions.
    TYPES VECTOR TYPE SORTED TABLE OF I WITH UNIQUE KEY TABLE LINE.
    DATA: ITAB TYPE VECTOR,
    JTAB LIKE ITAB WITH HEADER LINE.
    MOVE ITAB TO JTAB. <- Syntax error!
    MOVE ITAB TO JTAB[].
    The table object ITAB is created with reference to the table type VECTOR. The table object JTAB has the same data type as ITAB. JTAB also
    has a header line. In the first MOVE statement, JTAB addresses the header line. Since this has the data type I, and the table type of ITAB
    cannot be converted into an elementary type, the MOVE statement causes a syntax error. The second MOVE statement is correct, since
    both operands are table objects.
    Declaring New Internal Tables
    You can use the DATA statement to construct new internal tables as well as using the LIKE or TYPE addition to refer to existing types or
    objects. The table type that you construct does not exist in its own right; instead, it is only an attribute of the table object. You can refer to
    it using the LIKE addition, but not using TYPE. The syntax for constructing a table object in the DATA statement is similar to that for defining
    a table type in the TYPES statement.
    DATA <itab> TYPE|LIKE <tabkind> OF <linetype> WITH <key>
    [INITIAL SIZE <n>]
    [WITH HEADER LINE].
    As when you define a table type , the type constructor
    <tabkind> OF <linetype> WITH <key>
    defines the table type <tabkind>, the line type <linekind>, and the key <key> of the internal table <itab>. Since the technical attributes of
    data objects are always fully specified, the table must be fully specified in the DATA statement. You cannot create generic table types (ANY
    TABLE, INDEX TABLE), only fully-typed tables (STANDARD TABLE, SORTED TABLE, HASHED TABLE). You must also specify the key and whether
    it is to be unique (for exceptions, refer to Special Features of Standard Tables).
    As in the TYPES statement, you can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
    You can create an internal table with a header line using the WITH HEADER LINE addition. The header line is created under the same
    conditions as apply when you refer to an existing table type.
    DATA ITAB TYPE HASHED TABLE OF SPFLI
    WITH UNIQUE KEY CARRID CONNID.
    The table object ITAB has the type hashed table, a line type corresponding to the flat structure SPFLI from the ABAP Dictionary, and a
    unique key with the key fields CARRID and CONNID. The internal table ITAB can be regarded as an internal template for the database table
    SPFLI. It is therefore particularly suitable for working with data from this database table as long as you only access it using the key.

  • Standard & hashed tables

    hello every one,
    This is rahul
    when we are declaring internal table by default it takes as standard  table
    but y don't we take hashed table they can get performance very well
    hashed can perform very well than standard na

    hI
    READ THIS POINTS
    Internal tables are the core of ABAP. They are like soul of a body. For any program we use
    internal tables extensively. We can use Internal tables like normal data base tables only, but the
    basic difference is the memory allocated for internal tables is temporary. Once the program is
    closed the memory allocated for internal tables will also be out of memory.
    But while using the internal tables, there are many performance issues to be considered. i.e which
    type of internal table to be used for the program..like standard internal table, hashed internal
    table or sorted internal table etc..
    Internal tables
    Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by
    line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data
    objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables
    whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for
    storing and formatting data from a database table within a program. They are also a good way of including very complicated data
    structures in an ABAP program.
    Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract
    description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The
    data type is also an attribute of an existing data object.
    Internal Tables as Data Types
    Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type,
    key, and table type.
    Line type
    The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the
    structure is a column in the internal table. However, the line type may also be elementary or another internal table.
    Key
    The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify
    whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness
    depends on the table access method.
    If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves
    internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type
    is an internal table, the default key is empty.
    The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables
    with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember
    this, for example, if you intend to sort the table according to the key.
    Table type
    The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
    Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In
    this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access
    records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table.
    The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled
    very quickly, since the system does not have to check whether there are already existing entries.
    Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the
    table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system
    uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether
    the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
    Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of
    table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique.
    When you define the table, you must specify the key as UNIQUE.
    Generic Internal Tables
    Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a
    generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic
    internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data
    objects.
    Internal Tables as Dynamic Data Objects
    Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in
    respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects,
    since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are
    the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration)
    is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more
    than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The
    individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the
    internal table.
    Choosing a Table Type
    The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most
    frequently executed.
    Standard tables
    This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest
    possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by
    specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship
    with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in
    separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key
    access, the response time is logarithmically proportional to the number of table entries.
    Sorted tables
    This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries
    are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add
    them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always
    uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the
    table key in the WHERE condition.
    Hashed tables
    This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index.
    The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always
    have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for
    processing large amounts of data.
    Creating Internal Tables
    Like other elements in the ABAP type concept, you can declare internal tables as abstract data
    types in programs or in the ABAP Dictionary, and then use them to define data objects.
    Alternatively, you can define them directly as data objects. When you create an internal table as a
    data object, you should ensure that only the administration entry which belongs to an internal
    table is declared statically. The minimum size of an internal table is 256 bytes. This is important if an
    internal table occurs as a component of an aggregated data object, since even empty internal
    tables within tables can lead to high memory usage. (In the next functional release, the size of the
    table header for an initial table will be reduced to 8 bytes). Unlike all other ABAP data objects, you
    do not have to specify the memory required for an internal table. Table rows are added to and
    deleted from the table dynamically at runtime by the various statements for adding and deleting
    records.
    You can create internal tables in different types.
    You can create standard internal table and then make it sort in side the program.
    The same way you can change to hashed internal tables also.
    There will be some performance issues with regard to standard internal tables/ hashed internal
    tables/ sorted internal tables.
    Internal table types
    This section describes how to define internal tables locally in a program. You can also define internal tables globally as data types in the
    ABAP Dictionary.
    Like all local data types in programs , you define internal tables using the TYPES statement. If you do not refer to an existing table type
    using the TYPE or LIKE addition, you can use the TYPES statement to construct a new local internal table in your program.
    TYPES <t> TYPE|LIKE <tabkind> OF <linetype> [WITH <key>]
    [INITIAL SIZE <n>].
    After TYPE or LIKE, there is no reference to an existing data type. Instead, the type constructor occurs:
    <tabkind> OF <linetype> [WITH <key>]
    The type constructor defines the table type <tabkind>, the line type <linetype>, and the key <key> of the internal table <t>.
    You can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
    Table type
    You can specify the table type <tabkind> as follows:
    Generic table types
    INDEX TABLE
    For creating a generic table type with index access.
    ANY TABLE
    For creating a fully-generic table type.
    Data types defined using generic types can currently only be used for field symbols and for interface parameters in procedures . The generic
    type INDEX TABLE includes standard tables and sorted tables. These are the two table types for which index access is allowed. You cannot
    pass hashed tables to field symbols or interface parameters defined in this way. The generic type ANY TABLE can represent any table. You
    can pass tables of all three types to field symbols and interface parameters defined in this way. However, these field symbols and
    parameters will then only allow operations that are possible for all tables, that is, index operations are not allowed.
    Fully-Specified Table Types
    STANDARD TABLE or TABLE
    For creating standard tables.
    SORTED TABLE
    For creating sorted tables.
    HASHED TABLE
    For creating hashed tables.
    Fully-specified table types determine how the system will access the entries in the table in key operations. It uses a linear search for
    standard tables, a binary search for sorted tables, and a search using a hash algorithm for hashed tables.
    Line type
    For the line type <linetype>, you can specify:
    Any data type if you are using the TYPE addition. This can be a predefined ABAP type, a local type in the program, or a data type from the
    ABAP Dictionary. If you specify any of the generic elementary types C, N, P, or X, any attributes that you fail to specify (field length, number
    of decimal places) are automatically filled with the default values. You cannot specify any other generic types.
    Any data object recognized within the program at that point if you are using the LIKE addition. The line type adopts the fully-specified data
    type of the data object to which you refer. Except for within classes, you can still use the LIKE addition to refer to database tables and
    structures in the ABAP Dictionary (for compatibility reasons).
    All of the lines in the internal table have the fully-specified technical attributes of the specified data type.
    Key
    You can specify the key <key> of an internal table as follows:
    [UNIQUE|NON-UNIQUE] KEY <col1> ... <col n>
    In tables with a structured line type, all of the components <coli> belong to the key as long as they are not internal tables or references,
    and do not contain internal tables or references. Key fields can be nested structures. The substructures are expanded component by
    component when you access the table using the key. The system follows the sequence of the key fields.
    [UNIQUE|NON-UNIQUE] KEY TABLE LINE
    If a table has an elementary line type (C, D, F, I, N, P, T, X), you can define the entire line as the key. If you try this for a table whose line
    type is itself a table, a syntax error occurs. If a table has a structured line type, it is possible to specify the entire line as the key. However,
    you should remember that this is often not suitable.
    [UNIQUE|NON-UNIQUE] DEFAULT KEY
    This declares the fields of the default key as the key fields. If the table has a structured line type, the default key contains all non-numeric
    columns of the internal table that are not and do not contain references or internal tables. If the table has an elementary line type, the
    default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
    Specifying a key is optional. If you do not specify a key, the system defines a table type with an arbitrary key. You can only use this to
    define the types of field symbols and the interface parameters of procedures . For exceptions, refer to Special Features of Standard Tables.
    The optional additions UNIQUE or NON-UNIQUE determine whether the key is to be unique or non-unique, that is, whether the table can
    accept duplicate entries. If you do not specify UNIQUE or NON-UNIQUE for the key, the table type is generic in this respect. As such, it can
    only be used for specifying types. When you specify the table type simultaneously, you must note the following restrictions:
    You cannot use the UNIQUE addition for standard tables. The system always generates the NON-UNIQUE addition automatically.
    You must always specify the UNIQUE option when you create a hashed table.
    Initial Memory Requirement
    You can specify the initial amount of main memory assigned to an internal table object when you define the data type using the following
    addition:
    INITIAL SIZE <n>
    This size does not belong to the data type of the internal table, and does not affect the type check. You can use the above addition to
    reserve memory space for <n> table lines when you declare the table object.
    When this initial area is full, the system makes twice as much extra space available up to a limit of 8KB. Further memory areas of 12KB each
    are then allocated.
    You can usually leave it to the system to work out the initial memory requirement. The first time you fill the table, little memory is used. The
    space occupied, depending on the line width, is 16 <= <n> <= 100.
    It only makes sense to specify a concrete value of <n> if you can specify a precise number of table entries when you create the table and
    need to allocate exactly that amount of memory (exception: Appending table lines to ranked lists). This can be particularly important for
    deep-structured internal tables where the inner table only has a few entries (less than 5, for example).
    To avoid excessive requests for memory, large values of <n> are treated as follows: The largest possible value of <n> is 8KB divided by the
    length of the line. If you specify a larger value of <n>, the system calculates a new value so that n times the line width is around 12KB.
    Examples
    TYPES: BEGIN OF LINE,
    COLUMN1 TYPE I,
    COLUMN2 TYPE I,
    COLUMN3 TYPE I,
    END OF LINE.
    TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
    The program defines a table type ITAB. It is a sorted table, with line type of the structure LINE and a unique key of the component
    COLUMN1.
    TYPES VECTOR TYPE HASHED TABLE OF I WITH UNIQUE KEY TABLE LINE.
    TYPES: BEGIN OF LINE,
    COLUMN1 TYPE I,
    COLUMN2 TYPE I,
    COLUMN3 TYPE I,
    END OF LINE.
    TYPES ITAB TYPE SORTED TABLE OF LINE WITH UNIQUE KEY COLUMN1.
    TYPES: BEGIN OF DEEPLINE,
    FIELD TYPE C,
    TABLE1 TYPE VECTOR,
    TABLE2 TYPE ITAB,
    END OF DEEPLINE.
    TYPES DEEPTABLE TYPE STANDARD TABLE OF DEEPLINE
    WITH DEFAULT KEY.
    The program defines a table type VECTOR with type hashed table, the elementary line type I and a unique key of the entire table line. The
    second table type is the same as in the previous example. The structure DEEPLINE contains the internal table as a component. The table
    type DEEPTABLE has the line type DEEPLINE. Therefore, the elements of this internal table are themselves internal tables. The key is the
    default key - in this case the column FIELD. The key is non-unique, since the table is a standard table.
    Internal table objects
    Internal tables are dynamic variable data objects. Like all variables, you declare them using the DATA statement. You can also declare static
    internal tables in procedures using the STATICS statement, and static internal tables in classes using the CLASS-DATA statement. This
    description is restricted to the DATA statement. However, it applies equally to the STATICS and CLASS-DATA statements.
    Reference to Declared Internal Table Types
    Like all other data objects, you can declare internal table objects using the LIKE or TYPE addition of the DATA statement.
    DATA <itab> TYPE <type>|LIKE <obj> [WITH HEADER LINE].
    Here, the LIKE addition refers to an existing table object in the same program. The TYPE addition can refer to an internal type in the
    program declared using the TYPES statement, or a table type in the ABAP Dictionary.
    You must ensure that you only refer to tables that are fully typed. Referring to generic table types (ANY TABLE, INDEX TABLE) or not
    specifying the key fully is not allowed (for exceptions, refer to Special Features of Standard Tables).
    The optional addition WITH HEADER line declares an extra data object with the same name and line type as the internal table. This data
    object is known as the header line of the internal table. You use it as a work area when working with the internal table (see Using the
    Header Line as a Work Area). When you use internal tables with header lines, you must remember that the header line and the body of the
    table have the same name. If you have an internal table with header line and you want to address the body of the table, you must indicate
    this by placing brackets after the table name (<itab>[]). Otherwise, ABAP interprets the name as the name of the header line and not of the
    body of the table. You can avoid this potential confusion by using internal tables without header lines. In particular, internal tables nested
    in structures or other internal tables must not have a header line, since this can lead to ambiguous expressions.
    TYPES VECTOR TYPE SORTED TABLE OF I WITH UNIQUE KEY TABLE LINE.
    DATA: ITAB TYPE VECTOR,
    JTAB LIKE ITAB WITH HEADER LINE.
    MOVE ITAB TO JTAB. <- Syntax error!
    MOVE ITAB TO JTAB[].
    The table object ITAB is created with reference to the table type VECTOR. The table object JTAB has the same data type as ITAB. JTAB also
    has a header line. In the first MOVE statement, JTAB addresses the header line. Since this has the data type I, and the table type of ITAB
    cannot be converted into an elementary type, the MOVE statement causes a syntax error. The second MOVE statement is correct, since
    both operands are table objects.
    Declaring New Internal Tables
    You can use the DATA statement to construct new internal tables as well as using the LIKE or TYPE addition to refer to existing types or
    objects. The table type that you construct does not exist in its own right; instead, it is only an attribute of the table object. You can refer to
    it using the LIKE addition, but not using TYPE. The syntax for constructing a table object in the DATA statement is similar to that for defining
    a table type in the TYPES statement.
    DATA <itab> TYPE|LIKE <tabkind> OF <linetype> WITH <key>
    [INITIAL SIZE <n>]
    [WITH HEADER LINE].
    As when you define a table type , the type constructor
    <tabkind> OF <linetype> WITH <key>
    defines the table type <tabkind>, the line type <linekind>, and the key <key> of the internal table <itab>. Since the technical attributes of
    data objects are always fully specified, the table must be fully specified in the DATA statement. You cannot create generic table types (ANY
    TABLE, INDEX TABLE), only fully-typed tables (STANDARD TABLE, SORTED TABLE, HASHED TABLE). You must also specify the key and whether
    it is to be unique (for exceptions, refer to Special Features of Standard Tables).
    As in the TYPES statement, you can, if you wish, allocate an initial amount of memory to the internal table using the INITIAL SIZE addition.
    You can create an internal table with a header line using the WITH HEADER LINE addition. The header line is created under the same
    conditions as apply when you refer to an existing table type.
    DATA ITAB TYPE HASHED TABLE OF SPFLI
    WITH UNIQUE KEY CARRID CONNID.
    The table object ITAB has the type hashed table, a line type corresponding to the flat structure SPFLI from the ABAP Dictionary, and a
    unique key with the key fields CARRID and CONNID. The internal table ITAB can be regarded as an internal template for the database table
    SPFLI. It is therefore particularly suitable for working with data from this database table as long as you only access it using the key.

  • Producing a string of 3 random letters for a hash table

    I'm pretty new to all this and i was wondering if anyone would be able to help me produce a random string of 3 letters to be inputted into a hash table. I already have the code for integers to be placed into the table but am having difficulty with letters. I've tried using the Random() function but am probably putting it into the wrong place.
    I will place the code underneath so you can all have a look at it.
    Any help would be greatly appreciated.
    Thanks in advance
    Code:
    class HashTable
    private DataItem[] hashArray; // array holds hash table
    private int arraySize;
    private DataItem nonItem; // for deleted items
    public HashTable(int size) // constructor
    arraySize = size;
    hashArray = new DataItem[arraySize];
    nonItem = new DataItem(-1); // deleted item key is -1
    public void displayTable()
    System.out.print("Table: ");
    for(int j=0; j<arraySize; j++)
    if(hashArray[j] != null)
    System.out.print(hashArray[j].getKey() + " ");
    else
    System.out.print("** ");
    System.out.println("");
    public int hashFunc(int key)
    return key % arraySize; // hash function
    public void insert(DataItem item) // insert a DataItem
    // (assumes table not full)
    int key = item.getKey(); // extract key
    int hashVal = hashFunc(key); // hash the key
    // until empty cell or -1,
    while(hashArray[hashVal] != null &&
    hashArray[hashVal].getKey() != -1)
    ++hashVal; // go to next cell
    hashVal %= arraySize; // wraparound if necessary
    hashArray[hashVal] = item; // insert item
    } // end insert()
    public DataItem delete(int key) // delete a DataItem
    int hashVal = hashFunc(key); // hash the key
    while(hashArray[hashVal] != null) // until empty cell,
    {                               // found the key?
    if(hashArray[hashVal].getKey() == key)
    DataItem temp = hashArray[hashVal]; // save item
    hashArray[hashVal] = nonItem; // delete item
    return temp; // return item
    ++hashVal; // go to next cell
    hashVal %= arraySize; // wraparound if necessary
    return null; // can't find item
    } // end delete()
    public DataItem find(int key) // find item with key
    int hashVal = hashFunc(key); // hash the key
    while(hashArray[hashVal] != null) // until empty cell,
    {                               // found the key?
    if(hashArray[hashVal].getKey() == key)
    return hashArray[hashVal]; // yes, return item
    ++hashVal; // go to next cell
    hashVal %= arraySize; // wraparound if necessary
    return null; // can't find item
    } // end class HashTable
    class HashTableApp
    public static void main(String[] args) throws IOException
    DataItem aDataItem;
    int aKey, size, n, keysPerCell;
    // get sizes
    System.out.print("Enter size of hash table: ");
    size = getInt();
    System.out.print("Enter initial number of items: ");
    n = getInt();
    keysPerCell = 10;
    // make table
    HashTable theHashTable = new HashTable(size);
    for(int j=0; j<n; j++) // insert data
    aKey = (int)(java.lang.Math.random() *
    keysPerCell * size);
    aDataItem = new DataItem(aKey);
    theHashTable.insert(aDataItem);
    while(true) // interact with user
    System.out.print("Enter first letter of ");
    System.out.print("show, insert, delete, or find: ");
    char choice = getChar();
    switch(choice)
    case 's':
    theHashTable.displayTable();
    break;
    case 'i':
    System.out.print("Enter key value to insert: ");
    aKey = getInt();
    aDataItem = new DataItem(aKey);
    theHashTable.insert(aDataItem);
    break;
    case 'd':
    System.out.print("Enter key value to delete: ");
    aKey = getInt();
    theHashTable.delete(aKey);
    break;
    case 'f':
    System.out.print("Enter key value to find: ");
    aKey = getInt();
    aDataItem = theHashTable.find(aKey);
    if(aDataItem != null)
    System.out.println("Found " + aKey);
    else
    System.out.println("Could not find " + aKey);
    break;
    default:
    System.out.print("Invalid entry\n");
    } // end switch
    } // end while
    } // end main()
    public static String getString() throws IOException
    InputStreamReader isr = new InputStreamReader(System.in);
    BufferedReader br = new BufferedReader(isr);
    String s = br.readLine();
    return s;
    public static char getChar() throws IOException
    String s = getString();
    return s.charAt(0);
    public static int getInt() throws IOException
    String s = getString();
    return Integer.parseInt(s);
    } // end class HashTableApp

    public class Foo {
        private java.util.Random rand = new Random();
        public static void main(String[] args) throws Exception {
            new Foo().go();
        void go() throws Exception {
            String allowedChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
            System.out.println(getRandomString(allowedChars, 3));               
        String getRandomString(String allowedChars, int length) {
            StringBuffer buf = new StringBuffer();
            int charCount = allowedChars.length();
            for (int count = 0; count < length; count++) {
                int index = rand.nextInt(charCount);
                buf.append(allowedChars.charAt(index));
            return buf.toString();
    }

  • Displaying graphical representation of data in hash tables as bar chart?

    I want to be able to display results in my hash table as a bar chart i don't know how to do it could someone help me I've looked through tutorials couldn't find any information that actually helped.
    In my program it doesnt allow matching the capital and small letters
    so for instance if I already have Mike it allows for me to input mike in again so there are 2 Mikes.
    I also want to do a simple user interface the tutorial for it is not simple to understand could any one tell me how to create a simple user interface like putting a button into a place wher i want it to be.
    im not asking anyone to do it for me i just want people to show me how to do it
    thank you
    Edited by: Tek_Hedef on Dec 1, 2007 4:30 AM

    Thanks for the ideas pal but I did have a go at it but my bit of code is making it crash but i removed it now so here's what I have so far
    import java.io.*;
    import java.util.*;
    import java.awt.*;
    import java.awt.event.*;
    import javax.swing.*;
    import javax.swing.event.*;
    class StudentDetails extends JFrame implements ActionListener
         private JTextField StudentNameTxt, StudentMarkTxt;
        private JButton DeleteStudentDetailsBtn, DisplayAllStudentsBtn, SearchStudentBtn, FailedStudentsBtn, PassedStudentsBtn, DistinctionStudentsBtn, AddStudentDetailsBtn, ExitBtn;
        private JPanel DisplayStudentDetailsPnl;
        private JLabel StudentNameLbl, StudentMarkLbl;
        private JTextArea DisplayResultsTxt;
        private Hashtable StudentDetailsTbl;
        private String StudentName, StudentMark;
        public static void main(String[] args)
            StudentDetails frame = new StudentDetails();
             frame.setSize(600,600);
            frame.createGUI();
            frame.setVisible(true);
        public void display(JPanel DisplayStudentDetailsPnl)
            Graphics paper = DisplayStudentDetailsPnl.getGraphics();
            paper.setColor(Color.white);
            paper.fillRect(0, 0, 500, 500);
            paper.setColor(new Color((int)(Math.random()*255),(int)(Math.random()*255),(int)(Math.random()*255) ));
        private void createGUI()
            setDefaultCloseOperation(EXIT_ON_CLOSE);
            Container window = getContentPane();
            window.setLayout(new FlowLayout());
            StudentDetailsTbl = new Hashtable();
            StudentNameLbl = new JLabel("Student Name");
            window.add(StudentNameLbl);
            StudentNameTxt = new JTextField(15);
            window.add(StudentNameTxt);
            StudentMarkLbl = new JLabel("Student Mark");
            window.add(StudentMarkLbl);
            StudentMarkTxt = new JTextField(3);
            window.add(StudentMarkTxt);
            AddStudentDetailsBtn = new JButton("Add Student and Mark");
            window.add(AddStudentDetailsBtn);
            AddStudentDetailsBtn.addActionListener(this);
            DeleteStudentDetailsBtn = new JButton("Delete Student");
            window.add(DeleteStudentDetailsBtn);
            DeleteStudentDetailsBtn.addActionListener(this);
            DisplayAllStudentsBtn = new JButton("Display all Students and Marks");
            window.add(DisplayAllStudentsBtn);
            DisplayAllStudentsBtn.addActionListener(this);
            SearchStudentBtn = new JButton("Search Student");
            window.add(SearchStudentBtn);
            SearchStudentBtn.addActionListener(this);
            FailedStudentsBtn = new JButton("Students which Failed");
            window.add(FailedStudentsBtn);
            FailedStudentsBtn.addActionListener(this);
            PassedStudentsBtn = new JButton("Students which Passed");
            window.add(PassedStudentsBtn);
            PassedStudentsBtn.addActionListener(this);
            DistinctionStudentsBtn = new JButton("Students with Distinction");
            window.add(DistinctionStudentsBtn);
            DistinctionStudentsBtn.addActionListener(this);
            ExitBtn = new JButton("Exit");
            window.add(ExitBtn);
            ExitBtn.addActionListener(this);
            DisplayResultsTxt = new JTextArea();
            DisplayResultsTxt.setPreferredSize(new Dimension(200, 200));
            DisplayResultsTxt.setBackground(Color.white);
            window.add(DisplayResultsTxt);
            DisplayResultsTxt.enable(false);
        public void actionPerformed (ActionEvent e)
             if (e.getSource()== AddStudentDetailsBtn)
                  StudentName = StudentNameTxt.getText();
                   StudentMark = StudentMarkTxt.getText();
                  DisplayResultsTxt.setText("");
                  StudentDetailsTbl.put(StudentName, StudentMark);
                Enumeration enumStudentName = StudentDetailsTbl.keys();
                Enumeration enumStudentMark = StudentDetailsTbl.elements();
                String[] keys = (String[]) StudentDetailsTbl.keySet().toArray(new String[0]);       
                Arrays.sort(keys); 
                    for (String key : keys)
                         DisplayResultsTxt.append(key + " : " + StudentDetailsTbl.get(key)+ "\n");
                    StudentNameTxt.setText("");
                    StudentMarkTxt.setText("");
             if (e.getSource() == DeleteStudentDetailsBtn )
             if (StudentDetailsTbl.containsKey(StudentNameTxt.getText().trim()))
                  DisplayResultsTxt.setText("");     
                  String txt = StudentNameTxt.getText();
                Enumeration enumStudentName = StudentDetailsTbl.keys()  ;                   
                    String currentelement = (String)enumStudentName.nextElement();
                     StudentDetailsTbl.remove(txt);
                     DisplayResultsTxt.append(txt + " has been deleted");  
            if (e.getSource() == SearchStudentBtn)
            if (StudentDetailsTbl.containsKey(StudentNameTxt.getText().trim()))
                 String txt = StudentNameTxt.getText();
                 String result;
                 DisplayResultsTxt.setText("");
                 Enumeration enumStudentName = StudentDetailsTbl.keys();
                Enumeration enumStudentMark = StudentDetailsTbl.elements();
                   while (enumStudentName.hasMoreElements())
                        String currentelement = (String)enumStudentName.nextElement();
                    result = (StudentDetailsTbl.get(currentelement).toString());
                        if (txt.equals(currentelement))
                             DisplayResultsTxt.append(currentelement + " " + result);
                        else JOptionPane.showMessageDialog(null, "Student Name could not be identified");
            if (e.getSource() == DisplayAllStudentsBtn)
                  DisplayResultsTxt.setText("");
                 Enumeration enumStudentName = StudentDetailsTbl.keys();
                Enumeration enumStudentMark = StudentDetailsTbl.elements();
                while (enumStudentName.hasMoreElements())
                DisplayResultsTxt.append(enumStudentName.nextElement()+ " " + enumStudentMark.nextElement()+ "\n");
            if (e.getSource() == PassedStudentsBtn)
                 DisplayResultsTxt.setText("");
                 Enumeration enumStudentName = StudentDetailsTbl.keys();
                Enumeration enumStudentMark = StudentDetailsTbl.elements();
                while (enumStudentName.hasMoreElements())
                     int Mark = Integer.parseInt((String)enumStudentMark.nextElement());
                     String Name = (String)enumStudentName.nextElement();
                     if (Mark >=40)
                          DisplayResultsTxt.append(Name + " " + Mark + "\n");
            if (e.getSource() == FailedStudentsBtn)
                 DisplayResultsTxt.setText("");
                 Enumeration enumStudentName = StudentDetailsTbl.keys();
                Enumeration enumStudentMark = StudentDetailsTbl.elements();
                while (enumStudentName.hasMoreElements())
                     int Mark = Integer.parseInt((String)enumStudentMark.nextElement());
                     String Name = (String)enumStudentName.nextElement();
                     if (Mark <40)
                          DisplayResultsTxt.append(Name + " " + Mark + "\n");
            if (e.getSource() == DistinctionStudentsBtn)
                 DisplayResultsTxt.setText("");
                 Enumeration enumStudentName = StudentDetailsTbl.keys();
                Enumeration enumStudentMark = StudentDetailsTbl.elements();
                while (enumStudentName.hasMoreElements())
                     int Mark = Integer.parseInt((String)enumStudentMark.nextElement());
                     String Name = (String)enumStudentName.nextElement();
                     if (Mark >=75)
                          DisplayResultsTxt.append(Name + " " + Mark + "\n");
    }

  • 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

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

Maybe you are looking for