topic Re: Sorted Table in Application Development and Automation Discussions

Sorted Table

Former Member — Mon, 17 Dec 2007 06:11:21 GMT

Hi,

Please provide some scenario where we have to declare a table as sorted table.

Thanks.

Re: Sorted Table

Former Member — Mon, 17 Dec 2007 06:26:23 GMT

hi aditya.,

declaring sorted table is same as declaring the standard table.

TYPES: BEGIN OF ty_s_vbpa,

vbeln TYPE vbpa-vbeln,

lifnr TYPE vbpa-lifnr,

scacd TYPE lfa1-scacd, " Standard carrier access code

END OF ty_s_vbpa,

it_vbpa TYPE SORTED TABLE OF ty_s_vbpa.

Reward ppoints if useful

Chandra

Edited by: Chandrasekhar Velpula on Dec 17, 2007 7:27 AM

Re: Sorted Table

former_member404244 — Mon, 17 Dec 2007 06:26:54 GMT

Hi,

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.

also check the link

http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb3800358411d1829f0000e829fbfe/content.htm

Regards,

Nagaraj

Re: Sorted Table

Former Member — Mon, 17 Dec 2007 06:31:59 GMT

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.

Using Sorted table and Index while processing Internal tables

There would have been many instances where we would have to process large entries in an internal table with a WHERE condition. This article is intended to demonstrate the comparison between three different methods in handling this situation.

First Method: The normal method used by most of us. Standard internal table processing using WHERE condition

Second Method: Same as above, but here we would be using the Sorted table

Third Method: Sorted table and using the Index

Following is the demo program illustrating the above three methods:

REPORT ZINTERNAL_TABLE_OPERATIONS.* Program to find the best method in reading the internal tables

Type declaration

TYPES:

BEGIN OF TY_MARA,

MATNR LIKE MARA-MATNR,

MTART LIKE MARA-MTART,

END OF TY_MARA.* Internal table declaration

DATA:

T_MARA TYPE STANDARD TABLE OF TY_MARA,

T_MARA1 TYPE SORTED TABLE OF TY_MARA

WITH NON-UNIQUE KEY MATNR MTART.* Variable declaration

DATA:

W_COUNTER TYPE I,

W_RUNTIME1 TYPE I,

W_RUNTIME2 TYPE I,

W_TABIX LIKE SY-TABIX.* Table workarea definition

DATA:

WA_MARA TYPE TY_MARA.SELECT MATNR " Material Number

MTART " Material Type

FROM MARA

INTO TABLE T_MARA.T_MARA1[] = T_MARA[].* CASE 1: Processing internal table using LOOP..WHERE ConditionGET RUN TIME FIELD W_RUNTIME1.LOOP AT T_MARA INTO WA_MARA WHERE MTART EQ 'FHMI'.

ADD 1 TO W_COUNTER.

ENDLOOP.GET RUN TIME FIELD W_RUNTIME2.

Calculate Runtime

W_RUNTIME2 = W_RUNTIME2 - W_RUNTIME1.

WRITE W_RUNTIME2.CLEAR W_COUNTER.* CASE 2: Using a Sorted tableGET RUN TIME FIELD W_RUNTIME1.

LOOP AT T_MARA1 INTO WA_MARA WHERE MTART EQ 'FHMI'.

ADD 1 TO W_COUNTER.

ENDLOOP.GET RUN TIME FIELD W_RUNTIME2.

Calculate Runtime

W_RUNTIME2 = W_RUNTIME2 - W_RUNTIME1.

WRITE W_RUNTIME2.CLEAR W_COUNTER.* CASE 3: Using INDEX on a sorted tableGET RUN TIME FIELD W_RUNTIME1.

READ TABLE T_MARA1 INTO WA_MARA WITH KEY MTART = 'FHMI'.

IF SY-SUBRC EQ 0.

W_TABIX = SY-TABIX + 1.

ADD 1 TO W_COUNTER.

LOOP AT T_MARA1 INTO WA_MARA FROM W_TABIX.

IF WA_MARA-MTART NE 'FHMI'.

EXIT.

ENDIF.

ADD 1 TO W_COUNTER.

ENDLOOP.

ENDIF.

GET RUN TIME FIELD W_RUNTIME2.

Calculate Runtime

W_RUNTIME2 = W_RUNTIME2 - W_RUNTIME1.

WRITE W_RUNTIME2.Following is the analysis report in microseconds, as per the data volume:

Records: 21,390

Iteration No

Using Normal LOOP & WHERE

Using Sorted table LOOP & WHERE

Using INDEX on Sorted table

897

887

839

879

839

877

834

880

842

837

Records: 132,693

Iteration No

Using Normal LOOP & WHERE

Using Sorted table LOOP & WHERE

Using INDEX on Sorted table

34239

35774

3567

34271

38250

3592

34492

36534

3554

34198

35695

3584

Sorted table might have given a better performance here if the field in the WHERE condition is the first field in the internal table. However, from the above statistics, we can say that method 3 is better than the other 2 methods. In production environment, the data would be huge and the performance could be much improved with this simple technique.