제한이라고 하면...라인수만 가지고 하는게 아니고요..

폭도 관계 있는것 같습니다..

어자피 메모리용량을 말하는거니깐...1바이트 1000개깨지라면...2바이트면 500깨 까지 아닐까요??

자세한 사항은 BC선생님께 패스해 드립니다.. ^^

라인에대한 제한은 없습니다.

헐크호간님 말씀처럼 메모리 용량과 관련이 있고요...

전체 ITAB SIZE는....다시 말해 메모리 싸이즈는 BC분과 상의 하시는게

정신 건강에 좋습니다.

 

initial size 는 지정할 수 있구요.

internal table 의 initial size 보다 클 경우 해당 size 만큼 확장하게 됩니다.

따라서 사양 좋은 컴퓨터이시면 더 많이 담으실 수 있을 텐데요.

그리 많이 담을 일은 없을 것 같습니다. 100만건이라고 해봐야 얼마 안되는 데이터예요. ^^;

for all entry 사용시 말씀하신 것처럼 문제가 발생할 수 있습니다.

이유라면 DB에서 for all entry 의 데이터를 where 조건으로 변경해 주는데,

DB에서 가능한 where 조건수를 초과하게 될 경우 덤프가 발생할 수 있어요.

시스템마다 다르기 때문에 뭐라 단정할 순 없네요. BC팀에서 최적화를 어떻게 했느냐에

따라 달라질 수 있습니다. 저같은 경우 for all entry 사용을 코드 테이블이나

데이터 건수가 그리 많지 않은 경우 그 수가 확실히 정해지는 경우만 사용하구요

그 이외에 가변적인 경우(조건데이터가 상당히 많아질 경우, 제 기준은 만건 이상)에는

사용을 안하는 편이예요. 아마도 4.6 이전 버전에서 그 기준을 정해 놓은 것이라 좀 작게 잡은듯 하네요.

해당 사이트에서 테스트 해보시고 적정 카운트를 잡으시면 될 것 같습니다. ^^

^^할루~ 잘 지내셨어요?

 

디버깅부분에서 New Tool -> special Tools -> Memory Analysis 에서 보시는 것도...

 

참고로, IN의 경우에는 matnr의 경우 8,000건 정도에서 덤프가 발생합니다. (64kb over)

미천하나마,,의견 달아봅니다.

 

1.

abap에서 in 조건으로 들어가는 갯수는 db쪽이 아니라,sap에서 지정된듯합니다.

이렇게 생각하는 이유는 db 툴에서 직접 in 조건으로 수십만건을 넣는다해도 에러가 뜨지는 않습니다.

(예전 ms sql에서는 그런 말이 있기도 했습니다. 설 로만...)

하지만, sap에서는 그 sql문 string의 크기로인해 덤프가 발생합니다.

==>한번에 보내지는 query string의 길이로 인해 덤프 발생 결정이 되는듯함.

     in 조건에 백만개의 조건이 있을 경우,, 한번에 sql문으로 변형되어지는 쿼리 조건은 bc 파라메터에 정할수 잇고,

     보통 5~ 30 정도로 정합니다(오라클 힌트로도 가능함).

     이말은 in조건에 100개의 값이 있고, 파라메터를 5로 할경우, 20번의 쿼리가 전송되어집니다.

     Ex) select * from aaa where zz in ('1','2','~~~~ '5') 이런 형태로 20번 쿼리 스트링이 날아감.

==> 바로 위 예는 for all entries 를 쓰는게 좋은지 나쁜건지에 대한 답도 될것 같습니다.

      loop 돌아서 100개의 조건을 100번의 쿼리 스트링으로 날리느냐. for all entries에 구문으로  db 파라메터값에 따라

      쿼리를 모아서 날리느냐.... 당연히 몰아서 보내는게 좋겟죠(단 해당 쿼리 스트링의 길이는 sap(abap)에 정해져 있어,

       덤프가 날수도 있다..

 

  - 말이 길엇지만,,, 대충 대충 의견 한번 달았습니다.

2. 인터널의 사이즈.
데이터 건수로 접근해서는 안될것이고, 해당 테이블의 1 record의 용량이 얼마냐로 접근하셔야 겟죠.
레코드 1개의 용량이 1메가 정도가 되는데 100만건을 담으면, 계산이 1기가인가요??계산이 안되네..
여튼 이런식으로 계산을 해야함.
보통 100만건 해봣자,,10~20메가 정도 밖에 되지 않습니다.

아밥 고지를 찾아서님께.
이런 내용은 sap 이나, abap이 아니고,, 프로그래밍에 대한 접근이 적절할것같습니다.
db의 기본적인 의미를 이해하려한다던가...프로그래밍할때 메모리 적재는 어떻게 된다던가..
이런식으로 말이죠...
혹시..건방졌다면,,,그런 의도는 아니니,,,이해 부탁드립니다.

Jon 님 감사합니다. SAP의 Query 분석 결과만 보고 Query 조건이 확장되는 것으로 봐서

DB에서 결정되는 것이라고 제가 생각했었나 봅니다. DBMS에서 직접 조작할 수 있는 여건이

아니라서 단순하게 생각을 했었나 봅니다. 좋은 정보 감사합니다. BC 에서 최적화를 어떻게

했느냐에 따라서 달라질 것 같다는 생각이 드네요. ^^ 저희같은 프로그램하는 사람 입장에선

건수테스트 해보는 수밖에는 없겠네요. ^^;;

참고로 internal table 의 block size 는 기본적으로 8kb 를 넘지 않는 수준에서 확장하는데,

시스템에서 판단하여 크다싶으면12KB 이내로도 확장한다고 하네요. 말하자면 internal table 의

initial size(선언시 지정된 크기 또는 0 으로 기본설정된 크기)의 메모리가 꽉 차면 확장하여

메모리 공간을 확보하게 되는데 그때 8Kb 기준으로 확장을 하는 것이 기본이나 internal table

사이즈가 클 경우에는 12Kb 이내에서도 확장을 하는데 그것은 자동결정되는 것 같습니다.

모두 모두 열혈한 답변에 감사드립니다. 오늘도 e-abap때문에 일할 맛이 나네요.ㅋ