我的天

上周五基本上我已经完成了，自己第一个VBA+ADO+SQL的跨表查询，接下来我还得在那里逗留多长时间还得有多少bug需要改进说不准，得一边用一边发现问题。做的时候觉得没问题，用着用着就会发现各种问题。比如第一次发现的bug是明明那个ID理论上就只会有一条记录，因为所有和那连接的东西都是左外的，但问题是我这个合并的新手犯了个很无知的错误，在进行左外之前虽然我也已经做了分组，但是除了那唯一的ID以外，我把其它信息也一并分组了，虽然合并的时候指定的是ID，但实际上合并上去的其它性质不一样，即便分组了，合并的数据还是会产生很多行。最后出来的结果就是虽然其它性质的东西并没有体现在最终的合并表上，但是它们却以隐身的方式体现了出来，因为它们的存在，让那唯一的ID出现了好几行。把右边那个表的数累加起来，数据是正确的，但左边的那个ID一样的数据就重复了好几遍，结果只要是左边和右边交互生成的数据全部都乱套了。最终的解决办法很简单，就是在合并之前做最后的分组的时候除了合并的那个关键字以及已经分组聚合的数据，其它东西一律不要存在。

VBA方案中招了，python方案也中招了，但是PP的方案没中招，这在我意料之中，但是PQ的方案居然也没中招，这个是我无法理解的。为什么同样的思路同样的合并方式，PQ就不中招呢？还是说之所以PQ不中招，是因为第一次发现的时候我已经改过来了，只是后来我又忘记了？

周一的早上，当我在上报纸质数据之前做最后核对的时候，又发现了一个bug。汇总数量没有错，但是根据汇总数量生成的百分比不对。拿个计算器按一下就发现不对头，跟其它方式生成的数据相对比也不对头。百分比第二位小数都为0，引起了我的注意。因为正确的结果应该是不都为0。接着我马上想到了自己对其它不是百分比的数据全部都进行了四舍五入到三位小数，但是进度我也四舍五入到了三位小数，但实际上进度是有两位小数的百分数，也就是需要保留的是4位小数。我把最后一位抹掉了，当然出来的结果跟理论上的那个会有差别，而之所以在其他方式没有犯这个错误，是因为其它方式的计算过程中，我没有对进度这个字段进行四舍五入控制。所以解决方法也很简单，我把四舍五入的位数从三位改为四位，又或者是直接取消四舍五入就完了。
VBA是个奇怪的存在，因为实际上它所用的四舍五入并不是经典的四舍五入，而是科学领域常用的四舍六入五成双。我在大一学基础化学的时候第一次听说这个，那时真的让我每次都想半天才算得清这个东西。我毕业以后，去某个单位实习，做完某个检验需要计算结果，那个结果也需要使用四舍六入五成双，每次遇到那种数据我都得慢慢想清楚。VBA这个四舍六入五成双跟一般的Excel算出来的四舍五入效果不一样。这就会导致用脚本生成的数据可能会跟人肉算出来的有差别。程序员们只能用自己的方式重新把一般四舍五入的效果模拟出来，不得不放弃VBA原生就有的四舍五入函数round。我运气好，还没遇到这种问题，而之所以没有这种问题，是因为除了进行乘除法以外，加减法的时候，我是不会遇到小数点三位以上的数据的，所以起码能保证通过加减法出来的东西都不会有这种问题导致的误差。至于乘除法出来的数据，实际上我也只是看一下而已，比如那个进度，上报的进度数据我会在手工纸质的表上用一般的Excel公式生成。

越研究就会越觉得自己无知，那些实际过程中积累的经验比直接从别人那里一二三四学回来的深刻多了。