Internal Table에 대한 설명입니다.

의외로 이 개념에 대하여 혼돈을 일으키시는 분들이 많으시더군요. 그래서 이것에 대한 개념을 명확히 해야겠다고 생각이 들어서 비록 명령문의 설명 중간이지만 이 개념을 설명하고자 합니다.

Table에 대한 개념은 다들 아시죠? (설마 이것두 모른신다면…????)

맞습니다. Table은 데이터들을 저장하는 곳이죠. 데이터베이스를 배우지 않으셔도 전산을 한달 이상만 하셨다면 다들 아시는 내용입니다. 그럼 Internal Table에 앞서 조금 더 Table에 대한 개념을 잡고 넘어가겠습니다.

SAP R/3에서는 테이블에 데이터를 입력하거나 변경하고자 할 때에는 Header라고 부르는, 또는 Header의 기능을 수행할 수 있는 Working Area에 일단 데이터를 가져온 다음 그 데이터를 수정하고, 변경된 데이터를 다시 테이블에 적용하는 방법을 가지게 됩니다. 자 그러면 Header라는 것은 무엇인가? 테이블의 레코드와 동일한 Size와 Type을 가지는 존재를 말합니다. 즉 테이블에 들어갈 수 있는 하나의 레코드라고 보시면 됩니다. 따라서 Header의 기능을 수행하는 Working Area라고 하는 것은 테이블의 레코드와 동일한 Size와 Type을 가지는 존재인 것이 되겠죠. 다시 한번 말씀드리지만 SAP R/3에서는 TABLE에 데이터를 변경, 삽입하는 것은 Header의 기능을 수행할 수 있는 Working Area가 있어야 합니다.

자 이제 SAP R/3에서의 데이터가 삽입/변경되는 과정을 이해 하셨으면 INTERNAL TABLE이 무엇인지를 확인 해야겠죠? 테이블은 물리적인 존재입니다. 즉 하드디스크 상에 영구적으로 존재하는 것이죠. INTERNAL TABLE은 프로그램이 실행되고 있는 동안 생성되는 TEMP의 성격인 테이블입니다. 물론 이것도 하나의 테이블로 취급됩니다. 즉 앞에서 설명한 TABLE에서의 삽입/변경과정이 동일하다는 것이죠.

정리하겠습니다.

메모리 영역과 하드디스크(DBMS)영역에 테이블이 존재할 수 있습니다. 메모리 영역에서 생성되는 테이블은 프로그램이 실행되면 생겨나는 것이며 하드디스크 영역에 있는 테이블은 프로그램의 실행과는 무관하게 존재하는 테이블입니다.

메모리 영역에서 사용하는 테이블은 INTERNAL TABLE이라고 부르며 하드디스크에서 사용하는 테이블은 TABLE또는 TRANSPARENT TABLE이라고 부릅니다. 메모리 영역이든, 하드디스크 영역이든 모든 테이블은 삽입/변경하는 과정은 HEADER라고 부르는 특별한 존재를 통하여 가능합니다. 하드디스크의 Table을 사용하려면 Tables명령으로 Header를 선언하여 처리합니다. Internal Table은 Data문을 통하여 Header를 선언하여 처리합니다. 하드디스크 영역에 존재하는 테이블을 생성하기 위해서는 SE11 Transaction을 통하여 생성해 주셔야 합니다. 물론 DBMS Level에서 SQL문을 통하여 생성할 수 있습니다.

다음의 그림은 SE11 Transaction의 화면입니다.

select-option으로 선언된 변수하고 ranges 로 선언된 변수의 구조를 디버깅해서 봐봐.. 둘다 구조가 똑같애.

이것도 일종의 인터널 테이블이라고 생각하면 되지

select-option s_vbeln for vbak-vebln. 요놈하고

ranges s_vbeln like vbak-vbeln. 이렇게 한거하고 변수 구조로만 보면 똑같다는 거야... 단지 두개의 용도가 다른거지..

select-option 실행할때 입력받는 화면에 나타나는 변수고

