‎2011 Nov 01 4:24 PM
Hi Experts,
Below pasted code is throwing time out dump, complete details are follows,
MODIFY t_getpo FROM wa_po TRANSPORTING labnr
WHERE ebeln = wa_repord-ebeln AND
ebelp = wa_repord-ebelp.
size of t_getpo is approximately 1million (it is working fine if data is less than .80 million; but some times my delta request contains more than a million records)
type : is STANDARD internal table, all fields are char type.
Could you please suggest me how to avoid this time out shortdump?
Best Regards
DJ Reddy
‎2011 Nov 02 9:04 AM
Hello DJ Reddy,
here is my proposal without redefining table type to a sorted one:
if t_getpo always has only ONE record for the given EBELN and EBELP:
CLEAR wa_repord.
field-symbols: <fs_repord> like wa_repord,
<fs_po> like wa_po.
LOOP AT t_repord ASSIGNING <fs_repord>.
READ TABLE t_getpo ASSIGNING <fs_po> WITH KEY
ebeln = <fs_repord>-ebeln
ebelp = <fs_repord>-ebelp
BINARY SEARCH.
IF sy-subrc = 0.
<fs_po>-labnr = <fs_repord>-labnr.
ENDIF.
ENDLOOP.If t_getpo may contain MULTIPLE records for the given EBELN and EBELP:
CLEAR wa_repord.
field-symbols: <fs_repord> like wa_repord,
<fs_po> like wa_po.
data: lv_tabix like sy-tabix.
LOOP AT t_repord ASSIGNING <fs_repord>.
READ TABLE t_getpo ASSIGNING <fs_po> WITH KEY
ebeln = <fs_repord>-ebeln
ebelp = <fs_repord>-ebelp
BINARY SEARCH.
IF sy-subrc = 0.
lv_tabix = sy-tabix + 1.
<fs_po>-labnr = <fs_repord>-labnr.
LOOP AT t_getpo ASSIGNING <fs_po> FROM lv_tabix.
IF <fs_po>-ebeln NE <fs_repord>-ebeln OR
<fs_po>-ebelp NE <fs_repord>-ebelp.
EXIT.
ENDIF.
<fs_po>-labnr = <fs_repord>-labnr.
ENDLOOP.
ENDIF.
ENDLOOP.Regards,
Yuri
‎2011 Nov 01 5:47 PM
Hi,
You should try to use a sorted or hashed table instead of a standard one. Access will be optimized.
Kr,
Manu.
‎2011 Nov 02 2:45 AM
Reddy,
I guess you are in a loop.
Use FIELD-SYMBOLS and get rid of MODIFY statement and access will be much faster.
loop at t_getpo assigning <fs_getpo>.
"just change <fs_getpo> with required values, int table itself gets updated
endloop.
Regards,
Diwakar
‎2011 Nov 02 8:05 AM
Hi,
Thank you Manu and Diwakar,
Manu - I will try to implement your suggetstion.
Diwakar - As per your suggestion Modify is already in loop, as per our client platform guide line we are not supposed to use loop in loop. Please find the below total pice of code.
CLEAR wa_repord.
LOOP AT t_repord INTO wa_repord.
CLEAR wa_po.
READ TABLE t_getpo INTO wa_po WITH KEY
ebeln = wa_repord-ebeln
ebelp = wa_repord-ebelp
BINARY SEARCH.
IF sy-subrc = 0.
wa_po-labnr = wa_repord-labnr.
MODIFY t_getpo FROM wa_po TRANSPORTING labnr
WHERE ebeln = wa_repord-ebeln AND
ebelp = wa_repord-ebelp.
ENDIF.
ENDLOOP.Thank you
DJ Reddy
<Added code tags>
Edited by: Suhas Saha on Nov 2, 2011 1:52 PM
‎2011 Nov 02 8:22 AM
Hello DJ Reddy,
The reason why the MODIFY statement is getting a timeout is that for every iteration of T_REPORD, which has a corres. record in T_GETPO, a full table scan(all the rows of the standard internal tab are checked) is performed on T_GETPO for the MODIFY ... WHERE statement.
If you use SORTED or HASHED tables, the access to the rows will be done using binary or hash algorithm respectively & hence optimized.
I'll suggest you try to implement Manu's suggestion & get back to the forums in case you face any problems.
BR,
Suhas
‎2011 Nov 02 9:13 AM
Reddy,
I didn't mean to introduce any new loop, just wanted to show you to use it with FIELD_SYMBOLS.
Yuri has given the required thing above which should help you. Note that "BINARY SEARCH" mentioned by him is utmost important in your scenario.
Remember to SORT the table on ebeln, ebelp before using Binary search.
Also note that Loop inside Loop can't be taken as an impossible scenario, there are various unavoidable cases where you will have to use them. There are ways to use them efficiently using binary search/sorted tables etc. Can be searched for more details in forums.
Regards,
Diwakar
‎2011 Nov 02 9:16 AM
Diwakar,
the BINARY SEARCH was already in his original code
I simply left it there.
Yuri
‎2011 Nov 02 11:05 AM
Thank you ALL. for your help, it help me solving the issue
‎2011 Nov 02 9:04 AM
Hello DJ Reddy,
here is my proposal without redefining table type to a sorted one:
if t_getpo always has only ONE record for the given EBELN and EBELP:
CLEAR wa_repord.
field-symbols: <fs_repord> like wa_repord,
<fs_po> like wa_po.
LOOP AT t_repord ASSIGNING <fs_repord>.
READ TABLE t_getpo ASSIGNING <fs_po> WITH KEY
ebeln = <fs_repord>-ebeln
ebelp = <fs_repord>-ebelp
BINARY SEARCH.
IF sy-subrc = 0.
<fs_po>-labnr = <fs_repord>-labnr.
ENDIF.
ENDLOOP.If t_getpo may contain MULTIPLE records for the given EBELN and EBELP:
CLEAR wa_repord.
field-symbols: <fs_repord> like wa_repord,
<fs_po> like wa_po.
data: lv_tabix like sy-tabix.
LOOP AT t_repord ASSIGNING <fs_repord>.
READ TABLE t_getpo ASSIGNING <fs_po> WITH KEY
ebeln = <fs_repord>-ebeln
ebelp = <fs_repord>-ebelp
BINARY SEARCH.
IF sy-subrc = 0.
lv_tabix = sy-tabix + 1.
<fs_po>-labnr = <fs_repord>-labnr.
LOOP AT t_getpo ASSIGNING <fs_po> FROM lv_tabix.
IF <fs_po>-ebeln NE <fs_repord>-ebeln OR
<fs_po>-ebelp NE <fs_repord>-ebelp.
EXIT.
ENDIF.
<fs_po>-labnr = <fs_repord>-labnr.
ENDLOOP.
ENDIF.
ENDLOOP.Regards,
Yuri
‎2011 Nov 02 12:24 PM
Hi Yuri
You ca see here Siegfred mentioning parallel cursor method as an outdated solution , particulary the comment sorts are expensive. Here its recommended to use sorted tables
I add +1 with Manu and Suhas
Any comments ?
Kesav
‎2011 Nov 03 7:59 AM
Hi Yuri
>
> You ca see here Siegfred mentioning parallel cursor method as an outdated solution , particulary the comment sorts are expensive. Here its recommended to use sorted tables
>
> I add +1 with Manu and Suhas
>
> Any comments ?
>
> Kesav
Hello Keshav,
outdated does not mean that it is always worse. Since the introduction of sorted tables, indeed using them makes things easier.
In the above case my intention was to make as little changes to the original code as possible. Maybe changing the definition of the table will require more changes in other places of the program. And in this particular case the usage of "loop at from index" was relatively easy to implement without significant effort.
It did not require any additional sorting as the inner table was already sorted before.
Regards,
Yuri