topic Re: Basic Question about SORTED TABLE in Application Development and Automation Discussions

Basic Question about SORTED TABLE

oliver_am — Fri, 28 Jul 2017 09:59:50 GMT

Hi, all.

I have a sorted table like this:

TYPES:  BEGIN OF line, 

 key TYPE char10,  

field1 TYPE char10,  

field2 TYPE char10,  

field3 TYPE char10,    

END OF line,

 my_table TYPE SORTED TABLE OF line WITH UNIQUE KEY key.

When I do a READ TABLE by the KEY field internally is doing a BINARY SEARCH, isn't it?

READ TABLE lt_my_table INTO ls_line WITH KEY key = '12345678'.

What happens if I do the READ with the KEY field and other fields too ? is doing also a BINARY SEARCH?

READ TABLE lt_my_table INTO ls_line WITH KEY key = '12345678'

                                             field1 = '99999'.

Thanks in advance.

Re: Basic Question about SORTED TABLE

Former Member — Fri, 28 Jul 2017 10:16:24 GMT

No it's not. It is using the key tree of the table.

When you read this table you should use this form of the Read statement:

READ TABLE lt_my_table INTO ls_line WITH TABLE KEY key='12345678'.

A Binary Chop is used on a standard table that has been sorted into an order based upon a field and the Read statement would like something like:

READ TABLE lt_my_table 
      INTO ls_line 
      WITH KEY key='12345678'
     BINARY SEARCH.

the key field specified must be the field used to sort the table initially.

Re: Basic Question about SORTED TABLE

retired_member — Fri, 28 Jul 2017 10:22:26 GMT

Read the documentation for READ ...

Re: Basic Question about SORTED TABLE

oliver_am — Fri, 28 Jul 2017 10:51:11 GMT

I've tried but I couldn't find the answer.

Well... I've searched again and find this in READ TABLE - free_key

The search runs as follows for the individual table categories, without BINARY SEARCH being specified:

Sorted tables are sorted in a binary fashion if the specified search key is an initial part of the primary table key or includes this key; otherwise the search is linear.

So, I guess that yes, it's doing a binary search.

Re: Basic Question about SORTED TABLE

retired_member — Fri, 28 Jul 2017 11:07:15 GMT

There are three ways of accessing an internal table with READ TABLE. Index access and two accesses via search:

The linked documentation explains how the different table kinds (and secondary keys) are treated.

Re: Basic Question about SORTED TABLE

Jelena_Perfiljeva — Fri, 28 Jul 2017 20:06:42 GMT

IMHO you're asking a wrong question. You simply need to know when to use the appropriate table types. If you are reading a table with a key then use HASHED table type, not SORTED. (And now we can even create indexes for internal tables.) SORTED is more beneficial for reading with a LOOP.

BINARY SEARCH is really rather a thing of the past these days. I have not used it for years. Even if it actually used by the system in background I don't feel it's relevant or important.

This has been covered on SCN a lot, might want to search for existing posts.

Re: Basic Question about SORTED TABLE

retired_member — Sat, 29 Jul 2017 09:28:52 GMT

"If you are reading a table with a key then use HASHED table type, not SORTED".

Hmm, that is a little too short. Find a more elaborated recommendation here.

Re: Basic Question about SORTED TABLE

Sandra_Rossi — Sat, 29 Jul 2017 19:03:43 GMT

You're right, it's doing a binary search because the free key (KEY+FIELD1) includes the primary table key of the internal table (KEY).

PS @Horst.Keller : I guess there's a little typo in the sentence mentioned by Oliver at READ TABLE - free_key : "Sorted tables are sorted" should be "are read".

Re: Basic Question about SORTED TABLE

Jelena_Perfiljeva — Tue, 01 Aug 2017 21:29:20 GMT

TLDR 🙂 Of course it's a simplification based on the OP's example.