Does new READ TABLE syntax supports binary search?

former_member612073 — Fri, 31 May 2019 13:19:42 GMT

Does the new READ TABLE syntax (wa = itab[ col1 = …col2 = …]) supports binary search?

If no, is there any way this can be achieved?

Thanks in advance

Avishek

Re: Does new READ TABLE syntax supports binary search?

Nawanandana — Fri, 31 May 2019 13:46:58 GMT

Hi'

kindly look at bellow document , it clearly provide what is obsulate and what will be the alternative .

https://help.sap.com/doc/abapdocu_740_index_htm/7.40/en-US/index.htm?url=abentable_exp_itab_line.htm#!ABAP_ALTERNATIVE_2@2@

Obsolete Syntax
READ TABLE itab { { } 
                | { WITH KEY dobj } 
                | { WITH KEY = dobj } } [BINARY SEARCH] result. 
 
Alternative 1
... { } 


Effect
If the search key is not specified explicitly, the internal table itab must be a standard table with a header line. The first row found in the internal table is read for which the values in the columns of the standard key match the values in the corresponding components of the header line. Key fields in the header line that only contain blank characters are handled as if they match all values. If all the key fields in the header line only contain blank characters, the first entry in the table is read. The standard key of the internal table cannot contain any byte-like components.
Notes
The statement READ TABLE itab ... is not the same as the explicit declaration of the header line itab as a work area wa in the statement READ TABLE itab FROM wa .... In the latter, the table key and not the search key of the header field is used for the search. 

The search key can be omitted regardless of the additional obsolete short form (where no explicit target area is specified). 

In obsolete non-Unicode programs, the standard key can also contain byte-like components. 
Example
In the following READ statement (in contrast to the example for READ TABLE - table_key) no entry is usually found, since the whole standard key is compared. In particular, the components deptime and arrtime that belong to the standard key of the internal table are of type t and contain the value "000000" instead of blank characters as an initial value in the header line. Only table entries that contain exactly these values are read.
DATA: spfli_tab TYPE STANDARD TABLE OF spfli 
                WITH NON-UNIQUE KEY carrid connid 
                WITH HEADER LINE. 

FIELD-SYMBOLS <spfli> TYPE spfli. 

SELECT * 
       FROM spfli 
       WHERE  carrid = 'LH' 
       INTO TABLE @spfli_tab. 

spfli_tab-carrid = 'LH'. 
spfli_tab-connid = '0400'. 
READ TABLE spfli_tab ASSIGNING <spfli>. 


Alternative 2
... WITH KEY dobj 


Effect
If a single data object is specified directly after the addition WITH KEY, the internal table itab must be a standard table. The first row found in the internal table is read whose left-aligned content matches the content of the data object dobj. The data object dobj expects only flat data types. In the search, the start of table rows that are longer than the data object dobj are handled as if they have the same data type dobj (casting).
Example
To use the addition WITH KEY dobj for evaluating specific key fields, a structure must be created that corresponds to the relevant starting part of the row type. In contrast to the example for READ TABLE - table_key, in the following program section, the client column mandt of the table spfli_tab must be respected by the search key.
DATA: spfli_tab TYPE STANDARD TABLE OF spfli 
                WITH NON-UNIQUE KEY carrid connid. 

DATA: BEGIN OF key_struc, 
        mandt  TYPE spfli-mandt  VALUE '000', 
        carrid TYPE spfli-carrid VALUE 'LH', 
        connid TYPE spfli-connid VALUE '0400', 
      END OF key_struc. 

FIELD-SYMBOLS <spfli> TYPE spfli. 

SELECT * 
       FROM spfli 
       WHERE  carrid = 'LH' 
       INTO TABLE @spfli_tab. 
READ TABLE spfli_tab WITH KEY key_struc ASSIGNING <spfli>. 


Alternative 3
... WITH KEY = dobj 


Effect
If the addition WITH KEY is followed by a single data object after an "equals" sign, the first row found in the internal table itab is read whose entire content corresponds to the content of the data object dobj. It must be possible to convert the data object dobj to the row type of the internal table. If the data type of dobjdoes not match the row type of the internal table, a conversion is performed for the comparison in accordance with the conversion rules.
Note
This statement has the same function as specifying the pseudo component table_line as a free key, and is replaced by this component.
READ TABLE itab WITH KEY table_line = dobj ...
Example
Determines (obsoletely) whether a row in an internal table exists with an elementary row type. The comment lines show the generally valid syntax with the pseudo-component table_line.
DATA itab TYPE TABLE OF i WITH EMPTY KEY. 

itab = VALUE #( FOR j = 1 UNTIL j > 10 ( j ) ). 

READ TABLE itab WITH KEY = 4 
           TRANSPORTING NO FIELDS. 
* READ TABLE itab WITH KEY table_line = 4 
*                 TRANSPORTING NO FIELDS. 

IF sy-subrc = 0. 
  ... 
ENDIF. 


Addition
... BINARY SEARCH 

Effect
The addition BINARY SEARCH produces a binary search of the table, not linear. The same prerequisites and restrictions apply as when using the addition with a free search key. Before the correct row can be found, the internal table must be sorted in ascending order as follows:
If the search key is not specified explicitly, by the components of the standard key. 

If the search key is specified using WITH KEY dobj, by its left-aligned content in the length of the data object. 

If the search key is specified using WITH dobj, by the full table row. 
Note
The fact that the addition BINARY SEARCH requires a different sorting in each of the obsolete variants can be confusing and produce unexpected behavior. For this reason, the addition should not be used in the case of the obsolete variants and the non-obsolete variants of READ TABLE used instead.

Regards,

Nawa

Re: Does new READ TABLE syntax supports binary search?

Sandra_Rossi — Fri, 31 May 2019 14:31:45 GMT

No need of copy/paste the whole documentation, just refer to the sections which answer the question.

Re: Does new READ TABLE syntax supports binary search?

Sandra_Rossi — Fri, 31 May 2019 14:38:23 GMT

Binary search has always been optional since there are internal tables of type SORTED.

And even more optional since there are secondary keys.

With a sorted table (i.e. with a sorted primary key), or a table with a sorted key, the table expression itabsorted[ col1 = ... ] or itab[ KEY mysortedkey col1 = ... ] will implicitly do a binary search if you use the columns from the used key.

Re: Does new READ TABLE syntax supports binary search?

matt — Fri, 31 May 2019 15:20:35 GMT

You don't need binary search if you use a correctly typed table with an appropriate key. HASHED tables for preference.

Well done for using the new syntax. But HASHED and SORTED tables have been around since 2000...

topic Re: Does new READ TABLE syntax supports binary search? in Application Development and Automation Discussions

Does new READ TABLE syntax supports binary search?

Re: Does new READ TABLE syntax supports binary search?

Re: Does new READ TABLE syntax supports binary search?

Re: Does new READ TABLE syntax supports binary search?

Re: Does new READ TABLE syntax supports binary search?