Help with Changing Loop logic to Read logic

[sap_cohort]

Hi, I am looking to change the following Loop logic to using read logic because it will probably lead to faster performance.  Table is Sorted Table with Key MATERIAL DATEFROM DATETO.  This code is trying to find a material price record within a price date range table.

Can anyone help with the conversion?

Please let me know if I need to provide additional information.

      LOOP AT IT_SRO ASSIGNING <FS_SRO>
           WHERE MATERIAL EQ <TRANSACTION>-MATERIAL
             AND DATEFROM LE <TRANSACTION>-CALDAY
             AND DATETO   GE <TRANSACTION>-CALDAY.

[thangam_perumal]

Hi Kenneth,

                 Read logic mean Read Table? if  true  mean we cant use less than and greater value in read table...

[sap_cohort]

I was thinking that it might be possible to somehow read to at least get as close to the record as possible with a read and then somehow test if the next record meets the criteria.

Or maybe in this case a loop is justified and read cannot do as well?

Thanks for any insights.

[SuhaSaha]

LOOP AT IT_SRO ASSIGNING <FS_SRO>
           WHERE MATERIAL EQ <TRANSACTION>-MATERIAL
             AND DATEFROM LE <TRANSACTION>-CALDAY
             AND DATETO   GE <TRANSACTION>-CALDAY.

• I don't think you can replace this with READ TABLE because the only operator you can use with READ TABLE construct is '='.

For further read - ABAP Keyword Documentation.

The last example is similar to your code where the initial part of the (primary) key is used with '=' operator and the remaining condition is ignored.

Does the Code Inspector or ABAP Test Cockpit throw any warning?

Sorry for confusing you

BR,

Suhas

[matt]

It probably won't lead to faster performance and I'm not sure Suhas is right. The loop statement works fine with a partial key. (But now I doubt myself, and I haven't the time to write a test program...)

OK -try this alternative

TYPES: BEGIN OF material_attributes_ty,

  DATE_FROM type D,

  DATE_TO type D,

  other attributes

END OF material_attributes_ty.

TYPES: BEGIN OF my_material_ty,

  matnr TYPE matnr,

  attributes TYPE SORTED TABLE OF material_attributes_ty WITH UNIQUE KEY date_from,

END OF my_material_ty.

DATA: materials TYPE HASHED TABLE OF my_material_ty WITH UNIQUE KEY matnr.

Now you can go direct to your material, and then use looping to get the attribute for your key date.

matt

[SuhaSaha]

It probably won't lead to faster performance and I'm not sure Suhas is right. The loop statement works fine with a partial key.

Yes, you are correct Matt! The LOOP...WHERE in it's original form (as presented by the OP) is optimized. Similar example is part of the ABAP documentation that i had shared.

I was aware that the partial key (left-justified) works, but i didn't remember that the remaining part of the key (with non '=' operator) is not taken into account. The "sequential read" warning is generally given by the SCI or ATC, so i never remember the rules

Anyway I have corrected my comment.

Thanks,

Suhas

[sap_cohort]

Very nice example.  Thank you for passing that on and I will use that technique for sure!

[vamshi_mohan]

Hi Kenneth,

Are you trying to find a specific record or need a bunch of records.

If its multiple records, try with sorting table DATEFROM -> ascending;
DATETO-> descending.

Regards,

Vamshi.

[sap_cohort]

I am looking to capture a specific record for each material transaction.

Would it be best to continue using my loop logic on a sorted table or change to a read logic.  I'm thinking I could read to the first material price record match and then manually read through the remaining matching material records and test for the date range record I need based on date.

Any opinions are greatly appreciated. Thanks.

[matt]

If you read with just material, then the record you get back is the first match. So you can use read to get to 1266, and be sure you're on the one for 01/01/1900.

[vamshi_mohan]

Your sort order is quite fine. The loop also shall be executed as you are expecting as you are using loop at where... So the loop starts from the first material of your search. The loop logic is quite apt. No need of read.

Please share if you implement any better approach.

[sap_cohort]

Thanks for all the replies everyone!  Great support group you are!

I have decided to stay with the loop statement since it is simple and the table is sorted so performance is fine. Also, to populate the table is just a simple select into table.

I really, really, like Mathew's solution since it's one I didn't even consider, but it would take more work to fill the table than a simple select into to populate the table.

Thanks again all.