range로 선언하면 그냥 프로그램안에서 변수처럼 사용한다는 차이가 있어.

range는 말그대로 범위라는 의미라서 특정 범위 from ~ to 값으로 데이터 추출하고 할때 쓰는거고

그런 범위 개념으로 사용할수 있는 변수를 range 변수라고 말하는거야....

니가 짠 펑션에서는 sales order 번호 한개만 입력받아서 그 정보를 리턴하는건데.....
너처럼 select-option으로 선언된 변수로 하게되면

사용자가 s/o번호를 1 에서 10까지 입력할때 어떻게 처리할거지? 상식적으로 생각해봐....
이럴땐 1에서 10까지의 s/o 번호를 루프로 한번씩 돌려서 펑션을 콜해야 하는거지......

그럴려면 펑션 콜하기전에 입력한 s/o번호를 itab에 담아서 그놈을 루프돌리며 s/o 번호 하나씩 넣어가며 콜하면 되는거야....

help 찾아보면 이렇게 나오는데 요렇게 인터널 테이블 선언한거랑

DATA: BEGIN OF rtab OCCURS 0,
sign TYPE c LENGTH 1,
option TYPE c LENGTH 2,
low LIKE dobj,
high LIKE dobj,
END OF rtab.

s_vbeln 이 변수 이름이라고 하면 아래와같은 구조의 인터널 테이블로 변수가 생성되는거고

사용자가 1 ~ 10 으로 범위값을 입력하면 이 변수에 값이 이렇게 들어가.....

sign option low high

----------------------------

'I' 'BT' '1' '10'

sign은 그냥 'I' 가 무조건 들어간다고 생각하면 되고.....

option 의 BT는 Better Then의 약자야 1부터 10까지... 라는 의미고

low는 화면의 필드에서 앞에 입력한 값이고 high는 뒤에 입력한 값

사용자가 앞의 필드에 특정 번호 하나만 입력하고 실행하면 이렇게 들어가.. EQ = Equal 같은..이라는 뜻

sign option low high

----------------------------

'I' 'EQ' '1'

개념을 알라나 몰라...

아무튼 그 펑션으로 수행하려면 이렇게 짜면 되지.....

빨간색이 내가 추가한 로직이야......

DATA : BEGIN OF ITAB OCCURS 0.
INCLUDE STRUCTURE ZSDSVBAK_VBAP.
DATA : END OF ITAB.

VBELN LIKE VBAK-VBELN,

END OF IT_SO.

SELECT-OPTIONS : S_VBELN FOR VBAK-VBELN.

SELECT VBELN INTO CORRESPONDING IT_SO

FROM VBAK WHERE VBELN IN S_VBELN.

LOOP AT IT_SO.
CALL FUNCTION 'ZSD_VL_DISPLAY_2' EXPORTING

* I_VBELN = S_VBELN
I_VBELN = IT_SO-VBELN
TABLES
LS_VBAK_VBAP = ITAB.

SELECT 구문 최적화

SAP R/3 구조 이해하기

R/3 구조를 이해하기 위해 아래와 같이 VBAK 테이블에서 데이터를 1000건 SELECT 하는 프로그램을 작성해 보자.

읽어올 정보는 다음과 같다.

- VBAK-VBELN: 오더 번호

- VBAK-AUART : 오더 종류

- VBAK-BNAME : 오더 이름

- VBAK-KUNNR : Sold to party

일반적으로 아래와 같은 방식으로 SELECT 문장을 작성할 것이다.

위 구문은 VBAK 테이블의 모든 칼럼을 한 건씩 읽어 가면서, WRITE 하는 구조로 되어 있으며, SY-DBCNT를 확인하여 1000건이 넘으면 EXIT하도록 되어 있다.

그럼 다음 단계에서 왜 위 문장이 비효율적인지 알아보자.

SAP R/3 구조와 실행시간

R/3 는 아래 그림과 같은 구조로 이루어져 있다.

