我的天

VBA可以对普通的Excel文件用SQL查询，虽然我已经用的是超级表，理论上单元格的数据格式是一致的，但实际上这不是一个标准化的数据库，我没有办法在一开始的时候就对每个数据进行声明，所以在数据处理过程中就会出现这样那样说不准为什么的事情。

星期一的下午我跟往常一样做了些普通操作，最后当我用VBA生成一个汇总数据的时候发现弹出一个“标准表达式中数据类型不匹配”的警告。看到这个东西，我的第一反应是肯定是获取的数据里面有一些不规范的东西，比如说某一列通常是数字的，但是却出现了文字，但实际上我翻查了全部源数据都没有发现这个玩意。没办法之下，我只能做一个脚手架，一个一个的去排除，最后发现问题出在where里。where里有一个“性质<>某某某”的限定条件，问题就出现在那个地方，只要把这一句删掉，VBA是可以正常运行的，至于结果对不对不知道，反正能运行，然后我又回到了这一条的上一条结果，发现where里面的那个条件是没有问题的，所以这到底是什么问题呢？

然后我又想起，在进行普通操作的时候，我好像在某列数值的单元格里发现了一个汉字，说不准为什么那里会有一个汉字，但一个汉字足以影响那个单元格的类型。为什么我深有这种体会，因为如果某一列全部都是数字那么 VBA+ADO+SQL通常都会默认那是一个数值，但只要那一列里面有一个文字，所有东西都会被识别为文本。对数字进行聚合是理所当然没有问题的，但如果对文本进行这种操作，我不敢想象会出现什么东西。当然了，把文本作为分组条件，一点问题都不会有。

我感觉自己的VBA程序是健壮的，因为我已经用了他一年多了，之前从来没有出现过这种问题。有段时间经常会出现这样那样说不准什么问题的问题，但是过了一段时间之后，那些问题又自动消失了，所以我更相信那是有段时间windows更新导致某些框架不稳定导致了那段时间的意外。除非我对源数据做了更改，又或者是出现了某些意外，否则不会报这样的错误。

接着我又记起周一下午某个基本操作的时候，我好像发现在那个超级表的下面有一个“她”字。那个东西在不连续的单元格里，不是超级表的一部分，但关键是如果我用SQL获取数据，那肯定也会被纳入其中。看到那个莫名其妙的“她”字以后我已经把那删掉了，所以我看到的那个原始数据表格没有问题，但只是看上去没有问题。

折腾了好长时间未果，之后，我不得不重新翻出前一天晚上的源数据。然后手动把周一更新过的东西全部都贴回去。再去用VBA汇总，一切正常。在贴回去之前我首先用VBA测试了一下汇总没有问题，然后我才开始贴，贴了之后也没有问题。如果这个东西没有问题，也就是周一之前这个表格是没有问题的，但不知道周一进行了什么操作，导致了问题的出现。倒退以后重新贴数据没有问题，的确这个汇总也算保住了，但是我却一直放心不下，找不出问题的原因下一次依然会手忙脚乱。

吃过晚饭后我重新翻出有有问题的那个源数据。我的猜测是，因为数值列里面出现了一个文本，虽然我已经把文本删掉了，但是那个文本已经影响了那列单元格的类型，最终导致VBA弹出错误提示，虽然那个错误提示并不是出现在VBA调试发现的那一列。我的做法是在不修改VBA的前提下，把有问题源数据超级表下面的所有行全部删除，然后保存，再次运行vba，源数据通过了，可以正常运行。通过这样的操作，就能排除错误，非常有可能意味着我上面的猜测是对的。然后，我故意在数据列超级表外的单元格写一个字，然后保存，VBA汇总挂了。我把那个字删除，保存，VBA依然挂。但是当我把写过字的那一行删除，VBA汇总好了。这再一次验证了我的猜想。

这种事情该如何避免呢？首先不要手误，不要乱填。手误乱填这种事过去那么多年都从来没有发生过，为什么就发生了呢？到底是我的问题，还是另外一个人的问题？如果要避免这个事情，最好我在SQL引用源数据的时候就直接就限定为超级表范围，而不要把超级表所在的所有列都含进去。无论是哪一点，都是可以实现的。限定超级表的范围不太难，但关键是人手贱的这个行为，这一次出现在某个不知道为什么的单元格，下一次如果覆盖掉超级表的一个老数据呢？要避免这种人的失误非常难，但是人为什么会犯这种弱智到极点的失误呢？而且是犯了还毫不知情。

但总算这一次，我找出了可能的原因。

