problem with binary search

[Former Member]

hi,

i am facing some problem with the READ TABLE....BINARY SEARCH

i have retrieved the data into an internal table, and everything is fine when i check in debugging mode. however, for certain case, there is some vendors name cannot be shown, which mean does not go into wa_lfa1-t_name1, and unable to display.

i believe the problem come from the binary search.

example:

if i pull the report with full list without entering any parameter, then the whole report will come out, but vendor number 00000002, does not come out with a name.

but if i entered 00000002 as parameter, then it will come out correctly with the vendor name.

can any one please advice what is the problem here of unable to retrieve the details?

thanks

my code is as below:

  
SELECT lifnr        "vendor no
         zfbdt        "baseline date
         wrbtr        "amount in document currency
  FROM   bsik
  INTO TABLE  it_bsik
  WHERE lifnr IN s_vendor.

  IF NOT it_bsik[] IS INITIAL.
    SELECT lifnr
           name1
    FROM   lfa1 INTO TABLE it_lfa1
    FOR ALL ENTRIES IN it_bsik
   WHERE lifnr = it_bsik-t_lifnr.
  ENDIF.

    LOOP AT it_bsik INTO wa_bsik.
      CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
        EXPORTING
          input  = wa_bsik-t_lifnr
        IMPORTING
          output = wa_bsik-t_lifnr.

   READ TABLE it_lfa1 INTO wa_lfa1
      WITH KEY t_lifnr = wa_bsik-t_lifnr BINARY SEARCH.
      wa_finaltab-vendorname = wa_lfa1-t_name1.
ENDLOOP.

[Former Member]

befor usinging binary search sort the field.

READ TABLE - free_key

Syntax

... WITH KEY comp1 = dobj1 comp2 = dobj2 ...

[BINARY SEARCH] ... .

Effect:

After the addition before WITH KEY, components comp1 comp2 ... can be specified as a search key according to the rules in the section specifying components. One data object dobj1 dobj2 ... is assigned to each of the components. The data object must be compatible with or convertible to the data type of the component. The first found line of the internal table is read for which the values in the specified components (or their subareas or attributes) match the values in the assigned data objects dobj1 dobj2 .... If necessary, the content of dobj1 dobj2 ... is converted to the data type of the component before the comparison. No duplicate or overlapping key specifications are permitted. If all names name are initial when dynamically specifying the components, the first row of the table is read.

The search takes place as follows for the individual table types :

standard tables are subject to a linear search. If the addition BINARY SEARCH is specified, the search is binary instead of linear. This considerably reduces the runtime of the search for larger tables (from approximately 100 entries upwards). For the binary search, the table must be sorted by the specified search key in ascending order. Otherwise the search will not find the correct row.

sorted tables are subject to a binary search if the specified search key is or includes a starting field of the table key. Otherwise it is linear. If the specified search key is or inclucdes an starting field of the table key, the addition BINARY SEARCH can be specified for sorted tables, but has no effect.

For hashed tables, the hash algorithm is used if the specified search key includes the table key. Otherwise the search is linear. The addition BINARY SEARCH is not permitted for hashed tables.

Notes:

If a name field for naming a component comp is initial, the first line that fits the rest of the search key is read. If all name fields are initial, the first row of the internal table is read.

If the addition BINARY SEARCH is used, the READ statement executes an index access. This can therefore only be used for appropriately typed tables (generic type INDEX TABLE).

Even with a binary search (addition BINARY SEARCH is used for standard tables, automatically for sorted tables), if there are several hits (because of an incompletely specified search key or because there are duplicate entries in the table), then the first hit in terms of the sequence of the rows is always returned, that is, the row with the smallest index.

Example:

The internal table html_viewer_tab contains references to HTML- Controls. In the READ statement, the reference that points to an HTML control in a particular container is read.

DATA: container TYPE REF TO cl_gui_container,

html_viewer TYPE REF TO cl_gui_html_viewer.

DATA html_viewer_tab LIKE TABLE OF html_viewer.

...

CREATE OBJECT html_viewer EXPORTING parent = container.

APPEND html_viewer TO html_viewer_tab.

...

READ TABLE html_viewer_tab

WITH KEY table_line->parent = container

INTO html_viewer.

...