R/3 는 위의 그림과 같이 3 계층 구조로 되어 있다.즉, 사용자가 시스템에 특정 데이터에 대한 요청을 하면, Application Server가 중간에서 사용자의 요청을 가공한 후, DB Server에 데이터에 대한 요청을 보내고, DB Server로부터 데이터를 받아, 다시 가공하여 사용자에게 보내는 방식으로 처리한다.

따라서, 앞과 같이 SELECT * 하게 되면, 문제에서 제시한 네 개 필드 외에 해당 레코드의 모든 필드를 가져오게 된다. 즉, VBAK 테이블의 한 레코드 크기가 대략 575바이트인데, 1000건을 가져와야 하므로 총 575,000 바이트를 DB Server에서 Application Server로 전송해야 하며, 한번 전송할 때의 패킷 크기가 32,000 바이트인 경우(시스템에 따라 다를 수 있음), 총 20여 회의 네트워크 트래픽이 발생하게 된다. ( 575,000 / 32,000 )

다음 단계에서 앞 문제의 해답과 이유를 알아보자.

SELECT * 개선

SELECT * 형태의 문장을 COLUMN Selection 이용하여 아래와 같이 개선할 수 있다.

위와 같이 사용하려는 네 개의 Column만을 가져오도록 할 경우 네트워크 트래픽은 다음과 같다.

즉, 네 개 Column 크기의 합이 59 바이트이므로 1000건을 읽는다 해도 59,000 바이트의 데이터만 DB Server에서 Application Server로 전송되면 된다. 패킷의 크기가 역시 32,000 이라면, 이 경우에는 두 번의 트래픽만 필요하게 된다.

BSEG, VBFA 같은 SAP Cluster Table에 대해서는 Column Selection 을 할 수 없다(Column Selection을 하도록 작성해도 내부적으로는 전체 Column을 읽는다.). 이러한 테이블을 Column Selection으로 읽고 싶은 경우에는, 시스템을 내리고, 테이블 형태를 Cluster Table에서 Transparent Table로 바꾼다.

데이터 건수 확인 요령

아래 방법은 SY-DBCNT를 이용한 데이터 건수 확인 문장을 UP TO n ROWS 구문을 이용하여 개선하는 예를 보여준다.

위의 예에서 첫 번째 문장은 데이터 1000건을 건건이 DB Server에서 Application Server로 전송하는 반면, 두 번째 문장은 DB Server에서 1000건을 읽은 후 일괄적으로 Application Server로 전송하는 방식 으로 동작한다. 따라서 두번째 문장이 훨씬 좋은 성능을 나타낸다.

WHERE 조건 없이 데이터 한 건만을 가져오는 경우라면, 차이가 더욱 두드러진다. 한 건을 가져올 경우 전자의 경우 150,000ms, 후자의 경우 1,500ms 시간이 걸린다.

CHECK 구문 개선

아래 예는 CHECK 문장에 들어가는 조건을 SELECT 문장에 포함하여 개선하는 방법 이다.

Vbak 테이블에서 57,000건을 가져오는 것을 비교한 경우

SELECT & CHECK 27,958,000ms

SELECT WITH WHERE condition 3,065,000ms

가능하다면 어떠한 경우라도, CHECK 조건은 WHERE 절 안에 들어와야 하며 이것은 SELECT SINGLE에도 적용된다.

SELECT SINGLE vbeln auart …INTO (vbak-vbeln, …) FROM vbak

WHERE vbeln = ‘0090000090 ’AND bname = ‘smith ’.

위 구문에서 vbak 테이블의 키 필드는 vbeln이지만, bname을 CHECK로 빼지 않고, WHERE 절에 포함시킴으로써, DB Server와 Application Server 간에 쓸데없는 네트워크 트래픽을 줄일 수 있다.

그러나, CHECK 절이 매우 까다롭고 복잡한 경우에는 오히려 DB Server에서 일단 데이터를 받아오는 것이 빠를 수도 있다. 이것은 SQL Trace를 이용하여 실제로 어떤 것이 빠른지 조사해보고 결정하여야 한다.

