BW:关于DSO的RECORDMODE：一个比较棘手的问题

记得有这么一个问题，话说是DSO里出现了几条很违规的数据，这种数据吧，初始化的时候不会出错，跑D包才会有。  

以凭证号5100011935为例：

 

   

   

这里的0DOC_TYPE是不允许为空的，因为我们从最低层上载数据的时候，就已经限制了0DOC_TYPE=ZJ2

   

考虑到初始化的时候不错，跑D包才错，于是乎，我们抛弃了怀疑SAP BUG的情况，去检查LOG表 ，重点关注RECORDMODE   

 

   

LOG表是个好东西，这里很清楚，第一条数据是最早的，N镜像，之后又来了两条，X的为先，前镜像，目的是冲掉第一条数据，空的为后镜像，取而代之。之后的两条数据出现了错误，X掉前镜像之后，后镜像的0DOC_TYPE居然为空。

   

我们过去找这条数据的请求ODSR_4JFDA8PJ9IHRRHHHEO0YNNQD8，还好都在…

   

   

这里我们点监控器，回过来点调试。

   

   

这里我们可以得到这160条数据的前因后果。我们怀疑问题出在Start Routine上。

   

在调试请求的地方，选上想看的位置，基本上都是转换前后，Start Routine和End Routine的。

逐行调试之，最后发现，Start Routine调试结果没问题，在转换自身执行以后，就出现了ODOC_TYPE为空的情况。

这时我们就想到了DSO的机制，他会用前镜像冲销之前的记录，然后用后镜像覆盖。

   

几经周折，发现，原来是因为Start Routine里面有这样一句话。

   

    SORT itab_pack1 BY doc_number comp_code.

    DELETE ADJACENT DUPLICATES FROM itab_pack1 COMPARING doc_number

    comp_code.

   

这个看起来没有什么问题，可是我们假设一下，如果这条数据有前后镜像，这次删除会删掉其中的一个，删掉前镜像，后镜像的数量会和原来的数据相加，然后0DOC_TYPE=ZJ2，删掉后镜像，前镜像会和原来的数据做抵消，搞到最后，全为空。

   

PS：LOG表里的"按期履约的标记"的计算时在End Routine里，所以是有值的。

   

这种问题还是有点意思的。难怪最后算出来，履约的比总数都大~~~