Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Regarding the Binary search in Abap

akil_syed1
Explorer
0 Kudos

hi all,


I have developed this piece of code in my assignment using the binary search concept.i am not able to find why this code is not working.


please provide me suitable solution so that i can modify this code.



REPORT ZDEMOPROGRAM.

TABLES: vbak,

         vbap.

TYPES:BEGIN OF it_vbak,

       vbeln TYPE vbak-vbeln,

       auart TYPE vbak-auart,

      END OF it_vbak.

DATA: it_vbak1 TYPE TABLE OF it_vbak.

DATA:wa_vbak1 TYPE it_vbak.

PARAMETERS: p_vbeln TYPE vbak-vbeln.

SELECT vbeln

        auart FROM vbak INTO CORRESPONDING FIELDS OF TABLE it_vbak1.

SORT it_vbak1 BY vbeln.

READ TABLE it_vbak1 INTO wa_vbak1 WITH KEY vbeln = p_vbeln BINARY SEARCH.

IF sy-subrc = 0.

   LOOP AT it_vbak1 INTO wa_vbak1 FROM sy-index.

     IF wa_vbak1-vbeln <> p_vbeln.

       EXIT.

     ELSE.

       WRITE: /  wa_vbak1.

     ENDIF.

   ENDLOOP.

ENDIF.

17 REPLIES 17

sabirshah1
Participant
0 Kudos

check u didnt specify where condition in ur select query

I think u should use SY-TABIX in space of SY-INDEX.

READ TABLE it_vbak1 INTO wa_vbak1 WITH KEY vbeln = p_vbeln BINARY SEARCH.

IF sy-subrc = 0.

   LOOP AT it_vbak1 INTO wa_vbak1 FROM SY-TABIX .    "sy-index.

     IF wa_vbak1-vbeln <> p_vbeln.

       EXIT.

     ELSE.

       WRITE: /  wa_vbak1.

     ENDIF.

   ENDLOOP.

ENDIF.

davis_raja
Active Participant
0 Kudos

Its better not to use sy-tabix directly in the LOOP.

Declare a variable

v_index TYPE sy-tabix

Assign it after the READ statement

v_index = sy-tabix.

Then use it in the LOOP

Reason - sy-tabix value changes for every iteration of the loop

Former Member
0 Kudos

You say it's not working, but you don't say what or where the problem is.

Rob

Actually, it does work

Message was edited by: Rob Burbank

PeterJonker
Active Contributor
0 Kudos

Have you debugged your code ?

Where is it that your code is not doing what you expected and what did you expect ?

sujeet2918
Active Contributor
0 Kudos

Akil,

I can only see problem in loop, why are you using EXIT statement? instead use CONTINUE, so that your next record will process in case your IF condition fails.

Thanks,

Sujeet

raymond_giuseppi
Active Contributor
0 Kudos

Define your internal table as a TYPE SORTED, and remove fully one-half of your code.

Regards,

Raymond

0 Kudos

But the problem was pointed out by Sujeet.

SORT it_vbak1 BY vbeln.  is like declaring the table as SORTED for the scope of the report


0 Kudos

Like I said, the program gives exactly the results I would expect. The OP has to say what the problem is.

Rob

0 Kudos

Sory, No!

Look for performance of LOOP AT itab WHERE clause, when table is a type sorted and not sorted by statement sort.


TYPES:BEGIN OF it_vbak,

      vbeln TYPE vbak-vbeln,

      auart TYPE vbak-auart,

      END OF it_vbak.

DATA: it_vbak1 TYPE SORTED TABLE OF it_vbak WITH NON-UNIQUE KEY vbeln,

      wa_vbak1 TYPE it_vbak.

PARAMETERS: p_vbeln TYPE vbak-vbeln.

SELECT vbeln auart INTO CORRESPONDING FIELDS OF TABLE it_vbak1

  FROM vbak.

LOOP AT it_vbak1 INTO wa_vbak1 WHERE vbeln EQ p_vbeln.

  WRITE: /  wa_vbak1.

ENDLOOP.

Yes the error was raised due to confision between TABIX and INDEX, but that code may not be necessary. (of course there is much to do with thos program, no where clause, etc.) try a SCI on it for fun?

Regards,

Raymond

0 Kudos

Raymond Giuseppi wrote:

Sory, No!

Yes the error was raised due to confision between TABIX and INDEX,

Yup - missed that!

Rob

0 Kudos

Exactly, when you use WHERE condition

But here we got a LOOP.... FROM.

Right now i'm fighting with basis team which messed up SCI and some other things so i cannot try the difference but (happy to be wrong) that using SORTED or STANDARD table in LOOP...FROM got the same result from PERFORMANCE side

0 Kudos

Simone Milesi wrote:

But the problem was pointed out by Sujeet.

SORT it_vbak1 BY vbeln.  is like declaring the table as SORTED for the scope of the report


No. Really it isn't. If it was, you wouldn't then have to use binary search...

Jelena
Active Contributor
0 Kudos

This message was moderated.

BenedictV
Active Contributor
0 Kudos

Even yesterday I used a BINARY SEARCH in one of my BW transformations to improve performance....did I do something wrong

Jelena
Active Contributor
0 Kudos

Benedict Venmani wrote:

Even yesterday I used a BINARY SEARCH in one of my BW transformations to improve performance....did I do something wrong

And I yesterday got a program that used BINARY SEARCH instead of HASHED table.

It's not wrong when there is no better option. I doubt OP understands it. Certainly the code example here is not the best "use case" for it.

matt
Active Contributor
0 Kudos

Jelena Perfiljeva wrote:

Benedict Venmani wrote:

Even yesterday I used a BINARY SEARCH in one of my BW transformations to improve performance....did I do something wrong

And I yesterday got a program that used BINARY SEARCH instead of HASHED table.

It's not wrong when there is no better option. I doubt OP understands it. Certainly the code example here is not the best "use case" for it.

Unless you're dealing with huge volumes of data, you can always convert a standard table (e.g. given to you by a function module) into a HASHED/SORTED table, with additional keys as necessary. But only if you find that using the standard table is really making things slow.

But if you are defining an internal table, you should always define it to be the most optimal type for your purposes. If there's a COLLECT, for example, 99% of the time you really want to be using a HASHED table.

matt
Active Contributor
0 Kudos

Jelena Perfiljeva wrote:

Am I the only one noticing that this code has no logic (we have VBELN parameter and then proceed to select the whole table? wtf?) and is... um... not great overall?

Actually... I did exactly that today! Forgot to put the select option in the select statement.

But yes, I'd hardly define BINARY SEARCH as a "concept" or even something that needs teaching. Except to say you can sort a standard table and use the binary search addition...