我的天

虽然写Excel VBA已经有好长一段时间，但实际上对一些很基础的知识我还是不扎实的。比如ThisWorkbook和ActiveWorkbook到底是怎么指定的。光说这两样我好像明白，但是当我要使用的时候就感觉老碰钉子。这个东西使用不当，就会经常被弹出错误说某个工作簿里面没有某个工作表，或者说某个工作表已经存在了，不能再新建。不同的写法意味着同样的VBA脚本发起的那个工作簿不一样，有可能要在打开有数据的那个工作簿里发起，又或者直接是在VBA脚本所在的工作簿发起，不需要打开源数据工作簿。除了这个以外，还有就是当刷新数据要放在你已经建立的工作簿的超级表里，该如何删除超级表之前的数据？有两种选项，一种是把数据全部清空，这种情况不改变超级表的格式的，之前已经使用的行会继续存在。这里用的是clear命令，另外一个则是用delete的命令，那样的话原来工作表里面的数据全部删除，只剩下最后一行。二者的差异就在于，如果是用delete命令，如果那个超级表下面还有数据的话，那些东西将会上移，如果你又在那里插入新的数据，可能就会乱成了一团。所以如果在一个工作表里，你安排了很多个超级表，而你又确认那些超级表的格式不会改变，基本上也就那几行，又或者你不确定到底有多少行，但你能确定行数肯定不会超过多少行，这样的话，当你要用VBA把刷新的数据同时写入这些超级表的时候就应该用clear命令，这样的话，刷新的数据就可以指定从哪里开始。如果在这种情况下，尤其是工作表的下面还有一个工作表，你用了delete命令那么当你清空数据再写入数据，下面那个超级表对应的那个区域肯定会乱来。

没人跟我说过这些细节，这是在我摸索的过程之中，经历过一次又一次撞板之后得出的结论，所以如果可以的话，超级表你可以在旁边建超级表，但你不要在超级表的下面建超级表，尤其是那种你根本说不准上一个超级表到底有多少数据的情况下。多建几个工作表，在不同的列起始不同的超级表，一点问题都没有，但在很多人的固有思维里面，Excel就只是一个放表的工具，上下左右都可以放，但是就数据处理的便捷和难易程度来说，超级表的放置其实是得遵循一定规则。

自从知道了ADO+SQL之后，我就经常把这两个东西作为我最大的杀器，把经常使用的Excel表当数据库。但Excel始终不是数据库，最大的差别我觉得是虽然ADO+SQL可以用类似数据库的方式理解Excel表格，但因为Excel表格可以变换不同的格式，所以当在某一列理论上都是数字的那里突然意外有一格被插入了文字，那么ADO+SQL进行转换的时候就会出毛病。刚好你又对那一字段进行了分组汇总，那程序必然进行不下去。通常情况下，人肉很难发现这个问题，因为不知道在哪一行，突然插入一个文字是个意外。一般情况下，调用ADO+SQL把工作表里面的区域读取格式化的时候没有理会超级表的范围。如果有进一步的限定，实际上是可以设定范围的，但一直以来我都没有进行这个行的主动限制。

掌握了SQL以后我觉得Excel自带的那些公式实在太复杂了，参数很多、形式变来变去，有些用乘号，有些用加号，有些用*。

谈Excel，索引肯定是离不开的话题。从经典的lookup到用得很多的vlookup，到index+match，再到vlookup的升级版xlookup，所有的这些都是为了让搜索更方便。xlookup相对vlookup来说的确已经进步了不少，但无论是这些搜索的函数也好，其它按条件汇总的函数也好，总是有一些支持选择列，有一些不支持。之所以有支持和不支持之分，其中一个很重要的原因是支持选择列对写公式的那个人来说很方便，但关键是选择列可能严重影响搜索的性能。感觉上明明很简单的东西却要加载很长一段时间才能出结果，那个加载时间，甚至让你觉得是不可接受的慢，所以在使用这些索引函数的时候，绝大多数的教程都会提醒你数据源得用绝对引用。引用一个确切的范围，即便你把那个范围搞得很宽也行，但是引用一些空白行，又会导致一些意想不到的事情发生，尤其是对某些经典函数来说就会出错。当然，出现这种问题可能是因为我道行不够，如果是高手操作，什么问题都不是问题。

为什么搜索出来的结果可以动态显示，可以显示多行，但是被搜索的内容必须得用绝对引用呢？为什么教程里除了整列选择就没有一些动态确定索引范围的方式呢？隐隐之中我觉得新出现的公式应该可以做到，因为新出的那些高级函数出来的结果都是很动态的。虽然实际上近几年我已经很少关注学习那些新出的东西了，但是我还是有那么一点印象的。

