我的天

office的ADO+SQL跨表查询挂掉已经一周有余。虽然在这期间微软又出了更新，但据说那个更新并没有把这个问题解决掉。就在这周二，有人在论坛上说wps也中招了。之前一直好好的，但突然间就中招了，他并没有说错误代码是什么，是不是跟我们遇到的相同，但可以肯定的是，wps也中招了。office跟wps是两个不一样的东西，所以如果两边都中招的话，就意味着这个bug可能出在windows上，因为绝大多数情况之下，大家都是用windows系统，可能是win10也可能是win11。我用的是win10，所以我用回滚的方式就暂时没有问题了。之所以这样，是因为我没有参加安全延长计划，所以理论上我的win10是不可能再更新的，但win11不一样。谁知道那个wps中招的电脑是不是win11，是不是周一或者周二进行过自动更新。更新那些东西有时候会让你重启，所以你有感觉，但有时候是静默的，所以你根本不知道已经更新了。

就在网友的wps宣告沦陷之前，Office2024批量版也中招了，但是他中招的时间比我们这些当前频道零售版的晚一点点。从他的那个版本号可以看出，他的office已经更新到最新版本，就那个时间来说，跟让我们中招的那个版本差不多，所以我猜测那个版本更新搞倒了一大片的人，无论你是零售版当前频道，beta频道，企业半月更新频道，又或者是批量版。唯一有可能不受影响的是Office2019，因为跟win10一样，理论上那应该已经被微软停止支持，但如果那个Office2019装在win11的系统上，这又变得有点难说。Office2024批量版中招的那个人。他还不知道自己已经更新到最新版本，但从截图我一眼就看出，他没有禁止office更新，同时版本号也预示着他的确已经被自动更新了。office的更新跟windows的更新有些许不一样，因为office除了一些非常大的版本你会有感知以外，其它都是静默更新。

当wps网友宣告他的也沦陷以后论坛的大佬出来了，论坛的大佬测试一番说，最新版本的wps没有问题。wps也是比较神奇的存在，最新版本到底指的是哪个呢？个人版？企业版？专业版？付费版？还有一些针对特殊群体的版本。简单来说就是wps版本的复杂程度我觉得跟微软的office有得一拼。可以肯定的是，office的版本虽然多，但是你还是能在网上找到各种版本的来龙去脉，但是wps能不能查到我不知道。跟office不一样，很多版本的wps还停留在32位。所以到底中招那个人在用什么版本的wps？是32位的还是64位的？是不是针对特殊群体的版本？这都很难说。对普通人来说，哪个版本不中招用哪个版本就完了，但是对一些电脑数控的单位来说，无论是回滚office还是回滚wps，又或者是装另外一些版本的wps都是很困难的。

方法有很多，但是很多时候是人的所谓“安全”限制了我们的想象力。

我大概是从2023年夏天开始用各种方法进行跨表查询的，最后留下来主力是ADO+SQL。在这两年多的时间里，我感觉经历过三次说不准什么毛病的毛病。

第1次是不知道为什么，部分VBA运行不了，但貌似只在我的电脑上不行，在别人的电脑上可以，而我的电脑可能重启一下又可以了。这个现象很奇怪。在我办公室的电脑出现概率比较高，因为用得最多，家里的电脑偶尔也会这样，但无论是哪一款，可能重启一下就好了，但也可能重启也不好，因为这个是偶发性的，当我想他重复出现的时候他不出现，当我不想他出现的时候它就来了，所以很无奈，什么都没做过一段时间它自己又好了。当时我没有去深究这到底是什么原因。因为复现效果不好，也不知道该如何描述，但从后来的情况看来，可能这是因为windows或者office的某个更新引发了某个bug，但那个bug在往后的某次更新里又基本上被修正了回来。

第2次出现状况是在今年的夏天。情况就是一直使用的那些查询文件突然需要很长时间才能完成查询，查询是可以完成的，但是需要的时间比正常情况之下多很多。那个时间就比较神奇，是12秒的倍数，这个12秒不同的电脑可能不一样，我办公室的那台电脑是12秒，我家里的那台电脑可能不是12秒，可能需要更长的时间，因为家里那台电脑的cpu性能差一点。为什么会这样呢？这一次我是有研究过的，也在论坛上跟网友们分享过，他们也给出了临时的替代方案。临时的替代方案也不是不行，反正我就一直用那个替代方案，顶多是一开始的时候很麻烦，得把数据源挪出查询文件。微软到底是花了多少时间才修复那个bug我不知道，因为我已经按照替代方案的指引把我的文件都整理了一遍。以至于那个bug根本没办法继续伤害我，但某一次我又闲着，打开测试文件的时候发现那个bug没了，微软不知道什么时候修复了。

