hashed table

[Former Member]

hi Abaper !

Iam having doubt regarding internal table.

can we insert data into hashed table & sorted table ?

can any one give with examples of those

particularly hashed ?

Thanks & Regards,

Rajesh.

[Former Member]

hi,

Sorted tables. In a sorted table, the system automatically stores the entries and inserts new entries

sorted by the table key. The system uses a binary search on the table when you access it using the key.

You can specify the key of a sorted table as unique. You will often use the key to access a sorted table,

but it is also possible to use the index. Standard tables and sorted tables are generically known as

index tables.

Hashed tables. You can only access a hashed table using the key. There are certain conditions under

which you can considerably reduce the access times to large tables by using a hashed table. The key of

a hashed table must always be unique.

You do not have to specify the access type fully. You can either omit it altogether, or specify it partially

(index table). The table type is then generic, and, by omitting certain attributes, we can use it to specify

the types of interface parameters.

Data records are not inserted into the table in a sorted order. As with standard tables, you can sort hashed

tables using the SORT statement

INSERT <wa> INTO TABLE <itab>.

A unique key is only possible with sorted and hashed tables.

DATA: BEGIN OF LINE,
COL1 TYPE I,
COL2 TYPE I,
END OF LINE.

DATA: ITAB LIKE STANDARD TABLE OF LINE,
      JTAB LIKE SORTED TABLE OF LINE
           WITH NON-UNIQUE KEY COL1 COL2.

DO 3 TIMES.
  LINE-COL1 = SY-INDEX. LINE-COL2 = SY-INDEX ** 2.
  APPEND LINE TO ITAB.
  LINE-COL1 = SY-INDEX. LINE-COL2 = SY-INDEX ** 3.
  APPEND LINE TO JTAB.
ENDDO.

INSERT LINES OF ITAB INTO TABLE JTAB.

LOOP AT JTAB INTO LINE.
  WRITE: / SY-TABIX, LINE-COL1, LINE-COL2.
ENDLOOP.

The output is: :

         1         1          1
         2         1          1
         3         2          4
         4         2          8
         5         3          9
         6         3         27

The example creates two internal tables with the same line type but different table types. Each is filled with three lines. Then, ITAB is sorted into the sorted table JTAB. 

Hope this helps, Do reward.

Edited by: Runal Singh on Apr 8, 2008 12:36 PM

[Former Member]

Hi,

• Standard tables

The line is appended to the end of the internal table. This has the same effect as the explicit APPEND statement.

• Sorted tables

The line is inserted into the table according to the table key. If the key is non-unique, duplicates are inserted above the existing entry with the same key. The runtime for the operation increases logarithmically with the number of existing table entries.

• Hashed tables

The table is inserted into the internal hash administration according to the table key.

rgds,

bharat.

[Former Member]

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.

Let us start by having a look at the relevant data definitions we need:

1 REPORT y_fill_account_table.

2 * internal tables and work areas for database tables.

3 DATA: wa_acc TYPE yaccount,

4 itab_acc LIKE HASHED TABLE OF yaccount

5 WITH UNIQUE KEY mandt acc_num bank city,

6 wa_bank TYPE ybank,

7 itab_bank LIKE STANDARD TABLE OF ybank,

8 wa_city TYPE ycity,

9 itab_city LIKE STANDARD TABLE OF ycity,

10 wa_scustom TYPE scustom,

11 itab_scustom LIKE STANDARD TABLE OF scustom,

12 z TYPE i.

13 * References to different objects of class cl_abap_random_int

14 * and counter for the number of lines of the itabs.

15 DATA: rnd_bank TYPE REF TO cl_abap_random_int,

16 rnd_city LIKE rnd_bank,

17 rnd_scust LIKE rnd_bank,

18 rnd_cat LIKE rnd_bank,

19 rnd_account LIKE rnd_bank,

20 rnd_balance LIKE rnd_bank,

21 bank_count TYPE i,

22 city_count TYPE i,

23 scust_count TYPE i,

24 cat_count TYPE i VALUE 3,

25 max_start_balance type i value 45000,

26 cat_high type i value 3.

27 * How many datasets to create

28 PARAMETERS: numb_acc TYPE i DEFAULT 10.

First of all, there is the definition of an internal table that should hold the data for the database table YACCOUNT in line 4 and 5 plus the work area of the relevant line type in line 3. A hashed table is a table that is by a hash algorithm. There is no table index. The position of a row in the memory is calculated by specifying a key using a hash function that provides a unique value for each table row. If you want to read a dataset from a large hashed table this is faster by degrees than a search in a standard or a sorted table. In fact the time you need for a search in a hashed table increases logarithmically with the number of entries in the internal table. It is because of this advantage that we choose this type of internal table for our program. Later we have to check if the key of a new dataset we have created randomly is unique. To do this we have to search if the key of this dataset does already exist in the internal table itab_acc.

We need internal tables and work areas for all check tables of the table YACCOUNT as the random values should be take from these tables (lines 6 to 11). As these tables are not very large and only accessed by index, a standard table suffices. Again you see how easy it is in ABAP to define an internal table that has the same type as a database table. The references in the lines 15 to 20 are used for objects created by a factory method of the class cl_abap_random_int. The PARAMETERS statement enables the user to choose how many datasets should be created. I do not think I need to explain the definition of the integers.

