Sorted table in descending order

[Former Member]

Hi gurus,

is it possible to have a sorted table sorted by a key in descending order?

       TYPES: BEGIN OF gt_bsad,
         kunnr  TYPE bseg-kunnr,
         augdt  TYPE bsad-augdt,
       END OF gt_bsad.
       DATA: it_bsad TYPE SORTED TABLE OF gt_bsad WITH NON-UNIQUE KEY kunnr augdt.

Only with augdt sorted in descending order.

kind regards,

Wim

[Former Member]

Hi

No I don't think it's possibile

Max

;

[former_member192616]

Hi,

>

> is it possible to have a sorted table sorted by a key in descending order?
>

No, but why would you like to have it sorted descending (requirement)?

Kind regards,

Hermann

[former_member194613]

This was discussed recently, if you understand how binary search works, then you understand that the algorithm needs

to know that the smaller values are in first half and not in the second. If both possibilites are possible then it does not work.

But actually the only thing you need is a loop in descending order, which is also not available.

For the search you don't have to care whether it search downward or upwards, as log as it is fast.

[Former Member]

i think you are asking this for a requirement of binary search.

Matt has replied on this thread how to do a ascending binary search

[ |]

Nafran

[former_member192616]

Hi,

if you just want to output an ascending sorted table in descending order

you can use something like this:

data it type sorted table of t100 with NON-UNIQUE key msgnr .
data wa type t100.

select * from t100 into table it UP TO 50 rows.

data int type i.

 int = lines( it ).

  while int > 0.
    read table it into wa index int.
    write / wa-msgnr.
    int = int - 1.
endwhile.

or do you have another (other than output descending) requirement?

Kind reards,

Hermann

[Former Member]

Thanks all for the replies,

The requirement is to access the highest date per kunnr. That is why I wanted it to be sorted like that, but as I understand it is not possible. I know how to access this record but I was hoping that it could be as easy as just sorting it descending.

kind regards,

Wim

[former_member194613]

as I said,

for the largest line you must only access the line with the largest index, standard or sorted table.

Better SELECT only the largest line.

For the 10 largest, you would need a loop descending which you must program yourself as Hermann has shown.

with exit after 10 or n lines.

Siegfried

[former_member182566]

Siegfried, from what I understand the OP wants to have the highest date per kunnr.

Wim, if you sort your table by kunnr (ascending) and by augdt (descending) you can use read with binary search (by kunnr only).

This will bring the first record for that customer (which has the highest date that you want).

Hope this helps,

Rui Dantas

[former_member192616]

Hi Rui,

>

> Wim, if you sort your table by kunnr (ascending) and by augdt (descending) you can use read with binary search (by kunnr only).
> This will bring the first record for that customer (which has the highest date that you want).
> Rui Dantas

agree, will work. I don't see such (interesting) SORTs too often ;-).

>

> This will bring the first record for that customer (which has the highest date that you want).
> Rui Dantas

Yes, but just to complete:

depending how much identical kunnrs we have a self programmed search with sorted table (on kunnr augdt) might be faster.

e.g. something like (pseudo code)

search for kunnr and high value of augdt. (with key kunnr = '123' augdt = '31.12.9999' or something like that).
if not found
   step one index back (sy-tabix - 1)
   if kunnr = searched kunnr (check kunnr)
      -> got it!
   else
      -> not there
   endif
else
   -> got it!
endif

would result in one binary search (2 fields) + one index access. (worst case )

whereas the binary search on a standard table with one field (kunnr) only COULD result

in scanning larger portions of the table depending on the duplicates in kunnr (worst case scanning back half

of the table if all kunnr are the same, in order to get the first one (having the highest augdt)).

havent' checked it should work, benefit might be negletibale if we don't have huge amounts of duplicate kunnr values.

Kind regards,

Hermann