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: 

Performance issues in ABAP report using MSEG table

b_s_charumathi17
Explorer
0 Kudos

Hi All,

Due to clients specific requirements , we are developing a custom report from MSEG table. They run the report for a complete business area with out specifying plant and material. So we are getting a time out error.I ran a trace ,and could find its taking more time in a particular loop.

I have attached my code. Please guide me in improving the performance of the report.

Regards,

Charumathi B

8 REPLIES 8

FredericGirod
Active Contributor

Run your program using transaction SAT.

This will give you information: what takes time in your program

jmodaal
Active Contributor

Hello,

as frdric.girod already mentioned, you should try to determine the time-consuming parts via trace. This could be done via SAT or (what I personally prefer:) ST12.

As some customer developed tables appear in your program this could be done on your system only.

What is visible on a first glance is, that you are using standard tables with header lines and no secondary keys. Using header lines is quite old-fashioned and should not be used anymore. With big tables like that you will run into performance problems with statements like LOOP AT...WHERE, READ TABLE etc., because for each of these operations the entire table has to be processed right from the start. If a table is to be iterated using the same way (the same fields used for LOOP...WHERE or READ TABLE...) everytime, you can define the table as a SORTED or HASHED table, otherwise define secondary keys for the table and use them in the LOOP...WHERE or READ TABLE....

For database accesses (this is, where the ST12 offers some advantages in comparison to SAT) it depends again on your system and maybe you should get into contact with a DB admin in your company. This could become quite complex.

b_s_charumathi17
Explorer
0 Kudos

Hi Jan Modaal and Fredric Girod

I ran the trace .The program gives dump at this particular loop.Any ways to correct it.Pls let me know

loop at it_po.
loop at it_mseg where charg = it_po-charg and ebeln = it_po-ebeln.
didx1 = sy-tabix.
if it_mseg-bwart = '351' or it_mseg-bwart = '101'.
it_mseg-del = 'X'.
modify it_mseg index didx1.
endif.
endloop.
clear it_po.
endloop.

0 Kudos

A dump occurs where you reach the time limit, not when the statement is too long

What is the output of SAT ?

Hello,

give the internal table a suitable secondary index and use that for the LOOP.

types: begin of TMseg,
         mblnr   like mseg-mblnr,<br>
         " ...
         del(1)  type c,
       end of TMseg.
data: it_mseg type standard table of TMseg with default key
          with non-unique sorted key charg_ebeln components charg ebeln,
      mseg_wa type TMseg.    
...
loop at it_po.
  loop at it_mseg into mseg_wa using key charg_ebeln
      where charg = it_po-charg and ebeln = it_po-ebeln.
    didx1 = sy-tabix.
    if mseg_wa-bwart = '351' or mseg_wa-bwart = '101'.
      mseg_wa-del = 'X'.
      modify it_mseg from mseg_wa index didx1 using key charg_ebeln transporting del.
    endif.
  endloop.
endloop.               

0 Kudos

I had to make a bug fix in the source code. As you are modifying the internal table in the loop the MODIFY has to be adjusted for updating the right record. Without specifying the secondary key also in the MODIFY, the primary key would be used, where the SY-TABIX got from the access with the secondary key would point to another record.

0 Kudos

Or use some LOOP AT itab ASSIGNING <fs> and forget those index...

0 Kudos

Hello raymond.giuseppi,

this would save the time used for copying the data of the processed record from the internal table into the target area, but it would not save time processing the internal table to find the records fitting the given criteria - which is the problem here, I assume.