上一篇说到了数据汇总的问题。这个周一我就是按照上周五设定的那个步骤去做。在做的过程中，几乎没有发现什么问题，但是当我做完所有，一个个表格验证的时候却发现不知道为什么有些表格 SQL抓取的数据不完整，VBA从原始表格筛选、抓取的数据没有问题，但关键是SQL从本地的文件里提取到的那些数据不完成。第一次发现这个问题的时候，我看到的是为什么汇总数不一致。当我把SQL回退到第1步的时候发现第1步获取的数据就已经不完整。明明有50行数据，实际上只能提取到42行，重复多次依然是那个效果，但是偶然当我把文件关掉重开以后又好了。所以这个有时发生，有时不发生，到底是什么情况呢？当我打开VBA文件，一个一个测试的时候，发现前几个还好，后面就会出状况，可能是数据不完整，也可能是弹出一些莫名其妙的错误，但只要你把所有Excel都关掉，再重新打开又没有问题了，但是在测试几个以后，又会出现这样这样那样的状况。用VBA+ADO+SQL整理输出数据我已经实施过很多遍，之前从来没有遇到过这种神奇的状况。最后当我打开VBA脚本，无意之间拉到最后，居然发现cnn没有close，也没有初始化。cnn是个非常牛逼的东西，但是那个玩意也要耗费巨大的资源，在我出现数据状况的时候，我没有观察过我电脑的性能到底如何了，会不会CPU或者内存甚至二者都有点状况了。因为一次又一次的验证数据就意味着我得一次又一次调用cnn，光是打开又不关闭，最后就会出现奇奇怪怪的事情。当我把所有脚本都加上了结尾以后。从头到尾10个表以上的数据，一次性搞完，期间不会出现状况，所以多么神经质的行为才会导致了这种弱智事情呢？以前我倒真的从未试过这样。有过这样的经历以后就让我明白到cnn打开和关闭都必须是一个闭环，在一个宏里就得实现到位。如果某个宏被卡住了，半路停在那里，估计那个cnn是不正常的，当我又再次启动其它，只会让错误不断积累，最终导致崩溃，又或者是得不到我想要的东西。

写程序可以很快，但是调试却非常耗时间。这大概是所有码农都必须面对的事情，但实际上更多的人只顾写，只顾实现，而不考虑全盘，不尽可能地用全面数据测试，最终的结果就是使用的时候出现各种各样的未知情况。我不知道其他人到底是如何调试的，反正我真觉得调试的过程比写脚本更费神，因为要考虑所有的情况，哪怕某些条件可能非常极端，几乎不会碰到，但即便那样，一个健壮的程序应该依然能捕捉到那个错误，然后给出对应的反馈。比如我抓取不到数据了，我就应该弹框告诉人家我抓不到，因为有些操作的抓取数据以后才能进行，所以既然能判断抓不到数据，后面的也就不用继续了。

调试程序是一个很磨人的过程，这个过程重复多了，人自然而然就会向完美靠拢，即便我们一定不能成为完美的那个。

整个科室的人都出去培训了，除了我，所以一整天下来很安静，几乎没有人过来打搅我。只有一个过来找出去培训的那些人，神奇的是昨天单位微信群上也很安静，没有经常闪动。为什么会如此平静呢？

摸鱼这种事情有别人在跟没别人在对我来说没有区别，当我要摸鱼的时候，谁也阻止不了我。虽然有时摸鱼的时候不得不东躲西藏。可当我要认真的时候，同样也是没人能阻止我，不管那是上班还是下班，是白天还是半夜，只要我想干下去，哪怕那跟加班费没有半点关系，我也不会停下来，因为那是我想要干的事。

四周很安静，没有任何的干扰，也没有什么特殊的任务突然降临，所以我该做些什么呢？在做完平时应该做的那些事以后，我应该做些什么呢？摸鱼什么的摸多了也会觉得无聊，所以还是要找一些正经事干一下。有事可干的时候，你就只管去干，干就完了，但是当你无事可干又得找些事干的时候，的确挺烦恼。我觉得这个烦恼对我来说已经存在了好长一段时间。究其原因是有些时候你根本打不起去干某事。一方面你没什么事干，另一方面是有些事你或许可以干，但是你不想去干。这两个因素凑起来就变成了一个死循环，人就是在这个死循环里。慢慢地耗费着生命。