接下来就是这一次。这个bug和上一个bug我感觉有点类似，起码我用同样的测试文件就可以把它们都揪出来。上一次网友还可以给出提供替代方案。在不改变office版本的前提下，依然能让查询正常的运行，但这一次，简直就是个未解之谜，而且是封杀掉所有跨表查询。所以这一次好像唯一的做法就是暂时回滚，但回滚了以后，我怎么知道微软什么时候修复了那个bug呢？难道我还要在电脑里装个虚拟机，虚拟机那里用最新的版本？我没办法跟他们耗，首先是因为不能跨票查询就直接把我搞死了，其次是这件事情发生在年末，我没有时间耗。跟Excel打交道的人，年底的数据是最让人疯狂的。所以大概我就只能寄望于其它使用365或者Office2021售版的人给我继续做测试。当他们使用的当前频道可以正常运行测试文件，那么那个时候大概我就可以把365的禁止更新取消掉了。

为什么2025这种bug会出的这么频繁呢？其实我也不意外，因为不仅仅是office，windows的bug也很多。win11几乎每次更新都会带入幺蛾子，现在的微软已经不是以前可以完全信任的巨硬了。

用之前的文件做测试以后，其实我已经基本锁定这一次ADO+SQL查询失败的原因。我个人猜测是因为进行了某项封堵，只允许指针到达的那个地方进行数据格式化查询，另外那个用绝对地址引用的东西没办法转化为同样的数据库。这个现象只是从我的电脑里面发现的，我不知道其他人是不是也这样。我的那个测试文件刚好对数据源进行了各种各样的枚举，所以刚好碰巧可以用来测试。如果有人在6种情况下都可以顺利运行，基本确定他的office是不受这一次升级影响。非常有可能他一直停留在某个版本没有升级，也可能他使用的不是当前频道，而是批量版的长期频道或者beta频道。因为我的电脑用的都是当前频道，所以我需要大家一起来测试不同频道是不是同样存在这个问题。我用的是Microsoft 365其它版本的office，比如2021、2024或者2019会不会也受到影响？我个人感觉可能2019没有受到影响，因为和win10一样，在2025-10-14开始就已经停止支持，但因为我的win10在11月依然进行了两个升级，所以2019会不会也受到波及我觉得有点难说。

帖子发布了一天之后，终于迎来了大佬的关注。可能大佬正在使用的那个电脑也受到了这个的影响，而他的电脑又或者他使用的office可能不仅仅是一个版本，所以他可以明确指出某个版本的office不行，但是某个版本可以。他的解决方案是要不等待微软更新解决这个bug，要不重装回旧的那个版本。哪个版本可以他也已经说出来了，装回那个旧的版本以后你还得禁止自动更新，否则还是不行。装回旧的版本我感觉是一定可以解决问题的，但是要怎么装回旧的那个版本呢？登录微软的账号，365那里的确有离线安装包，但是下载安装得花费很多时间，而且那里只会给你提供最新的版本，除非之前就已经把旧版本的离线安装包存下来，否则几乎无解。

大佬都这样说，意味着这一次的bug估计不是修改某个注册表就能解决的。几个月前的那个bug，如果把VBA的文件从xlsm降级为xls，也就是2003版本的那种Excel文件，就能避免查询时间很长的问题。如果只是一个查询文件，降级没有问题，但如果那个文件里面带有大量的格式，这样的降级就会让那个文件面目全非。这一次我也尝试过把xlsm文件降级为xls，没有效果。

之前我从未试过把office降级，但是我曾经试过卸载windows的更新文件。在控制面板里就可以卸载windows的部分更新文件，但office的在哪里呢？显然不在那个位置，于是我就去搜索如何把office回滚到旧的版本，结果出乎意料原来如此简单。

