Basic Question about SORTED TABLE

[oliver_am]

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.

[former_member182550]

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.

[horst_keller]

Read the documentation for READ ...

[oliver_am]

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.

[Sandra_Rossi]

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

[horst_keller]

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

• access via table key
• access via free key

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

[Jelena]

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.

[horst_keller]

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

[Jelena]

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