Application Development and Automation 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: 
Read only

Read statement is not reading the data

0 Likes
2,015

have checked the subject line incident and found below:

The data is not being detected by the Read statement.what shall we do

1 ACCEPTED SOLUTION
Read only

michael_piesche
Active Contributor
1,803
  1. When you use BINARY SEARCH (which nowadays you shouldnt), make sure that the table is sorted the way you access the attributes in your read table statement:
    SORT lt_matdoc BY mblnr matnr werks charg.
    When looking at your table data screenshot, it looks like your table lt_matdoc is currently sorted by MBLNR, MJAHR, ZEILE (and possible also continuing with BWART, MATNR, ..., but cant be too sure because there are no further duplicate entries to justify that assumption)
    Thats why a BINARY SEARCH will almost never find the records you are looking for, when the SORT KEY doesnt match the SEARCH KEY.
  2. If you know, that you will only have max 10 maybe 100 entries in that table, and it is not accessed hundreds, thousands of times during one transaction with this / these read statements, just get rid of the BINARY SEARCH and dont bother sorting, the performance loss is not really felt by the user, but you make your coding harder to maintain otherwise.
  3. If you do need performance optimized read access, change your table type to SORTED or HASHED and access by TABLE KEY, maybe also use secondary keys if different access keys are necessary, but be aware of overhead incase of a lot of key inserts and deletes, which can make performance with keys bad again if unneccessary.

have checked the subject line incident and found below:

The data is not being detected by the Read statement.what shall we do

2 REPLIES 2
Read only

michael_piesche
Active Contributor
1,804
  1. When you use BINARY SEARCH (which nowadays you shouldnt), make sure that the table is sorted the way you access the attributes in your read table statement:
    SORT lt_matdoc BY mblnr matnr werks charg.
    When looking at your table data screenshot, it looks like your table lt_matdoc is currently sorted by MBLNR, MJAHR, ZEILE (and possible also continuing with BWART, MATNR, ..., but cant be too sure because there are no further duplicate entries to justify that assumption)
    Thats why a BINARY SEARCH will almost never find the records you are looking for, when the SORT KEY doesnt match the SEARCH KEY.
  2. If you know, that you will only have max 10 maybe 100 entries in that table, and it is not accessed hundreds, thousands of times during one transaction with this / these read statements, just get rid of the BINARY SEARCH and dont bother sorting, the performance loss is not really felt by the user, but you make your coding harder to maintain otherwise.
  3. If you do need performance optimized read access, change your table type to SORTED or HASHED and access by TABLE KEY, maybe also use secondary keys if different access keys are necessary, but be aware of overhead incase of a lot of key inserts and deletes, which can make performance with keys bad again if unneccessary.
Read only

1,803

"you shouldnt" because you should foster the use of internal tables of type SORTED or HASHED, hence BINARY SEARCH cannot be used (but access time is equal or faster).