ORDER BY 구문 개선

아래 예는 SELECT 구문에서 사용되는 ORDER BY를 Internal Sort를 이용하여 개선하는 방법을 보여준다.

많은 양의 DB를 DB Server에서 정렬하는 것은 그 시스템을 사용중인 모든 사용자에게 영향을 미친다. 하지만 ABAP/4 프로그램 내에서 처리하게 되면 해당 Application Server에만 영향을 미친다.

하지만 SELECT 구문 내에서 ORDER BY를 이용하여 정렬하고자 하는 필드에 INDEX가 적절하게 구성되어 있다면, DB Server에 해롭지 않다.

APPEND 구문 개선

아래 예는 APPEND 구문을 이용하여 내부 테이블에 건건이 데이터를 추가하는 것을 INTO TABLE을 사용하여 개선하는 방법을 보여준다.

내부 테이블의 내용을 한 번에 전송하는 것이 더 효과적이다.

데이터를 내부 테이블로 한 번에 읽어 들이는 방법의 또 다른 효과는 처리시간이 매우 짧다는 것이다.

SELECT .. ENDSELECT. 내에서 많은 처리를 할수록 ORAO155 Snapshot too old( rollback segment too small ) 오류를 만날 확률이 높다.

수행시간이 긴 SELECT 문장은 동일한 작업 대상 테이블에 대한 INSERT/UPDATE 문장과 I/O Contention을 일으킬 확률이 높으며, 이럴 경우, DB Server가 반드시 read consistency를 보장한다고 단언하기 어렵다 .

VIEW를 이용한 Nested SELECT 개선

아래 예는 여러 개의 테이블에서 데이터를 가져올 때, view를 이용하여 NESTED SELECT를 개선하는 방법을 보여준다.

VBAK : 716건, VBAP 2779건의 데이터를 대상으로 테스트 한 결과는 아래와 같다.

개선 전: 3,892,184 microseconds(약 4초)

개선 후: 981,385 microseconds(약 1초)

Nested SELECT 대신에 VIEW를 이용하여 두 개의 테이블을 JOIN한 다음, VIEW에서 데이터를 읽어오는 것이 훨씬 수행 속도가 빠르다.

그러나, DB VIEW는 버퍼를 경유하지 않고 바로 DB에서 데이터를 읽어 오기 때문에 두 개의 테이블 중 하나가 버퍼링이 되고 있는 경우, 버퍼링의 장점을 살리지 못하여, 늦어지는 경우가 아주 가끔 발생할 수도 있다 . 이런 경우는 SQL Trace를 이용하여 실제로 수행시간을 측정하고 결과가 좋은 것을 사용하도록 한다.

DB Dictionary 의 DB VIEW는 항상 INNER JOIN이다.

VIEW생성시 MANDT열을 가져오도록 정의한 테이블을 가장 먼저 읽는다.

SELECT FOR ALL ENTRIES를 이용한 OUTER JOIN

아래는 SELECT FOR ALL ENTRIES를 이용하여 ABAP에서 OUTER JOIN을 구현한 예이다.

OUT ER JOIN을 할 경우 위처럼 FOR ALL ENTRIES IN 구문을 이용하여 SELECT한 후, 내부 테이블에서 처리하도록 한다 .

SQL 함수 사용하기

SELECT구문에서 LOOP를 돌면서 처리하는 형태의 합, 평균을 구하는 방법을 SQL 함수를 이용하여 개선하는 예이다.

10,000건의 데이터를 처리하였을 경우, 아래와 같은 성능 차이가 나왔다.

개선 전: 2,370,000 microseconds

개선 후: 1,574,000 microseconds

GROUP BY 절은 Pool Table이나 Cluster Table에는 사용될 수 없다(BSEG, VBFA).

WHERE 없는 SELECT 구문은 피하라.

아래와 같이 WHERE 조건 없이 SELECT 구문을 사용하는 것은 매우 위험하다.