打开office任意软件-文件-帐户-更新选项-禁止更新
windows搜索cmd，管理员模式打开
粘贴
cd %programfiles%\Common Files\Microsoft Shared\ClickToRun\
回车
粘贴
officec2rclient.exe /update user updatetoversion=16.0.19328.20244
回车
等待

16.0.19328.20244是Microsoft 365当前频道的版本，回滚后SQL跨表查询恢复正常。更多office版本请搜索微软官网。

365更新版本的官方链接是：https://learn.microsoft.com/zh-cn/officeupdates/update-history-microsoft365-apps-by-date
更多版本的做法请看：https://www.bilibili.com/opus/1136898381847724034

一波操作后就可以了。我选的时候2510的大版本，让我出状况的是2511版本，在我印象之中，北京时间2025-12-14之前我一直没有问题，而让我出问题的那个2511是属于大版本里面的第2个版本。我选择跳过了2511的第1个版本，为的是更稳妥一些。当我把2510，19328.20244装回去以后。点击查询，VBA正常了，接着我赶紧把这个方法让同事也操作一遍。因为SQL的跨表查询无法进行将严重影响我们的工作。试验证明她的电脑也没有问题了，我们两个的版本都是365。

之后我赶紧回到ExcelHome论坛，把这个简单的回滚方式分享给大家，跟卸载office重新安装比起来这个回滚简单很多，速度也很快，只要你的网速靠谱。因为我感觉其实对office来说，它内部就是卸载了一个补丁，然后再填补一些东西，而并不需要整个office都翻新。单位的网络是很神经，但从开始回滚到结束，大概花了不到20分钟。最长的时间都用在了下载上面，安装很迅速，安装完成以后。365的激活是正常的，我的账号是正常的，也就是说直接开箱使用。查看版本就可以发现已经从2511退回到2510。

本来我的办公电脑是win10，没办法继续更新下去，我觉得让365停止在一个合适好用的版本是一个比较安全的做法。

到底是什么原因导致了这个ADO+SQL查询一夜之间就失败呢？首先我把这个错误代码和错误描述拿去搜索，无论是bing还是百度，历史网页都没有太多有价值的信息，同时我也搜索了24小时之内的结果。两个搜索引擎都没有找到些什么，也就是说发现这个问题的人估计还不多。奇怪的是，当我用国际版的bing的时候，发现居然没办法限制搜索结果为24小时内。不知道如果用Google会有什么效果，但显然在上班时间我不想冒那个风险用Google。

搜索没办法得到结果，我就去ExcelHome的论坛VBA板块看一下，果然也是没有人发帖，我觉得如果有人在那里发帖了，搜索引擎估计能捕捉到，但显然没有，于是我就当了吹哨人。一开始我就把已经发现的情况描述出来，比如是什么时候开始发现不行的，有什么错误代码有什么错误描述。

一开始我的帖子就只有那些东西，但之后我又拿出了几个月前用来测试文件打开的时候查询很慢的那个文件，把所有选项都点了一遍，结果发现6个选项里面只有2个选项可以完成查询，其余的那些都不行。对比成功查询的那两个，发现里面其实我只做了一个cnn的指向。其它实际上用的是两个数据源，虽然最后输出的数据可能只是指向其中一个。这个情况很尴尬，意味着用经典传统写法的cnn是可以正常查询的，无论数据源在查询文件里面还是在外部，无论那个文件是关闭的还是打开的。之所以要用ADO+SQL，就是为了可以方便快速地跨文件查询。现在这个指针只能是一个，以前除了指针那个以外的其它可以用绝对地址引用到达，现在那些用绝对地址引用的好像都不行了。遇到这个情况我很绝望，这就意味着我的那些查询文件一夜之间几乎全部都失效了。如果只是一个文件，那还好，但显然我绝大多数的查询都是跨表的，也正是因为有跨表这个功能，才让它们有价值。偏偏微软不知道进行了什么更新，把这个给废掉了，我不知道他们什么时候才能修复这个bug，但我觉得没有半个月估计搞不定。因为首先他们得意识到有这个bug，然后才着手去研究是什么更新导致了这个bug。马上就年底了，各种各样的数据报送要求接踵而至，在这个节骨眼上你给我干出这种bug，我实在非常无语。

