一个 SORT 引起的 BUG
**关于SORT的测试**
REPORT ytest_sort.
PARAMETERS: p_count TYPE i.PARAMETERS: p_stable TYPE c AS CHECKBOX.DATA: BEGIN OF lt_tab OCCURS 0, a TYPE i, b TYPE c, END OF lt_tab.DO p_count TIMES. APPEND VALUE #( a = sy-index ) TO lt_tab.ENDDO.IF p_stable = 'X'. SORT lt_tab STABLE BY b.ELSE. SORT lt_tab BY b.ENDIF.cl_demo_output=>display( lt_tab[] ).如上代码，字段B一直是空的，我们按照B排序(P_STABLE不勾选)，结果如下：
当COUNT为21行时，还是正序的。大于21行之后，就出现了各种各样的情况。
怎么样，出乎意料吧？
(如果勾选了P_STABLE，结果都是正序的。)
你可以理解为SAP的SORT底层的排序算法比较特殊，而且SAP提供了STABLE这样的关键字，让我们可以在不改变原来顺序的基础上进行排序，所以SORT语法的结果不算是BUG。
但是这里有几个事情要说明：
1、当一个内表 ** 被排序的 ** 字段 ** 有重复值的时候 ** 的时候，SORT可能会引起不稳定，如果想要稳定排序，就要加上STABLE。
2、使用ALV时，SORT语法可能和ALV的排序结果不一致，要保持一致，可以加上 **AS TEX** **T** 关键字试一下。
3、当情况1出现在标准程序中的时候，就是妥妥的BUG了吧。
**一个标准程序的BUG**
下面的内容是针对某SRM程序BUG的分析，不感兴趣的朋友可以跳过啦。
SRM产品中，对RFx数据进行供应商比价时，当RFx行项目数据较多(22行或以上)，WDA界面中展示的行项目顺序是错乱的，与创建RFx时的行项目顺序不一致，给业务操作带来很大的困扰和不便。
为此我们找到了我们的运维厂商，希望他们解决这个问题。结果经过他们辛辛苦苦一个周的调试，最后认为是我们自己改了标准程序。
然后……把问题关闭了……
没办法，自己上。我刚开始接触WDA一两个月，真的不想自己上。
然后摸索了一个下午，最终发现了上述BUG。好像比某广的运维人员效率高一点。
下面是解决问题的思路：
由于WDA界面上的表格是通过BIND_TABLE设置上的，于是我在所有可能的BIND_TABLE方法中打上断点，然后执行WDA程序，顺利找到debug的入口。
之后在堆栈中，找到BIND_TABLE所传递的内表的相关逻辑，在相应的方法中打断点，找到了关键代码。
内表中的EXLIN是空值，且内表行数较多，SORT引起了不稳定。
而且标准程序的SORT没有加STABLE关键字。
除此之外，还有一些 **辅助证据** 证明这是个BUG。
比如：标准程序中针对ITEM的排序规则，除了根据字段EXLIN之外，还可以根据字段NUMBER_INT进行排序。而且SAP还提供了相应的函数BBP_PDH_ITEMLIST_SORT_HIER做排序，我在执行WDA程序时也进入到了此Function
Module。
虽然上图中IV_SORT_BY_NUMBER_INT的默认值是空，但在实际执行时，代码进入了下图中的第60行，BY_NUMBER_INT被设置为X。
而且，66行和74行，分别是采用不同排序方式的代码。
至此，我觉得可以确定这是一个BUG了。
向运维厂商的不专业表示不满，向他们随便关闭问题的做法表示谴责。