특히 다음과 같이 빠른 속도로 크기가 증가하는 테이블에는 절대로 사용하지 말 것

BKPF, BSEG, COBK, COEP, LIPK, LIPS, MKPF, MSEG, VBAK, VBAP, VBPA, VBFA

테이블의 모든 데이터를 읽어 작업을 수행하려 한다면 다음과 같이 EXEC SQL 구문을 이용한 native sql을 구사하여 Application Server를 Bypass 하도록 한다. 그렇지 않으면 Application Server가 Where 절에 MANDT 조건을 붙여, Full Table Scan이 되지 않고 인덱스를 이용하게 되어 최악의 결과를 초래하게 된다.

DML 구문 최적화

효과적인 UPDATE 기법

SELECT 와 ENDSELECT 사이에서 순환을 하면서 UPDATE 하는 형태는 아래와 같이 WHERE 절을 이용하여 개선할 수 있다.

zvbak 1000건을 대상으로 한 결과는 다음과 같다.

SELECT .. UPDATE .. ENDSELECT. 1.8초

UPDATE .. SET 0.3초

위의 예제에서 COMMIT WORK 또는 ROLLBACK WORK 구문은 논리적인 작업 단위가 끝나면 반드시 기술해 주는 것을 잊지 말자. COMMIT WORK나 ROLLBACK WORK를 빠뜨리면 DB Server가 수정 정보를 계속 rollback segment에 가지고 있어야 하기 때문에 System에 overload로 계속 남아있게 된다.

효과적인 INSERT 기법

데이터를 테이블에 INSERT 하고자 할 경우, LOOP를 돌면서 처리하는 것보다 아래의 예처럼 한꺼번에 INSERT 하면 효과적이다.

아래 결과는 건수 당 테스트 결과이다.

1,000건 입력 시.

한 건씩 : 2.58초

한꺼번에 : 0.72초

5,000건 입력 시.

한 건씩 : 9.66초

한꺼번에 : 1.59초

10,000건 입력 시.

한 건씩 : 20.00초

한꺼번에 : 2.47초

효과적인 DELETE 기법

SELECT 와 ENDSELECT 사이에서 순환을 하면서 DELETE 하는 형태는 아래와 같이 WHERE 절을 이용하여 개선할 수 있다.

zvbak 1000건을 대상으로 한 결과는 다음과 같다.

SELECT .. DELETE .. ENDSELECT. 3.0초

DELETE FROM 1.2초

개선 전 코딩은 거의 최악의 코딩이다. 개선 전 경우 DB Server는 대상 데이터를 찾아서 모두 Application Server로 보낸다. 데이터를 받은 Application Server는 아무 일도 하지 않고, 받은 데이터를 다시 DB Server로 보내고, DB Server에서는 이 데이터를 삭제한다.

그러나 개선 후의 경우는 데이터의 발췌 및 삭제 작업이 DB Server에서만 발생하게 되므로, Application Server와 DB Server사이에 데이터 전송 작업이 전혀 일어나지 않는다.

효과적인 Internal Table 작업

Nested LOOP 처리

Nested LOOP는 BINARY SEARCH를 이용하여 아래와 같이 개선할 수 있다.

Ivbak : 5,000 ivbap : 20,000 일 때.

Nested LOOP with WHERE : 5분.

LOOP/READ BINARY SEARCH/LOOP : 15초.

효과적인 LOOP 처리

특정 조건을 만족하는 데이터가 몇 건인지를 알고 싶은 경우에는 다음과 같이 한다.

특정 조건을 만족시키는 데이터가 있는지 알고 싶다면 아래와 같이 하라.

내부 테이블 간 데이터 복사

동일한 구조를 가지는 두 개의 내부 테이블 간에 서로 데이터를 복사하고자 할 경우 아래와 같이 한다.

내부 테이블의 데이터 APPEND

동일한 구조를 가지는 두 개의 내부 테이블간에 서로 데이터를 APPEND 하고자 할 경우에는 아래와 같이 개선한다.

