ACCESS数据库很方便，为什么不实现一个内存版的数据库？比如创建MDB时实际保存到内存区域，再用内存映射为文件句柄，然后就要吧进行读写操作了。不需要任何新的SQL等技术，唯一的区别就是把从硬盘读写变成内存读写，如果硬盘占用10MB，内存可以预分配50M空间，插入数据可以不断扩展虚拟文件的大小。只不过数据库文件锁也要做内存文件，基本不需要多用户访问。
abc.mdb , abc.ldb
不过现在硬盘也便宜了，怕高频访问掉速的话也可以用RAMDISK虚拟内存硬盘，或者使用SQLITE,SQL SERVER内存数据库
VB6 ADO确实没有原生支持轻量级内存数据库的实现，但可以通过技术组合模拟类似功能。
技术可行性分析
-
内存映射文件替代方案
VB6可通过Windows API创建内存映射文件，将虚拟地址空间映射到物理内存区域，配合ADO的Jet引擎可实现内存级数据操作。但需手动处理文件锁（如.ldb）的内存模拟，需通过互斥量或信号量实现并发控制。
-
Access内存版的技术限制
Access的MDB文件设计基于磁盘存储，其页式管理、事务日志等机制与物理文件强绑定。内存映射虽能加速IO，但无法消除Jet引擎的磁盘依赖特性。微软官方未提供纯内存模式，因需重构存储引擎架构。
-
ADO的临时解决方案
可通过
Recordset对象的adUseClient游标类型配合断开连接模式，将数据加载到内存中进行操作，但本质仍是客户端缓存而非真正的内存数据库。
未实现内存版的原因
- 架构设计目标差异：Access定位为桌面单文件数据库，强调易用性而非高性能内存操作
- 技术复杂度：内存管理需处理垃圾回收、指针安全等问题，与VB6的COM架构存在兼容性挑战
- 市场需求不足：VB6时代企业级应用更倾向SQL Server，轻量级场景直接使用Recordset已满足需求
替代方案建议
-
SQLite内存模式
可通过第三方驱动调用SQLite的
:memory:模式，实现纯内存数据库操作。 -
自定义内存管理器
利用
GetMem/CopyMemory等API预分配内存区域，模拟MDB文件结构。 -
现代技术迁移
考虑升级至VB.NET，利用
DataSet或Entity Framework Core的内存数据库特性实现类似功能。