不管是哪种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表里数据结果相同，即要求将最终的累计结果冲为零，所以最后加了以下三项反冲，但反冲的数值并不是我们文件中的值，而原来有多少就冲多少（即好比数据被删除了）：
原文:https://www.cnblogs.com/jiangzhengjun/p/4297274.html