내부 테이블의 데이터 삭제

여러 건의 데이터를 내부 테이블에서 삭제하고자 할 경우 LOOP를 돌지 말고 아래와 같이 한다.

내부 테이블의 중복 데이터 삭제

위 방법을 사용하기 위해서는 비교조건 필드를 기준으로 정렬되어 있어야 한다. 비교조건이 없다면, 모든 필드로 정렬되어 있어야 한다.

내부 테이블 데이터 개수 알아내기

도메인 값 얻어오기

통화키 얻어오기

내부 테이블을 파일로 다운 받고 파일 열기.

Data Type

RFC Destination

Transaction Code

AbapDocu: ABAP 프로그래밍 예제.

Search_sap_menu: 메뉴 찾기.

ST05 :시스템 –유틸리티 –성능 추적.

STMS: CTS 관리자 .

SE09: CTS 요청.

SE30: 프로그램, 함수 성능 검사.

SQ01: ABAP QUERY.

SM50: 실행 중인 프로그램 목록 보기 .

SU01: 사용자 등록정보(암호 변경 가능) 바꾸기.

ST22: Dump 조회.

AL11: 서버 폴더 목록

함수

입력한 날의 달 마지막 날 구하기.

RP_LAST_DAY_OF_MONTHS

소수점이 포함된 문자를 숫자로 바꿔주기.

CHAR_FLTP_CONVERSION

음수일 때 –앞에 붙이기 ( 1,000,000 - -1,000,000 )

CLOI_PUT_SIGN_IN_FRONT

새 창을 열어 Transaction 코드 실행하기

NAVIGATION_EXECUTE_OBJECT

OBJECT_NAME “T-code

REPORTTYPE = ‘TR ’

NEW_WINDOW = ‘X’

숫자 뒤쪽의 –를 앞으로 보내기

CLOI_PUT_SIGN_IN_FRONT

함수의 파라미터 목록 얻어오기

RFC_GET_FUNCTION_INTERFACE

ABAP/4 is a fourth-generation language (4GL) but it is an event-driven language. It has a few events. But don’t confuse about ABAP Objects and events of them. Event blocks are introduced by an event keyword. They end when the next block begins. The following block can be another event block, introduced by a different keyword, or another processing block that is valid in the context, such as a subroutine or dialog module. Event keywords have the same name as the events to which they react.

The sequence in which processing blocks occur in the program is irrelevant. The actual processing sequence is determined by the external events. However, to make your programs easier to understand, you should include the event blocks in your program in approximately the samer order in which they will be called the system. Subroutines should be placed at the end of the program.

The following events occur at runtime of a typical report program with logical database:

INITIALIZATION

Point before the selection screen is displayed. When you start a program in which a selection screen is defined (either in the program itself or in the linked logical database program), the system normally processes this selection screen first. If you want to execute a processing block before the selection screen is processed, you can assign it to the event keyword INITIALIZATION. Mostly global variables, classes, internal tables declarations are made here.

AT SELECTION-SCREEN

Point after processing user input on the selection screen while the selection screen is active. It provides you with several possibilities to carry out processing blocks while the system is processing the selection screen.

START-OF-SELECTION

Point after processing the selection screen. It gives you the possibility of creating a processing block after processing the selection screen and before accessing database tables using a logical database. You can use this processing block, for example, to set the values of internal fields or to write informational statements onto the output screen. At the START-OF-SELECTION event, also all statements are processed that are not attached to an event keyword except those that are written behind FORM-ENDFORM block.

You can do select database tables data processing here. REPORT statement always execute a START-OF-SELECTION implicitly. Consequently all processing logic between the REPORT statement and the next event keyword is automatically processed in the START-OF-SELECTION event.

GET <table>

After the logical database has read an entry from the node <table>. The most important event for report programs with an attached logical database is the moment at which the logical database program has read a line from a database table. When many programmers learn how to write an ABAP program, they confuse about logical database concept and this GET events. At first glance GET looks like a normal statement, but it is event keyword. If you look at the source of the logical database program code, it is easier to understand the GET keyword, even when you see the opposite keyword PUT inside the logical database program.