在超级表里面使用公式，引用的单元格不再是经典的单元格名字，而是超级表的列名，前提是你用的那种公式不涉及跨行，如果跨行了，我好像没发现超级表能有什么超级功能，但是如果用超级表的偏移定位函数，的确能实现到达上下行。

xlookup是个比较新的函数，所以它能不能把索引的范围定为超级表的某一列呢？我发现的确是可以这么干的。如果有两个超级表，我要用超级表A作为索引，超级表B的某些数据作为查询条件。那么我在写xlookup公式的时候，我就可以完全用超级表的快捷引用方式。暂时我只尝试过一些比较简单的数据，出来的效果非常好，比我整列引用速度快很多。虽然xlookup是支持整列引用的，但那样的话很慢，而之所以很慢，我估计一个很重要的因素是xlookup只在高级的Excel里面使用，而高级的Excel文件又比低级的Excel文件行数多很多。其实我一直搞不懂为什么同样是Excel的公式，有些函数可以整列引用，有些却不行。有些虽然可以整列引用，但实际上效率不高。用同样的公式，一个引用的是超级表，一个引用的是整列，同样是xlookup，出来的结果就很有差别。如果你在超级表B更新了数据要索引超级表A的内容。引用整列的那个在你把数据粘贴到超级表B的时候，就已经会把你卡得痛不欲生。也正是因为有这种痛不欲生，所以以前当我要引用很多数据的时候，我选择的是用Power Query做一个后台匹配。因为如果用前台做这种整列的索引，整个文件哪怕不是互相影响的那些表，也会变得奇慢无比。在这里我巧妙的地方是利用了超级表的动态性。以前，如果要动态应用可能会增减数据表格内容的时候，好像需要套用offset。

当我要指定某片数据区域的时候，Excel其实是能感知其连片区域范围的，但只是在用公式索引的时候没有给用户一个直截了当的方案而已。

追加查询这种事，2句话搞定，这实在让人太震惊了，但实际上，两句话里其实暗藏了许多玄机，高手用一句话完成了几个步骤的事。能做到这样，绝对是因为对函数这种东西了如指掌。

source = Table.SelectRows(Excel.CurrentWorkbook(), each List.Contains({“表1″,”表2″,”表3”},[Name]))[Content],
result = Table.Combine(source)

Excel.CurrentWorkbook()这种东西通常我们都是后面搭配{[Name=”某表”]}使用，那是点名使用，一次只能一个，但实际很多时候合并工作簿都是里面同型号的表全部合并，如果全部都用这种，得列多长的清单。高手的代码里，还可以把List.Contains变成Text.Contains，如果是list那就是点名要哪些或者不要哪些表，如果是text那就是直接筛选表的关键词，包含哪些关键词或者不包含，各有所长，都能实现。如果命名很规律，那是简单到爆炸的事，即便命名不规律，也能用排除的方式忽略某些不想合并的表。你或许会说，既然是合并工作簿，为什么不直接用从外部文件的工作簿获取呢，那样直接就到位了，选择的时候也很自由，因为那是可以可视化操作的，而且不需要实现把工作簿加入到表，我觉得最根本的区别在于移动文件的时候，外部获取你还得更换数据源，当然了，这个可以通过自动获取数据源地址的方式实现，但直接CurrentWorkbook是最没有烦恼的。要把工作簿里所有表都变成超级表，这在收集和整理表格的时候其实也是有难度的。所以这种一次性用CurrentWorkbook包揽工作簿的方式我觉得最好不要超过10个，3-5个是最合适的。通常，如果用追加合并，可视化系统生成的是Table.Combine{{“AA”,”BB”,”CC”}}类型的多个表格列表，而高手的代码里，source其实就是一个表格的列表。轻描淡写之前，处处暗含玄机。要做到这样得非常清楚每个函数需要什么数据，可以生成什么数据，玩弄的正是表格、列表、记录的互相转换。

同样是contains的功能，list的是后面跟前面对，对上就true，但text是前面跟后面对，对上就true。对我这种初学者来说，这是很迷糊的事，谁先谁后到底是最定义这些公式的，为什么要这么郁闷呢！有这种吐槽大概因为我不熟悉，对高手来说估计是没有疑问的。到底建立这些M函数的时候，他们是怎么分配工作的呢？类似的功能一个人负责？某个统领下的函数一个人负责？最后有没有对“.”以后相同，功能类似东西做比对呢？对我这种懒人来说，类似的函数能用复制粘帖修改就不会用重写这一招，但显然，他们的脑洞估计不是。

看书对照操作是一回事，融会贯通又是另一回事。