前天下午，我突然想到要以另外一个数据模板写一个VBA的汇总脚本。汇总脚本之前我已经写过，而且已经用了一个入户周期，2.1万吨的玉米入库绝大多数都是通过那个东西生成的，一直都没有问题，所以根据我的数据模板生成那个东西是完全没有毛病的，但如果我换了一个数据模板呢？我自己的数据模板没有毛病，其中一个很重要的原因是里面一些关键参数的设定我是以我的模板的某些数据量身定做的，但如果我换了一个模板我就得把某些数据转换过来。比如把两列的数据有条件地合并为一列，这是可以预知的，另外一些不可预知的我只能尽可能的把我想到的都做出来。当我遇到这个问题的时候。我感觉明明很简单的东西，为什么就要搞出那么多的花样呢？为什么这个不应该随心所欲的东西，实际上就这般随心所欲呢？大家都是说根据某个国标去做的列表，但实际上用起来的时候五花八门。我自己用的那个转换脚本是完全根据我的那些乱七八糟理出来的，但我不知道别人的乱七八糟到底乱成一个什么模样。这是一个无底洞，我自己的处理方式是嵌套很多层replace，但显然对小白来说，这样的操作非常不友好。所以在新的汇总脚本里，我采取的方式是建立一个索引，把集合五花八门的索引得先建立好了，然后我再以左外的方式匹配某些关键词，把所有的内容给关联上去。因为是开放的，可以很容易进行编辑，而且不需要他们懂得任何公式嵌套技术。这是我能想到的一个很大的坑，但我觉得还有一些更大的坑隐藏在阴暗处，比如别人生成汇总的那个数据模板不是我理解的那一款，他们需要在那个模板上手动编辑才能出结果。这就意味着索引的方式得发生变换了。还有一个就是万一在另外一个参数的地方，他们那个基础数据表还得进行某些修改才是他们汇总表的那个格式，那么那个地方也需要进行加工。综上所述，我觉得其实这些坑可以完全不存在，但问题就是设计软件的人和使用软件的人思路不一致，使用软件的人没有考虑到以后会被要求进行这样的操作，所以一开始默认套用了某些增加参数的方式。最终结果是他们得绕一大个圈、人肉查找好几个表才最终汇总出一个结果。这样就会导致汇总出错的概率提高，同时也会让人没有必要地忙乎一大轮，而且是天天都得这么忙。

如果把这些事情都理清了，根本不是问题，但可以肯定的是，不是所有人都愿意在这个理清上面花时间、把这一整套人肉的操作变成自动化。因为从根本上说大部分的他们只是为了仅仅完成任务，而从来没想过要把那做得更好、做到极致。

又花了大半个下午的时间，我把python跨表查询版最后的那个小计功能也开发出来了。其实前一天晚上我已经找到了类似的案例，只要按研究透的那个东西，接着往我自己那里套就可以了。我大概明白里面用到的公式到底是干什么用的，但是把它们套起来了以后，我发现用在我的那里无论如何都不对，所以我就在案例里不断套脚手架，不断地做注视去掉东西。最终发现让我失败的原因是我的那个dataframe是没有索引的，这就让我后面折腾了好长一段时间。

要在dataframe里加小计，首先需要对进行小计的项目进行分组处理。前一天我已经了解过，这样分组出来结果就只是那些聚合的数据。这些聚合的数据如果你不需要带入特殊的分组词，那么你跟原数据合并，然后根据你的分组项目名排序，小计就会合体到原来的dataframe里。如果你要加入小计这样的词语，你就得虚拟新增一列以非分组项目为名称的列名，内容就是小计之类的词。这样的分组结果我不知道为什么那个案例最后要设定以分组项目为索引，因为我在折腾那个案例的时候发现做不做这一步出来的结果没区别。

最最关键，让我折腾半天的根本原因是我要加小计的那个dataframe在从Excel读取数据的时候就已经设定了不添加索引。我发现当我去掉了案例的默认索引以后，和我的脚本出现了同样的问题。所以解决方案是先给我的datafame添加一个默认索引，然后再进行上面说到的分组操作，接着把有默认索引的dataframe跟分组结果结合在一起。同时对分组项目排序。分组后的结果有没有默认索引都无所谓，因为合并时都得重置索引。我没有试过如果这个dataframe也自带了默认索引，最后能不能成功合并。纯粹为了探索，我应该了解这个，但因为我运气好，在研究之前就已经得到了我想要的结果，所以我就没有继续下去，接下来我会继续拿那个案例把玩一下。

为什么会在Excel的单元格数据传入pandas的时候就把默认索引禁止掉呢？其实不禁止也完全没有问题。因为在最后把加工过的东西输出的时候，我可以控制不输出。之所以会有这样的习惯，写出这样的控制，是因为我看的第一本用python批处理Excel的书里面是这么写的。在看那本书的时候，我觉得那本书写得一般般，因为他给出了一个例子，然后大概告诉你要实现什么功能，接着就是展示脚本。我觉得起码你得在介绍那个例子的时候，除了源数据本身，也得展示一下你最终的效果是什么。他们还偶尔说不清具体需求是什么，唯有去研究他们的代码，你才知道原来具体他们要干那个。

