不管是哪種DSO，表里的數據都會有Record Mode這一字段，NEW表與Active表里的該字段是由數據源上傳上來的，而Chang Log則是由BW系統在激活時由抽取上來的數據與Change Log里原有數據進行比對得到的，並且 后像、A像 都以是 X前像+后像來記錄，R像與D像 則還是以本身的像類型記錄
(注：Push方式的Delta-Queue里的數據也會帶有記錄模式，這種是用戶在維護數據時SAP系統記錄的（並且不同的Delta Proess增量處理模式，則會導致Delta-Queue存入數據有不同的記錄模式Record Mode），但不知道Pull方式的Delta-Queue是否也帶？需測試
下面以上面文件數據源為源，來測試記錄模式
新建標准DSO，將文件中的數據抽到此DSO中：
激活前，New中的數據如下，此時Record Mode並沒有數據：
激活后，Active表與Change Log中的數據如下：
Active表中的Record Mode也是空的，只有Change Log表里的Record Mode有數據，且都是新像，它是由系統自己對比數據自動設置的，但是New表與Active表里的Record Mode的值是由數據源本身提供的，但此時的文件數據源沒有提供，所以是空的
修改文件里的數據，再抽：
抽到DSO后激活，再看Active表與Change Log表里的數據如下：
由於500那條記錄沒有作修改，所以這次抽取時，Change Log沒有增加與它相關的數據
從Change Log可以看出，在DSO做激活時，系統會拿本次抽上來的數據與Change Log表里的數據作比對，然后生成修改過程的數據（如前像），正是因為有了Change Log表，所以AIE增量處理方式的數據源原本數據是不能直接抽到累加型的DSO與CUBE中的，但如果中間通過標准覆蓋型DSO后，就可以再將數據抽到累加型的DSO與CUBE中
問題引出：通過DSO關鍵值字段默認覆蓋特點，上面對修改與新增都會支持的很好，如果數據源中的數據被物理刪除了，那么怎么讓DSO也知道呢？
其實在Transformateion中，我們可以看到Record Mode其實是技術字段，那么只要我們的上來的數據中有Record Mode這樣一個字段時，實質上也是可以抽到DSO的New與Active表中的Record Mode中的：
下面我們在上面文件數據源上加上Record Mode這樣一個字段：
然后在文件中也加上一列 Record Mode：
然后Transformateion做一下字段映射，映射之前需要將常量修改為直接分配規則方式：
再開始傳數據，此時PSA里的數據如下：
運行信息包后，DSO表中數據如下：
此時發現將N像（新增像）統一變成了X后像，即修改結果像
發現Active表里少了一條數據了，即R像的數據被刪除了
此時Chage Log里會增加一條R像的數據，即Active中被刪除的那條數據。但1001、1002都沒有變化，因為轉過來時的Record Mode分別為新項與后項，最后都將它們看做是后項即修改，但數據又沒有發生任何變化，所以日志表里對這兩條記錄沒有記錄任何日志
下面來測試一下A像（累加項），在做之前，需要重新創建另外一個DSO，其金額字段轉換規則需要使用累加型（默認情況下是覆蓋型的，如上面的DSO）：
再修改文件內容，都修改成后像：
在測試之前，刪除數據源中PSA里以前抽的所有數據請求Request
再運行信息包：
運行DTP，查看DSO的Active表：
再次運行信息包與DTP后，Active表中發現Amount累加（2倍）了：
Change Log表中，后像的值都是累加后的值（2倍值），而不是傳過來的文件里設置的值：
下面再次修改文件，使用A像：
運行信息包與DTP后，New表：
Active表里的數據變成了3倍：
Change Log表
再運行一次信息包與DTP后：
再修改文件成R像：
運行信息包與DTP：
此時Active里沒有數據了，發現全部被刪除了：
（原因：因為是R像，R像本意最終是要將記錄刪除的，所以Active表里的數據最后被全部刪除了，既然是刪除則R反沖多少已經並不重要了，重要的是要將對應的數據刪除掉）
此時的日志表里的數據不會被刪除（因為是日志表嘛，不會直接刪除，它是要記錄數據變化的整個過程的），但最終的結果也要與Active表里數據結果相同，即要求將最終的累計結果沖為零，所以最后加了以下三項反沖，但反沖的數值並不是我們文件中的值，而原來有多少就沖多少（即好比數據被刪除了）：
