07-28-2017 10:59 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.
07-28-2017 11:16 AM
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.
07-28-2017 11:22 AM
07-28-2017 11:51 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:
So, I guess that yes, it's doing a binary search.
07-29-2017 8:03 PM
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".
07-28-2017 12:07 PM
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.
07-28-2017 9:06 PM
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.
07-29-2017 10:28 AM
"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.
08-01-2017 10:29 PM
TLDR 🙂 Of course it's a simplification based on the OP's example.