Sorted and hashed tables

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

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

Similar Messages

What is the difference between standard,sorted and hash table

can anyone say what is the difference between standard,sorted and hash tabl

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

Actual difference between a standard , sorted and hashed atble

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

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

Need some input on comparision btw sorted and std table.

Hi,
Just a small comparision on using standard table, sorted table, and sorted table using index in a loop with where conditions.
I just ran this report to find out the time taken and it is quite surprising. Case 3 of the program is quite faster than case2 and of course very fast than case1. any inputs on how this is possible???
output value :
try 1: 674, 192, 147 for 100 entries.
try 2: 603, 53 , 6 for 20 entries.
*C-- Small report to compare sorted and standard table.
REPORT zloopcompare.
TYPES : BEGIN OF tp_marc,
 werks TYPE marc-werks,
 matnr TYPE marc-matnr,
 END OF tp_marc.
DATA : t_marc TYPE STANDARD TABLE OF tp_marc.
DATA : t_marc1 TYPE SORTED TABLE OF tp_marc
WITH NON-UNIQUE KEY werks matnr.
DATA : wa_marc TYPE tp_marc.
DATA : p1 TYPE i,
 p2 TYPE i.
DATA : l_tabix TYPE sy-tabix.
DATA : count TYPE i.
PARAMETERS : p_werks TYPE marc-werks OBLIGATORY.
SELECT werks matnr FROM marc
INTO TABLE t_marc1
UP TO 1000 ROWS.
t_marc[] = t_marc1[].
*Case1 - standard table with where condition.
GET RUN TIME FIELD p1.
LOOP AT t_marc INTO wa_marc
WHERE werks EQ p_werks.
ENDLOOP.
GET RUN TIME FIELD p2.
p2 = p2 - p1.
WRITE : / p2.
*Case2- sorted table sorted as per the where condition.
GET RUN TIME FIELD p1.
LOOP AT t_marc1 INTO wa_marc
WHERE werks EQ p_werks.
ENDLOOP.
GET RUN TIME FIELD p2.
p2 = p2 - p1.
WRITE : / p2.
*Case3- using index to get faster access.
GET RUN TIME FIELD p1.
READ TABLE t_marc1 INTO wa_marc WITH KEY werks = p_werks.
IF sy-subrc EQ 0.
l_tabix = sy-tabix + 1.
LOOP AT t_marc1 INTO wa_marc FROM l_tabix.
 IF wa_marc-werks NE p_werks.
 EXIT.
 ENDIF.
ENDLOOP.
ENDIF.
GET RUN TIME FIELD p2.
p2 = p2 - p1.
WRITE : / p2.

HI sharath,
I just checked and executed the code :
1. case 1 and 2 are fine.
2. but 3 is not what u desire.
(in fact its not looping at all)
3. the code in case 3 is :
IF wa_marc-werks NE p_werks.
EXIT.
ENDIF.
So the loop goes inside ONLY ONCE,
and so, hence, its LIGHTNING FAST.
Please note that READ TABLE reads only
1 record.
4. ***************
Instead of NE
write this, and u will see that its not so fast.
IF wa_marc-werks = p_werks.
EXIT.
ENDIF.
regards,
amit m.

Differences between Standard , sorted and hashed internal tables

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

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

Swing and hash table

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

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

How to make sorting in hash table efficient

Hi guys,
I am relatively new to collections.
I have a HashTable which has 100000 records in it, when I sort it, it takes a lot of time to get it done.
As the Hashtable methods are synchronised so even I can't use threads to perform this quickely for me.
Can any one provide any solution using multi threading or any other method to achieve the optimization in
sorting the hashtable.
Thanks,
Atul

As already suggested, use TreeMap if you want to build your table in sorted key order. Otherwise, if you want to sort after the fact, you could do one of the following:
SortedSet sortedKeys = new TreeSet(map.keySet());
// or
List sortedKeys = new TreeSet(map.keySet());
Collections.sort(sortedKeys);Note that this will NOT affect that order in the map. It only affects the order of the extracted keys.
Also not that if sorting 100,000 items is taking "a long time," then you probably wrote your own sort algorithm and it's probably O(n^2) or something.

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

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

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

Hash table reallocation (rehashing)

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

Hi,
Just go thro' this.
1. Types of internal tables
1.1 STANDARD table
Key access to a standard table uses a linear search. This means that the time required for a search is in linear relation to the number of table entries.
You should use index operations to access standard tables.
1.2 SORTED table
Defines the table as one that is always saved correctly sorted.
Key access to a sorted table uses a binary key. If the key is not unique, the system takes the entry with the lowest index. The runtime required for key access is logarithmically related to the number of table entries.
1.3 HASHED table
Defines the table as one that is managed with an internal hash procedure
You can only access a hashed table using the generic key operations or other generic operations ( SORT, LOOP, and so on). Explicit or implicit index operations (such as LOOP ... FROM oe INSERT itab within a LOOP) are not allowed.
1.4 INDEX table
A table that can be accessed using an index.
Index table is only used to specify the type of generic parameters in a FORM or FUNCTION. That means that you can't create a table of type INDEX.
Standard tables and sorted tables are index tables.
1.5 ANY table
Any table is only used to specify the type of generic parameters in a FORM or FUNCTION. That means that you can't create a table of type ANY.
Standard, sorted and hashed tables belongs to ANY tables.

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

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 !

Creation of Sorted and Standard and Hashed Internal Tables ..

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

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

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

URGENT - Sorting Hash Tables

I am using a hash table with 2 columns. The first one has strings and is the key. The second column has integers.
I need to sort this table on the first column and print the contents of the table.
Then i need to sort it on the second column and print the results.
How do i sort the hastables.
Please let me know as soon as possible.
Thanks and Regards,
Vijay

You got it all wrong. Hashtables cannot be sorted because then it would not be a hashtable. The content of the Hashtable can be sorted.
What you want to do is get the key Set (keySet() method) of the Hashtable, wrap it in a List (e.g. LinkedList), sort that (see java.util.Collections for sorting) and then print out the contents of the Hashtable in the order pointed out by the keys in the sorted List.
Then you can do the same for the values() Collection of the Hashtable.
Pointers:
http://java.sun.com/j2se/1.4/docs/api/java/util/Hashtable.html
http://java.sun.com/j2se/1.4/docs/api/java/util/Set.html
http://java.sun.com/j2se/1.4/docs/api/java/util/List.html
http://java.sun.com/j2se/1.4/docs/api/java/util/LinkedList.html
http://java.sun.com/j2se/1.4/docs/api/java/util/Collections.html

Sorted and hashed tables

Similar Messages

Maybe you are looking for