GET <table> LATE

After the logical database has read an entry from the node <table>. The event is triggered when all of the records for a node of the logical database have been read. If you want to write, for example, a sub total for a field, you can use this event.

END-OF-SELECTION

To define a processing block after the system has read processed all selections. It is triggered in type 1 programs (reports). This is the last of the events called by the runtime environment occur. It is triggered after all of the data has been read from the logical database, and before the list processor started. You can use the corresponding event block to process and format the data that the program has stored in internal tables or extracts during the various GET events.

The following events occur during the processing of the output list of a report program:

TOP-OF-PAGE

In list processing when a new page starts.

END-OF-PAGE

In list processing when a page ends.

AT LINE-SELECTION

When the user triggers the predefined function code PICK.

AT PF<nn>

When the user triggers the predefined function code PF<nn>.

AT USER-COMMAND

When the user triggers a function code defined in the program.

The last three events are used when an interactive report program has been written.

PS. There are some other events and events have some extra usage options for different purposes; but major event are above as mentioned.

출처 : http://www.itcserver.com/blog/2006/06/26/events-in-abap/

pro/c ,esql/c 등에서 써보안던 cursor를 생각이 나게 된다.

Data를 Select하여 cursor라는 공간에 넣어 다음에 loop를 돌면서 data를 처리하는 방식이라고

생각하면 제일 간단한 계념이라고 생각이 든다.

하지만 Cursor가 제공하는 기능보다는 더 많은 기능을 가지고 있으며, 다양한 기능이

담겨 있다.

Internal table 의 종류에는 4종류가 있다.

다양한 종류는 교재를 참고하면 충분히 이해 하리라 본다.

1. Field String

- 여러개의 필드로 구성된 레코드. SAP GUI의 메모리를 차지한다.
- physical oracle database와는 아무 관련이 없고, program 실행시에 의미가 있는 logical한 영역이다.
- TABLES 문 다음에 선언해주는 table은 실질적으로는 field string을 선언해주는 것이다.

2. Internal table(with header line)

ex> data : begin of it_tab occurs 0 with header line,

a ,

b,

end of it_tab.

data : it_tab like bkpf occurs 0 with header line.

2-1. Internal table을 사용하는 이유
- DB가 메모리에 있기 때문에 속도가 빠르다.
- report를 출력하기 위해서.

2-2. Internal table(with header line)의 선언
- DATA절에 선언한다.
- LIKE를 이용한다.(권장)
- header line이 없는 Internal table처럼 선언하고 뒤에 WITH HEADER LINE구문을 붙인다.

2-3. Internal table을 채우는 방식
2-3-1. APPEND <itab> [SORTED BY <field>]
순서
I) MOVE-CORRESPONDING으로 work area 즉, header line에 넣는다.
II) APPEND명령으로 hearder line에서 Internal table로 넣는다.
- default는 descending. occurs 다음의 숫자만큼만 APPEND 되어 ranking list가 만들어진다.
- SORTED BY를 생략하면 occurs 다음의 숫자와 관계없이 read된 순서대로 APPEND된다.
- header line을 이용하지 않고 internal table을 채우고 싶다면 APPEND <wa> TO <itab>. 이라고 한다. 이 방식이 <itab> = <wa>나 APPEND <itab>보다 빠르다.

2-3-2. COLLECT
- header line의 P, I, F field를 internal table의 내용과 비교하여 같은 것이 있으면 data를 누적하고, 없으면 append한다.
- 이때, field의 type 중 P, I, F를 제외하고 비교한다.

2-3-3. INSERT문을 사용한다.