The next lines do some more preparatory work:

29 DELETE FROM yaccount. "delete all lines from the db table yaccount

30 * Fill internal table from relevant db table

31 * and get the number of lines.

32 SELECT * FROM ybank INTO TABLE itab_bank.

33 bank_count = LINES( itab_bank ).

34 SELECT * FROM ycity INTO TABLE itab_city.

35 city_count = LINES( itab_city ).

36 SELECT * FROM scustom INTO TABLE itab_scustom.

37 scust_count = LINES( itab_scustom ).

38 * Get objects that have a method to create a

39 * random number between min and max.

40 *for account categories

41 rnd_cat = cl_abap_random_int=>create( min = 1 max = cat_high ). "

42 * for number of banks

43 rnd_bank = cl_abap_random_int=>create( min = 1 max = bank_count ).

44 * for number of customers

45 rnd_scust = cl_abap_random_int=>create( min = 1 max = scust_count ).

46 * for number of cities

47 rnd_city = cl_abap_random_int=>create( min = 1 max = city_count ).

48 * for account number which has 8 digits

49 rnd_account = cl_abap_random_int=>create( min = 10000000

50 max = 99999999 ).

51 * for initial balance

52 rnd_balance = cl_abap_random_int=>create( min = 0

53 max = max_start_balance ).

In line 29 we delete all lines from the database table YACCOUNT and from line 32 to 37 we load the content of the database tables YBANK, YCITY and SCUSTOM in the relevant internal tables and get the respective number of entries in each internal table. In line 41 we create an object that produces random number between one and the number of categories. This is done by a public static factory method of the global class cl_abap_random: Public components of global classes are available in the whole system. In ABAP it is quite common to provide services as methods of global classes. Surely you remember the object oriented way to output a table also uses a method of a global class (cf. tip 10 of our series).

In the same way we create random-integer-producer-objects for the three check tables (lines 43 to 47), the account number and the initial balance of each account.

Next we create the random entries in a way that assures that the syntactic and semantic constraints are met:

54 DO numb_acc TIMES.

55 z = rnd_bank->get_next( ). " Get random number

56 READ TABLE itab_bank INDEX z INTO wa_acc-bank. "Get a bank randomly

57 z = rnd_city->get_next( ).

58 READ TABLE itab_city INDEX z INTO wa_city. "Get dataset from ycity

59 wa_acc-city = wa_city-city. "randomly

60 wa_acc-currency = wa_city-currency. "Currency depends on the city

61 DO. "get an account number that is unique for bank and city

62 z = rnd_account->get_next( ).

63 wa_acc-acc_num = z.

64 READ TABLE itab_acc FROM wa_acc TRANSPORTING NO FIELDS.

65 IF sy-subrc <> 0. "Check if there is already a dataset

66 EXIT. "with the same key in itab_acc

67 ENDIF.

68 ENDDO.

69

70 z = rnd_scust->get_next( ).

71 READ TABLE itab_scustom INDEX z INTO wa_scustom.

72 wa_acc-customer = wa_scustom-id.

73 wa_acc-balance = rnd_balance->get_next( ).

74 wa_acc-category = rnd_cat->get_next( ).

75 wa_acc-last_entry = sy-datum.

76 INSERT wa_acc INTO TABLE itab_acc.

77 ENDDO.

78 INSERT yaccount FROM TABLE itab_acc.

79 WRITE: 'Database Table yaccount successfully filled with ',

80 numb_acc,' datasets' .

By looping numb_acc times it is made sure that we create the number of datasets chosen by the user. It is within this loop that the dataset is built: We create a random number between 1 and the number of banks in the check table in line 55. By using this number for an index read from the relevant internal table we get a bank randomly and move this value to the relevant component of our structure wa_acc. The mechanism works in an analogous way for each random value from a check table. Just note the advantage resulting from the fact that each row in database table YCITY contain a city and the respective currency for the city: When reading from the table YCITY we get a structure with the components city and currency, and not just any currency, but the currency assigned to the city. This way it is assured that each account has a currency that is determined by the city.

Let us now have a closer look at the inner loop from line 61 to line 68. What is this loop for? This loop is to assure that all lines of the internal table itab_acc will have a unique index. In line 63 the work area wa_acc contains all the key fields we have filled with random values. The statement READ TABLE itab FROM wa reads the dataset with the same key as the work area wa from the internal table itab. So we are looking in the internal table itab_acc if it already contains a dataset with the same key as the work area. If the account number we have created has produced a composite key that already exists another random account number should be created. If the account number is part of a unique key that is a key does not exist so far in the internal table itab_acc the sy-subrc after reading the table in line 64 is different than zero and the loop is left. From line 70 to 74 other random values are created and the entry column is filled with the system date.

Lines 78 to 80 are almost self-explanatory: The whole internal table is inserted into the database table and we output some information as to how many datasets we have created.

And that is it. To use this program yourself create an empty report y_fill_account_table in the package y_abap_demo and insert the program code provided at the end of this tip by copy and paste.

Running the program

To check if the program works, run it, insert a number such as for example 1500, and see if you get the output: