这是一年中最适合讲故事的时候，手机免费建站，所以这里有一个小侦探故事！

不久前我们注意到AIF中的一个问题，即条目无法正确处理，错误的性质甚至无法记录。只是没有处理受影响的记录。经过一番挖掘，一位同事能够确定这是由于一个日期字段实际上是空的（而不是首字母）。当数据应该被转换成XML格式以便进一步处理时，由于日期字段的内容和格式出乎意料，这没有起作用，在云上，我们知道为什么处理停止了。

我们不知道的是，在某些情况下，是什么导致了日期字段的格式不正确。

没有简单的方法可以追溯到受影响条目的共同点是什么（或者是否有共同点！），我们只知道它在某种程度上与销售订单相关，并且所讨论的日期字段是驻留在VBAK的append结构中的自定义字段。一些条目被认为有问题，而其他许多条目没有。而且许多在日期字段中有空格的条目与AIF处理无关，因此基本上是"在雷达下飞行"。

然后我记得我们有一个小程序，如果我们幸运的话，它可能会！–帮助至少缩小受影响条目的来源范围。这个程序做的不多，它只是计算两个字段的组合在一个表中存在多少条目。如果表中包含一个名为"ERDAT"的字段，那么选择也可以受到日期范围的限制（是的，可以改进为允许其他字段名！）。因此，它非常适合于寻找"奇人出局"，即计数"通过屋顶"的组合，企业信息化软件，或者由于两个表字段的组合而看起来可疑。下面是选择的样子：

您只需要返回一个简单的ALV显示（这是来自DEV，所以不是一个有意义的示例）：

但是，在受影响的生产系统中，针对不同的领域，结合感兴趣的领域，这样做有助于我们缩小依赖于某些BAPI处理的特定传入流程和接口的范围，而进一步挖掘发现，填充BAPI扩展结构的方式是根本原因显然，便宜的云服务器，淘客怎么赚钱，相关性并不意味着因果关系——因此，这一技巧只能指出一个希望是正确的方向，即至少找出最有可能的大海捞针的地方。最妙的是，即使在CDHDR和CDPOS if这样的非常大的表上，程序也会丢失，这是一个很大的if！–您使用的是HANA-DB。在我们迁移到HANA-DB之前，为大型表安排时间的可能性非常高。有了HANA，程序很快就能（几乎）写出数字。

COUNT语句的字段必须基于字符（CHAR、NUMC、DATS或CUKY）我们的程序只考虑了两个领域根据DD03L表检查数据类型

代码根据选择屏幕输入构建动态SELECT语句：

COUNT语句代码并填充输出表：

您是否有类似的小工具程序可以在这种情况下提供帮助？