collect 의 기본적인 기능은 char,numc type 의  field 가 같으면 i,p type 의 field 가 sum 됩니다.

위의 예에서 A,B Field type 이 C 가 되고 숫자가 들어가는 field 는 I,P type 으로 선언후 실행해 보시기 바랍니다.

네 madmax님 그게 맞는데요 그건 헤드에 뭔가 있을때 그것을 기준으로 인터널 테이블에 있는것을 비교 하여 sum을 처리하는거죠

제껀 헤드가 비워 줘있어요

loop at으로 돌린다고하더라도

만약

head : index 1내용 이 들어올때

collect를 하면 index1이랑 collect 되게 되자나요.. 아님 index2랑  그리고 index1은 그대로 남게 되지 않나요?

collect할 대상 internal table 이 있으셔야 합니다. 그리고 collect하는 테이블이 꼭 헤더라인을 가질 필요는 없어요. ^^;

loop 을 돌고 있는 itab에 collect 를 하실 수 없습니다. collect 대상 키값과 index 값을 안다고 해도 기존값에 collect가

되기 때문에 데이터가 해당 키값의 데이터 만큼 늘어나게 되어 부정확한 계산이 됩니다. 그 키값과 다른 레코드를

제외시켜주는 로직도 있어야 하구요. 그냥 동일 구조의 itab 을 하나 더 두시고 collect 하시는 것이 좋겠네요.

아래처럼...

loop at lt_tab.

  delete lt_tab.

  collect lt_tab.

endloop.

위에분처럼 하면 무한루프 돌듯한데요..

계속 지우고 밑에 쌓이고 할테니...

무한루프네요...죄송함니다;;

다시 올릴께요.

 

  data l_lines like sy-tabix.
  DESCRIBE TABLE lt_tab LINES l_lines.
  loop at lt_tab.
    delete lt_tab.
    COLLECT lt_tab.
    SUBTRACT 1 FROM l_lines.
    if l_lines eq 0.
      exit.
    endif.
  ENDLOOP.

참고로 COLLECT는 Coding은 싑지만 Internal table의 data가 많을 경우  Performance에 문제 발생 하므로  다음 사항을 주위 하시기 바랍니다.

1) Internal table에 데이터를 채울때는 COLLECT외의 다른 table filling statements(APPEND, INSERT, MODIFY, SELECT * INTO TABLE and/or SELECT * APPENDING TABLE)를 COLLECT와 혼용을 피하시기 바랍니다. 만약 혼용하여 사용한다면 COLLECT는 자신의 hash algorithm을 사용하지 못함. 이 경우 COLLECT는 lenear search를 사용하여 resort를 하므로 속도를 매우 느리게 합니다.

2) Internal table의 data가 많을 경우 COLLECT을 피하고 AT END OF ~ SUM ~ENDAT를 사용 하시기 바랍니다.

 <Worse>

 LOOP AT itab1.

   MOVE-CORRESPONDING itab1 to itab2.

   COLLECT itab2.

 ENDLOOP.

<Better>

 SORT itab1 BY werks, kunag, kunnr, vtweg, matnr.

 LOOP AT itab1.

    AT END OF matnr.

       SUM.

       MOVE-CORRESPONDING itab1 to itab2.

       APPEND itab2. CLEAR itab2.

    ENDAT.

 ENDLOOP.

저도...대용량 데이터를 Collect로 읽다가 Time Out 덤프가 떨어져서..Sum 으로 바꾼 기억이 나네요.. ^^"

Perormance를 위해서는 Sum으로 사용하는 것이 좋습니다.