W3D5 _ Database Updates ( Unit 4 ~ ing )

Unit 1 Database Updates with ABAP Open SQL

INSERT / UPDATE / DELETE // MODIFY

sy-subrc : 작업 성공 여부 / sy-dbcnt : 작업 성공 횟수

INSERT ( INTO )

DATA: wa1 TYPE zscarr_01.
 
wa1-carrid = 'TJ'.
wa1-carrname = 'TJ Airline'.
 
INSERT INTO zscarr_01 VALUES wa1.

UPDATE ( SET )

DATA: wa1 TYPE zscarr_01.
UPDATE zscarr_01 SET currcode = 'KRW'
                     url = '//Temp Url'
                     WHERE carrid = 'TJ'.

DELETE ( FROM )

DELETE FORM zscarr_01 where carrid = 'TJ1'.

* MODIFY

- 테이블명 FROM workarea명(한 건) / MODIFY 테이블명 FROM TABLE internal_table명(여러 건)

- SAP에서만 존재하는 독특한 키워드로, record가 있는 경우 update 없는 경우 insert 수행

cf ) Internal Table을 활용한 Insert 응용예제

AUTHORITY-CHECK OBJECT - p 004 / Note (project에서 안 씀)

Open SQL commands don’t perform any automatic authorization checks.

   

Client Specified - p 004

현재 client ( mandt )가 아닌 다른 client 데이터를 가져오고자 할 때 사용

cf ) For getting used to Array Fetch 

Restoration of Previous Database Status ( Database rollback )- p 012

- DB 수정을 할 때 실패하면 이전에 변경된 것도 다시 원상태로 복구된다.

- Send a termination dialog message with message type A or X. ( terminate the prog. ) - ROLLBACK WORK causes a database rollback without terminating the prog. 잘 안 써

---

Unit 2 Database Change Bundling

p 032

SAP Logical Unit of Work ( LUW )

   • LUW : Logical Unit of Work로 논리적인 작업 단위 의미

   • DB LUW : 떨어져 있는 table이나 마치 한 개 인 것처럼 논리적으로 묶을 수 있음

     - All of nothing principle : 모두 다 적용되거나 모두 다 적용되지 않는 것이 DB의 원칙

     - Commit : save와 비슷한 개념으로 더 이상 Rollback이 적용되지 않음

     - 프로그램 단에서 모두 처리됨      - Implicit Database Commits : 나중에 한꺼번에 LUW로 묶인 DB가 Commit됨

---

Unit 3 SAP Locking

① Database Lock

   • 한 사람이 DB에 접근하고 있는 경우 다른 사람이 접근하지 못하도록 Lock 설정

   • Commit전까지 DB는 Lock이 되어 있음, 전 과정에 걸친 Lock         최종적으로 DB Commit이 끝나면(DB에 적용되면) 락을 푼다

② SAP Lock Concept

   • Central Instance에서만 존재하는 Enqueue Work Process에서 이루어짐

   • Lock을 저장해 놓는 Lock Table도 존재

③ Create Lock

   • Lock Object : SE11에서 EY 또는 EZ로 시작하는 Lock Object 생성

     - Tables에 Lock을 걸고자 하는 테이블명 명시

     - Lock Parameter(Lock Argument)는 key field가 자동으로 입력됨 : Parameter 개수 감소시 Enqueue되는 record 수 증가

   • Lock Module : Lock Object를 Activate하면 Enqueue와 Dequeue Function Module 생성

     - SM12에서 누가 Lock을 적용하고 있는지 확인 가능, 사용중일때는 ‘Foreign Lock’

- Lock obj 생성시기 : activate 이후

 ④ Lock Actions - Possible Results

   • SY-SUBRC = 0 : 성공적으로 Lock 수행하거나 Lock 가능

   • FOREIGN_LOCK : 다른 사람이 이미 Lock 잡고 있는 경우

   • SYSTEM_FAILURE : 기타 시스템 내부의 문제

p 62 추가해야하나. ?

Lock Argument ( Lock Parameter ) - p 064

- LOCK이 걸리는 범위를 지정   

Parameters in ENQUEUE Module - p 065

Lock Mode

S or W -  S : 락을 잡은 횟수에 대해 누적이 된다. / Read Lock / Lock을 공유할 목적으로 잡는다. 남들도 들어와서 볼 수 있음

O - Optimistic Lock / 접근을 허용하고, 나중에 누군가 E락을 걸면 접근이 안됨 / 처음에는 S와 비슷했으나, 나중에는 E를 해주기 위해 생성

E or V- E : 락을 잡은 횟수에 대해 동일하게 누적이 된다. / Write Lock /

                   실질적으로 수정하려는 목적, 배타적임, 남이 못들어감,

                    S로 잡아야만 들어갈 수 있다.

- V : 누적 가능 ( count 올라감 )

X or U - X : 락을 잡은 횟수에 대해 누적이 되지 않음. / 가장 배타적임 / 나도 한번밖에 락을 못검

R or C - R : O일때 R을 걸면 자동으로 E로 걸어짐(O->R(=E))

                  O에서 R(E)로 된 후에는 배타적이게 됨.

  

참고 동영상 - 각각 Mode에 대한 효과 동영상 입니다.

Scope

- Scope 1 : 자기프로그램 락

- Scope 2 : 업데이트 프로그램 락

- Scope 3 : 자기프로그램 + 업데이트 프로그램까지 락

Lock Container

각각을 별도의 락으로 잡지 않고 Lock Module들을 Lock Container에 넣어둠, FLUSH_ENQUEUE 모듈을 통해서 한꺼번에 Lock Table로 이동

RESET_ENQUEUE와 DEQUEUE_ALL 구별

   • RESET_ENQUEUE : Lock Container에 남아있는 Enqueue Function Module 삭제

   • DEQUEUE_ALL : Lock Container와는 관련 없이 테이블의 모든 Lock을 해제, 테이블명을 붙여주면 각각 해제 가능

---

Unit 4 - Organization of Database Updates

p 093

PERFORM ON COMMIT. - COMMIT WORK.

가벼운 프로그램만 씀. critical 하지 않은 곳에만 씀. p 99 - Diaglog 워크프로세스를 비워줘야하는데 안비워줌 데이터가 어디들어가고 언제 들어가는지 logging을 통해 확인할 수 없음DB에 과부하를 준다 스탠다드에서 제어가 안되기 때문에 일일이 개발자가 해야한다(책임영역이 많아진다)