在一个明细数据表里加入小计这东西是完全可以实现的，但是从数据处理的角度考虑，为什么我要把明细跟汇总合并在一起呢？如果用我的Excel思维去考虑这个问题，我觉得明细表就是，明细表汇总表用透视表表达出来就好了。因为数据透视表是很灵活的，可以用任意的汇总维度去观察同一个源数据。python可以轻松处理Excel的数据，但是到了Excel以后，展示的方式的控制好像python的插件就有点难以直接控制，而要控制这个最好的方法就是通过api，用VBA控制，因为vba是原生office的自带工具。

我发现python批处理Excel脚本的运行速度跟电脑的CPU有很大关系，跟内存大小关系不大。用我办公室的电脑运行，但需不到6秒，用我宿舍的电脑运行大概需要7秒，用我家里的电脑运行大概需要7.5秒。这是在正常的情况下，如果我的电脑正在执行多任务，这些时间就会说不准了。之所以我说这跟电脑的CPU性能有关，因为运行脚本的时候我盯着任务管理器。发现有段时间Excel的CPU会飙升最大40%，虽然维持的时间很短。不同性能的电脑同样CPU，封顶都会飙到40，这就意味着CPU的核数越多，单核的性能越好，那么这个脚本的运行速度就会越快。6系的i5运行6秒，2系的i3运行8秒，是有差距，但经历过Power Pivot得12秒起，python很爽了。

我觉得这个python脚本还有继续改进的空间，继续努力。

我觉得自己对数据和图表有一种痴狂，但我又不是那种很文艺的人，所以我希望图表是漂亮的，但我不会花很多精力去把图表搞得很花俏，哪怕那看上去会更漂亮。我是一个实用型的人，所以当我看到人家用一大段文字来描述数据的时候我会很自然翻一个白眼，显然那些东西最佳的表达方式是图表，哪怕你不能用图，用表也是很直观的，没有必要用一大段话把明明一目了然的东西搞得很复杂，而且一旦这样做，别人核对起来也非常麻烦，所以是什么样的脑洞才搞不出那样的东西呢？到底那么逆天的模板是谁创造出来的呢？真想把那个人揪出来打一顿，可能一顿还不解恨，要打几顿才能解决问题。创造那种表达方式的人已经够狠了，这样反人类的表达方式居然会被当作模板，一次又一次使用，那些使用的人为什么就不抗议呢？创造者的脑洞很奇葩，追随者根本就没有用大脑，没有用大脑的结果就是在套用的过程中根本不理解作者的意图，然后各种各样的错误就出现了。

数据的表达应该很舒服美观，当你把那些处理得当以后一切都是那么的舒服，但是用一种不恰当的方式强行表达，那不仅仅是影响美观，而且会让人觉得处处卡顿，有时甚至是看半天都不知道那到底是干嘛的，因为没有逻辑性可言，所以一些笔误的东西会层出不穷。最经典的笔误就是把数字倒过来写，比如15写成51。从输入者的角度考虑，这样的笔误很正常，但是从数据本身考虑，这根本是无法容忍的错误，因为一大堆数字的排列方式毫无逻辑性可言，所以出现了这些很明显的笔误，在核对的时候非常难找出原因，因为那不是重复计算或者缺少数字那么简单。核对汇总数的时候，你怎么都想不到那差值是怎么来的，唯有一个一个人肉对明细，最后发现原来是如此低级的错误。可以汇总的数据还可以快速对比出有差别，但是一些时间的数据，而且就只有一个时间的数据发生这种错误简直就在考验你的RP好不好，有没有那么好的运气能找出这样的毛病？

刚刚参加工作的时候，不知道为什么就被叫去做统计。有一次去找领导签名，那是一个很常规的报表签名，他突然问我某些数据，那时毫无准备的我根本回答不上来，然后他就来了一句，你对数字不敏感，不太适合做这个。做这个不是我主动选择，是你们安排的，如果你觉得我对数字不敏感，你完全可以找一个敏感的人去做。现在回想起来，即便突然有一天领导问我同样的问题，我依然会回答不上来。因为我的脑子就不是用来装那种数据的。我不能马上脱口回答那个问题，但是我却可以最快的速度反馈出最精准的答案，我的习惯是把数据抓在手里，而不是一直存放在脑子里。这些年下来，事实证明在这个单位我是干这个的最佳人选。如果是几年前。这个最佳人选是毋庸置疑的，而现在估计我得加上之一这两个字，但是如果综合考虑对全面性的把控，我依然是那个最佳的人选，没有之一。

正是因为我干的就是这个，所以当我看到别人在瞎整的时候，我会条件反射一脸嫌弃。