被一个貌似简单的老技术问题虐了几天
公司的程序需要使用一套外部系统，是必须要用，没得商量的那种，这套外部系统Since 2001年，有将近18年的历史，跟它对接用什么方式？说出来你可能不信，竟然是用生成Microsoft Access(简称MSAccess)文件的方式，没错，就是生成mdb文件，往mdb里写数据，然后丢给这套外部系统。
一个mdb，就是一个数据库，文件型数据库，这也是很多我这个年代来的程序员接触的第一个数据库系统，我记得最早的时候我是用VB(不是VB.NET，那时没有.NET)来访问它的。后来我发觉在比较简单的应用场景里，根本就不需要把数据保存到mdb中，直接读写带一定格式的文件比mdb访问快得多；再后来我发现可以用一些压缩算法来生成更小巧的数据存储文件；再后来我发现xml是一种可读性更好的数据存储方式；再后来我发觉sqlite功能蛮强，不比MSAccess差，由于开源跨平台，应用场景更丰富……总而言之，我没有理由再使用mdb来存储数据了。
若干年后(如果今天看的话就是许多许多年前了)，我去了一家公司，我所在的部门有一套非常重要的程序，用VC++写的，保存数据的文件的格式竟然就是mdb……VC++使用mdb文件的方式相当繁琐且容易出错，我当时觉得十分不爽，于是努力替换掉它，把它之前需要好几兆空间保存的数据压缩到几十K，你没看错，缩小了两个数量级，读写速度飞快，可这并不是一件令我有多少愉快回忆的事情，你想我这么一个新人努力地把人家辛辛苦苦定下来的东西“推倒重来”，人家会怎么想？
又若干年后，命运又跟我开了个玩笑：对不起，虽然已经是2019年了，你还是得继续通过mdb文件交换数据！我：……
现在公司的程序并非2019年才诞生，早有了，使用.NET Framework访问mdb文件比VC++轻松无数倍，虽然如此，我还是想进一步简化工作，我写了一套帮助类库，让程序无需关心具体操作，只需要准备好数据到一个数据字典中，把数据字典交给我的帮助类库，就自动完成了填充mdb文件的操作，非常方便。
在刚过去的2018年里，我干了一件事情，就是将大量的程序从.NET Framework上迁移至.NET Core，这里边自然遇到了不少障碍，其中一个“无法逾越”的障碍就是mdb的生成！
访问mdb数据库的正统方法是OLEDB接口，OLE这是个古老的概念，它基于COM(公共组件模型)，COM的一个重要特点就是：Windows特有，并且，微软没有把它做成跨平台的打算。
我花了很多时间寻找解决方案，未果，看来只能使用一些折中的做法：mdb的生成使用一个公共的Windows服务器来做，我自定义了一套通信规则，编写了生成mdb的服务程序，还提供了一套方便的客户端代码，调用者可以像原先那样，直接一个方法生成mdb，不用关心中间经过了那些网络通信步骤，还是一样的方便。我的程序经过了全面的测试，确认无误，一切看起来非常OK，直到系统正式使用的时候客户反映mdb的生成频频出问题……
马上查看log，发现了这么一个错误：“XXXX正由另一进程使用，因此该进程无法访问此文件。”XXXX便是我要生成的mdb文件，我在生成mdb文件的时候，把模板复制到临时目录一份，名字用GUID，不会重复的，打开，填充数据，关闭，然后将mdb文件返回给客户端。这“正由另一进程使用”是什么意思？我的文件只可能是我这个进程使用啊。
再经过了N次测试，我本地就是重现不出这个问题，只有把程序部署到服务器上才会出现，并且不能每次都重现，我的本地和服务器的差别是IIS Express和IIS的差别，但对IIS这么纷繁复杂的配置，我感觉要从中找出什么端倪来简直是大海捞针，搜索相关信息，无果。(不喜欢Windows服务器很大程度上是不喜欢IIS，对，我就这么旗帜鲜明)
这个问题的本质就是：我关闭了OLEDB的连接后，mdb文件似乎还处于锁定状态，想用程序读取这个mdb文件返回的话就会出错。好，这个难不倒我，我开始寻找一些解决方法。
1，禁用连接池
OLEDB数据库连接默认也是有连接池的，你关闭一个数据库连接，实际上并不是真的关闭它，而是让它返回到池中，准备给下次打开连接时使用。我很快找到了禁用连接池的选项，禁用之，测试，OK，上线！问题依旧。
2，GC.Collect
我虽然开始学.NET的时候就知道垃圾回收，可直接显式地使用这个方法，是第一次，按照微软官方文档的说法，一般情况下并无GC.Collect的必要，调用这个方法能强制释放一些内存资源，也许能强迫数据库真正关闭。但上线后很快发现问题依旧。
3，外部复制
经过尝试，我发觉竟然可以用Windows的copy命令来复制被打开着的mdb，我灵光一闪，对，服务器也可以这么干，于是关闭mdb连接后调用了外部的copy命令，复制生成的mdb文件，再把复制好的这个文件返回给客户端，perfect！果然，客户那边不再反映什么问题了。这个难题难道就这么解决了吗？图样！第二天，客户找到我们，说我们生成的mdb文件缺数据！这是大问题！甚至比生成不了mdb的问题还要打，前者的话他们可以再次尝试，而后者则可能带来业务上的数据错误。我马上到服务器上看，对比了生成的临时文件，我确认了问题还在！我这样copy被锁定的mdb文件是未写入完全的！有缓存，我要想方法禁掉缓存。
4，尝试禁用OLEDB的写入缓存
Windows在将数据存储至磁盘上的时候，其实都不是直接写磁盘，而是使用了一种缓存机制，先写到缓存，再缓存到物理磁盘，这样无疑提高了调用的速度，所以才有了Flush的概念，Flush就是立即将缓存的数据冲掉，也就是强制立即写入磁盘，而我现在要做的，是禁用掉这个缓存，让对mdb的操作更直截了当地写到磁盘上，我费了不少力气，在微软的官方文档上找到了这个选项，但是这回更惨，本地测试报错，原因是并不支持这个选项，可以理解为OLEDB只是接口，究竟支不支持，还得看引擎，访问mdb的这个Jet引擎貌似不行。
5，更换引擎
Microsoft.Jet.OLEDB.4.0变更为Microsoft.ACE.OLEDB.12.0，嗯，具体的安装文件可以在微软官网下载到。ACE.OLEDB.12.0这个应该更新一些，结果还是不行，并且一样地不支持上一点提到的那个选项。
6，等待解锁
既然上面都不是办法，那我就用重试的机制，读取文件失败，抛出异常，捕捉异常，间隔两秒钟，重试读取，再失败，再重试，最多尝试两分钟，两分钟文件总归写入完成了吧？结果还是不行，2分钟还是无法读取，且这回客户那边有些受不了这样的漫长等待了，客户问能不能恢复之前那个有数据缺失的版本？至少能用。
7，到底有没有.NET Core下的访问mdb文件的第三方库
微软不提供支持，我找第三方行不行？很显然，我之前找过，但这次我打算更认真仔细地找。最后找到了这么一篇文章：《Using Microsoft Access in .NET Core》，写于2018年11月，还挺新，难怪我之前没找到。文章提到了，.NET Core可以用ODBC接口访问mdb，但微软只提供了Windows版本的ODBC引擎，Linux版本的却没有提供，想在Linux环境下直接用ODBC访问mdb的话得找第三方的方案，这里就有一个：Access ODBC Driver，但并不免费，并且费用还不低。
看吧，老板是肯定不会同意让我去买这么一个东西的。
8，ODBC
好，既然上面提到ODBC，那我就切换到ODBC接口去，不用什么OLEDB了，过程进展还挺顺利，除了对MSAccess的类型的理解有少许不同外，ODBC和OLEDB接口差别很小，我很快就弄完了。测试，上线！嗯？这次居然貌似可以了。客户用了一天下来，没再发现什么异常，我检查了日志，也没再出现“正由另一进程使用”的问题。这次难道真的好了吗？我已经有点焦头烂额了。
好吧！至少到现在没再出什么问题。尽管我这几天里并不只在处理这个问题，但这个问题却是这几年来最让我掉面子的问题了。第一它很老，第二它看起来很简单，第三它似乎有很多种变通方法。但实际搞起来却被它虐了许多回合，实在令人唏嘘。
半年前一个许多年前的老同事突然QQ我，说他在解决一个技术问题的时候搜到了我的博客，于是想起了我，挺怀念当初跟我学技术的日子，因为2018年了，他居然在做VB，没错，不是VB.NET，是VB，本文开头提到的那个VB，这是一套极其古老的系统，他还在维护着，我能理解他的苦闷，但这就是生活。