发现了这个只要跨文件就失效的问题以后我马上又去论坛那里补充更新。补充更新过了一段时间以后，我就发现有人回帖了。他的状况跟我一样，无端端那些联合查询失效了，他用的不是Excel，他是用Access，也就是全套office的这个用法都撞墙了。

有人说不行，也有人说他没事，仔细看他们的那个office，我感觉没挂的那个用的是beta频道，而我们这些挂了的人我感觉是用零售版的当前频道。批量版的长期更新估计还没有状况，因为他们要过上很长一段时间才会有更新，相对于零售版的更新来说，那些批量版的更新会稳定一些。之所以要发帖，是因为我要看一下到底有多少人和我一样的，我知道论坛里面有大佬，他们遇事比我多，他们可能会想到一些我想不到的解决办法。我不知道他们有没有遇到这种问题，有可能他们没遇到，因为即便装的是零售版，他们通常会禁止更新，更多的可能是他们用的是批量版。但因为他们是热心的大佬，看到小菜鸟在那里求助，他们不会坐视不管，这样的话，我们这些中招的人离得救就不远了。

要解决专业的问题，得去专业的地方吸引专业的人。

昨天说到一个很简单的SQL语句引用的数据库就只有一个字段两行记录，居然需要24秒才能得出结果。这让我觉得非常不可思议。首先可以肯定的是数据量非常少，为什么会出现这种问题呢？那只能是连接方面是不是出了什么故障，也不能说，那是失效的，因为的确还能查询得到想要查询的东西。在我测试的那个宏里面。我引用了两个文件，一个是外部文件，一个是内部文件。外部文件是含有比较多的数据，而内部文件，也就是我一开始说的那个只有两条数据。我感觉如果我的SQL再厉害一些，我对VBA再熟悉一些的话，那个内部文件可能我就不需要引用了，我直接就在VBA里创建一个数据库，然后把两条数据给写进去，用完以后就删掉，但显然现在我还没有很大的把握，一定能完美地做这件事情。把我某个文件里面的数据转化为数据库的数据我又烂熟，所以我采取了现在使用的这种方式。

ADO+SQL的这种方式，因为我们是跨表引用，所以意味着数据肯定来源于多个文件。他们有可能是同一个工作簿的不同工作表，也有可能是在不同的工作簿里。对我来说，只要是在一个工作簿里，那么起码一开始设定指向的时候就得有一个数据源。最经典的方式引用的那个数据源在使用数据的时候，在from后面不需要进行进一步的引用，其它的就得麻烦一些。我的第一个反应是，是不是引用数据的那个语句出现了变动呢？比如说现在我用的是Excel12。在数据源引用方面，我又折腾了一番，发现好像还是那样，没什么进展。会拖慢查询的那个数据源，我甚至把它放到了主数据源里，结果发现还是很慢，于是这就排除了是数据源引用语句变动导致缓慢。

所以这到底是什么原因造成的呢？因为我有很多个跨表引用的查询。有些查询是内部数据外部数据都有，有些只有外部数据，经过测试后我发现好像只有引用了内部数据的查询才会变慢。

为了证明我这个想法，星期三的晚上我编造了一些数据做测试。主要原理就是研究是不是数据源的关系导致这种变慢。一开始我的设计就是一个排列组合的方式，因为我默认的数据引用是要跨表的，所以我把数据源根据内内、内外、外外和外内这4种方式测试，实际上内内和外外是一回事，也就不需要进行两个引用了，所以我又把那两个东西拿了出来，同样进行测试。结果让人有点吃惊，凡是有内部数据参与的查询都会变慢。我测试的数据就只有一个字段几条记录，内内和内外需要12秒，外外需要0.1秒，外内需要24秒。这就能解释为什么我的那些变慢的查询起码都要24秒才能出结果。因为我永远把内部数据放在后面。究其原因是因为我设计那些查询的时候，我后来才想到要在那个查询文件里面搭一个加脚手架，把一些基础的东西加上去，在这种情况下我加得最多的是日期表。

关于这个测试的来龙去脉以及最终的结果，我在ExcelHome里面做了一个详细的帖子，在这里就不再具体阐述了。

折腾了这么一番以后，我发现这个锅还真不是我整出来的。造锅的是微软，不知道更新出了什么状况导致了。

Excel用多了，不知不觉我也居然能挑出微软的毛病。