2-3-4. MODIFY문은 data가 있으면 update하고 없으면 insert한다.
- MODIFY itab [INDEX idx].
[TRANSPORTING f1 ... fn [WHERE cond]].
- LOOP 안에서 MODIFY itab.이라고 해 준다면 현재의 line이 MODIFY된다.
- 특정 line을 MODIFY를 할 때는 INDEX idx를 해준다.
- 특정 line을 WHERE조건을 써서 MODIFY 할 때는 TRANSPORTING ...을 해 준다.

- f1 ... fn은 MODIFY할 field명이다.
- LOOP 밖에서 INDEX나 TRANSPORTING을 사용할 때는 반드시 SY-SUBRC를 check해 준다.
- 특히 LOOP 밖에서 index를 사용하지 않으면 short dump를 발생시킨다.

2-4. data를 읽어오는 방식.
2-4-1. LOOP AT <itab> ... ENDLOOP
- data를 순차적으로 읽는다.
- LOOP문 안에는 INSERT, DELETE, MODITY문이 올 수 있다.

2-4-2. READ문을 사용하면 data를 명확한 single field를 읽을 수 있다.
- SY-TABIX 필드는 work area가 마지막으로 읽었던 record의 index를 가지고 있다. 즉, 현재 header line 내용의 index이다.
- INSERT, DELETE, MODIFY문도 SY-TABIX를 이용해서 dynamic하게 접근할 수 있다.
- 특히 MODIFY의 경우 INDEX절이 있는 경우 INDEX 다음의 값은 반드시 table내에 존재하고 있는 값이어야 한다.
- LOOP문과 READ문을 사용한 후에는 반드시 SY-SUBRC를 이용하여 error check를 한다. SY-SUBRC의 값은 성공일 때 0, data가 없을 때 4, error일 때 8이다.
- COMPARING option을 사용하면 COMPARING 다음에 적어주는 field의 header line의 값이 internal table에 있는 지도 check한다. COMPARING은 INDEX, WITH KEY, BINARY SEARCH등과 함께 쓰여야 의미가 있다. SY-SUBRC가 0이면 READ한 결과도 존재하고 COMPARING 다음의 field다음의 값도 존재한다. 2면 READ 한 결과는 존재하지만 COMPARING 다음의 field는 존재하지 않는다. 4면 READ한 결과가 존재하지 않는다.
- TRANSPORTING NO FIELDS라는 option을 붙이면 data가 존재하는 여부를 check하여 SY-SUBRC에 넣고, 해당 line의 index를 SY-TABIX에 넣는다. 이때, header line의 값은 변하지 않는다.
2-5. SORT문으로 sort할 수 있다.
- Default는 ascending이다.
2-6. 기타
- CLEAR <tab>은 header line을 initialize한다. header line이 없는 internal table은 body부분을

initialize한다.

ex> clear it_tab.

- REFRESH <tab>은 internal table의 모든 entry를 delete한다. 하지만 internal table은 memory를 차지하고 있다.

ex> refresh it_tab.

- FREE <tab>은 모든 entry를 지우고, memory space도 release한다.
- table에 대한 정보출력은 describe문으로 한다.
- <itab>[]과 같은 방식으로 Internal table을 참조하면 header line이 없는 Internal table과 같다. 이 방식은 header line이 있는 Internal table의 몸통을 직접 참조한다.
- occur문 뒤의 숫자는 예상되는 레코드의 수이다. 실제 레코드의 수가 앞서의 숫자보다 많아도 삽입은 된다. Internal table은 application server의 Rollback area를 사용한다.

3. Internal table(without header line)
3-1. 목적
- Internal tables allow you to reproduce very complex data structures in ABAP/4 programs

3-2. 특징
- header line이 있는 Internal table보다 약간 빠르다.
- work area를 직접 핸들링해야 한다.

3-3. 선언
- type선언을 하고 DATA절에서 like를 한다.

3-4. 기타
- 기타 삽입 등은 work area를 사용하는 것만 주의하면 Internal table(with header line)과 같다.
- complex structure는 반드시 header line이 없어야 한다.
- CLEAR문은 다른 것과 달리 header line이 있는 internal table에서 다르게 작용한다.

Enterprise resource planning