数据跟踪：销售订单执行明细表查询报错“将截断字符串或二进制数据。语句已终止。”

一、遇到的问题

        如下截图，【销售订单执行明细表】点击查询后，会出现“将截断字符串或二进制数据。语句已终止。”的报错。然后有一些日期的数据不会报错，另外一些日期的又会报错，这个是什么原因造成的呢？

        这个是系统的标准报表，我们没有对这个报表进行过二开，所以报错的原因肯定是因为系统本身自带的哪个字段有问题？这个要怎么定位分析呢？

二、分析问题

        根据这个提示，可以判断到是哪个字段的值过长导致的。但是由于销售订单执行明细表所统计的数据太多，基本上囊括了整个销售业务链条的数据（包括销售订单、发货、出库、应收、收款等单据的数据），没有办法一下子判定是哪个单据哪个字段的问题，只能再做进一步的问题定位。

        具体的分析思路如下：

        1、先找出某个有问题的单据，再进行仔细的分析。

             可以先通过缩小日期范围，先定位是哪一天的数据有问题，然后再缩小当天的单据范围进行定位（一个个地排查这一天的单据具体是哪个有问题），这个容易理解，也很容易操作，就是要耐心地花点时间来定位。

        2、找出问题之后，先通过前台查看分析，看看能不能发现是哪个字段的问题？可以通过检查这个销售订单，还有它下游的单据的字段信息得知。

        3、如果通过前面两步还不能找到根本原因，那就只能用最后一个绝招了，那就是进行数据跟踪！也就是一般所说的SQL跟踪。一般是用SQL Profiler 跟踪器进行跟踪（如果是MSSQLSERVER作为数据库服务器的话，这个是自带的），这个跟踪器的具体使用方法可以参考以下两个链接，不再赘述：

        系统运维.数据库.SQL分析

        https://vip.kingdee.com/article/93398725082314496

      【SQL跟踪工具】SQL Profiler 跟踪器

        https://vip.kingdee.com/article/21561  

        下面展示一下我跟踪的过程和结果：

        1、先把SQL Profiler 跟踪器 的跟踪文件创建好，然后开始在前台进行报错信息的还原操作，等到出现报错提示的时候就来 SQL Profiler 跟踪器 停止一下跟踪，然后就开始从下往上地查看SQL语句（在TextData这列）。

        下面是我跟踪分析的过程，供参考。从这个过程可以推测出可能是哪段SQL出现了问题，然后单独把这段SQL拿到SQL执行器里面执行一下，再进行具体的分析。

        从下面的执行情况就知道Select语句没有问题，但是insert数据到临时表的时候却报错了，即可知道是临时表的问题，那就大概可以猜到是临时表的哪个字段的长度不够了！

接下来我们就去搜索一下这个有问题的临时表的创建语句，再进行分析！

        临时表的创建语句的搜索方法如下：

        对临时表的创建语句进行分析，见以下图文：

        最后发现，系统标准账表插件创建的收款条件的名称只有100个长度，然后我们这边的收款条件的名称在上线初期改成了150.

三、验证思路

        1、修正了BOS里面收款条件的名称的编辑长度，改成了100。

        2、然后数据库table里面也把现有的收款条件的名称字段的值改成了100个字符，语句如下：

        3、然后就发现前台查询所有年度的数据都可以查询出来了，说明根本原因就在于收款条件的名称过长导致的！

        至此，问题已解决！

四、总结

        1、修改系统自带字段的长度的时候，除了考虑上下游单据之间的这个字段的长度要修改之外，还要考虑到可能会对系统标准账表的影响；

        2、系统预置的账表会事先创建临时表这种做法其实也不太科学，因为用户修改前台字段的长度，是很合理的需求，总不能因为系统报表会报错我就不能把某个字段的长度改大吧？所以这个是系统设计上的一个局限性，希望总部针对这块会有更好的方案。

        3、以上问题虽然只是解决【销售订单执行明细表】报错的问题的一个过程，但是对于其他报表查询报错的问题，甚至是单据查询报错之类的问题，都可以依照这个思路进行问题分析。基本上数据类的问题都可以通过数据跟踪的方式来解决，只是这个要一点SQL基础，还有很多的耐心而已！[手动笑哭]

        至此，全文终。