在使用Access数据库（.mdb或.accdb文件）的多人共享环境或者ASP、VB等程序开发场景中，经常有人遇到这样一个报错提示：无法保存；正被别的用户锁定。这个错误在编辑表结构、修改窗体或保存查询时尤其容易出现，严重时数据库文件会变成只读状态，任何修改操作都无法完成。要彻底解决这个问题，首先需要弄清Access的锁定机制是怎么工作的，再按照可能的原因逐项排查。
Access的锁定机制：ldb文件是怎么来的
Access是典型的文件型数据库，它不像SQL Server那样有独立的服务进程管理数据，而是直接依靠操作系统对文件的操作来实现并发控制。当一个用户打开mdb或accdb数据库时，Access会在同一目录下自动创建一个与数据库同名、但扩展名为.ldb（新格式accdb对应的扩展名是.laccdb）的锁定文件。
这个ldb文件本质上是一张“座位表”，里面记录了当前哪些计算机、哪些用户正在使用数据库，以及各自锁定了哪些页面。所有访问该数据库的用户都必须对这个ldb文件拥有读写权限，因为Access要靠它来协调并发访问。当最后一个用户正常关闭数据库时，ldb文件会被自动删除；一旦用户异常退出（比如直接断电、任务管理器强杀进程、程序崩溃），ldb文件就会残留在磁盘上，锁定信息得不到清理，下一个用户打开数据库时就可能被误判为“正被别的用户锁定”。
理解了这一点就会明白，报错的本质并不是数据库坏了，而是Access认为仍然有人占用着文件。排查方向也就清晰了：要么是确实还有连接存在，要么是锁定信息没有被正确清除。
常见原因一：数据库连接没有正确释放
这是程序开发中最典型的原因。很多老系统用ASP、VB6或者Delphi通过ADO连接Access，代码里打开了Connection或Recordset对象，却没有在用完之后及时关闭并释放，连接会一直挂在数据库文件上，ldb文件迟迟不消失，其他用户自然无法保存修改。
典型的错误写法如下：
'错误示例：打开了连接却没有关闭
Dim conn
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\data\sys.mdb"
Dim rs
Set rs = conn.Execute("SELECT * FROM users")
'处理完数据后没有 rs.Close 和 conn.Close
'连接一直保持打开，ldb文件无法释放
正确的做法是每次操作完成后显式关闭对象并置为Nothing，养成良好的资源释放习惯：
'正确示例：及时关闭并释放
Dim conn, rs
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\data\sys.mdb"
Set rs = conn.Execute("SELECT * FROM users")
If Not rs.EOF Then
Response.Write rs("username")
End If
rs.Close
Set rs = Nothing
conn.Close
Set conn = Nothing
另外，如果数据库放在Web服务器上供ASP程序访问，IIS应用程序池的回收策略也会影响连接释放。连接池中的连接可能长时间保持打开状态，必要时可以在连接字符串中加上Jet OLEDB:Database Locking Mode=1调整锁定模式，或者直接回收应用程序池强制释放所有连接。
常见原因二：网络共享目录的权限问题
Access放在网络共享目录（如文件服务器或NAS）上时，权限配置不当是引发锁定报错的另一个高发原因。前面提到，所有访问者都必须对数据库文件和ldb文件所在目录有读写权限。这里特别强调的是目录权限，因为ldb文件需要随时创建和删除，如果用户只有对mdb文件的读写权限，却没有对文件夹的“修改”权限，ldb文件就创建不出来或者删不掉，Access的表现往往就是锁定错误或数据保存失败。
排查时需要确认以下几点：第一，共享权限和网络权限（NTFS安全权限）都要检查，两者是叠加生效的，取最严格的那个；第二，如果是IIS或某个服务账户访问数据库，要确保该账户（如IIS的匿名账户IUSR或应用程序池标识）拥有目录的修改权限；第三，杀毒软件或同步盘（如OneDrive、坚果云）可能会临时锁住mdb文件进行扫描或同步，建议将数据库文件目录加入排除列表。
还有一种容易被忽略的情况：有人用Access打开了数据库做设计修改，然后最小化窗口去干别的事，窗口保持打开状态时连接一直存在。这时可以在服务器上打开“计算机管理”中的“共享文件夹”，查看“打开的文件”列表，就能看到哪些用户正在占用数据库文件，必要时可以直接右键关闭对应的打开句柄。
常见原因三：ldb残留文件与数据库损坏
如果确认没有任何用户和程序在使用数据库，但仍然报锁定错误，几乎可以肯定是残留的ldb（或laccdb）文件在作怪。处理方法很简单：先确认所有人都退出了相关程序，然后在数据库所在目录找到同名的ldb文件直接删除即可。ldb文件只是锁定信息，删除它不会影响数据库本身的数据。
如果ldb文件删不掉，提示“文件正在使用”，说明仍有进程占用，可以在服务器上通过任务管理器查看msaccess.exe进程，或者在命令行中执行以下命令查找占用：
rem 查找占用数据库文件的进程 openfiles /query | findstr "sys.mdb" rem 强制关闭指定文件句柄（需先运行 openfiles /local on 并重启） openfiles /disconnect /id 文件ID
删除ldb后如果问题依旧，就要考虑数据库文件本身损坏的可能了。不正常关机、网络传输中断、多个用户并发写入冲突都可能导致Jet数据库引擎内部结构损坏，损坏的数据库会表现出各种诡异行为，锁定错误就是其中之一。此时可以对数据库执行压缩和修复：打开Access，在“数据库工具”选项卡中点击“压缩和修复数据库”，或者用命令行方式处理：
rem 通过命令行压缩修复数据库 "C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE" ^ D:\data\sys.mdb /compact
修复前务必备份原文件。如果压缩修复后仍然频繁出现锁定问题，建议检查数据库的默认打开模式：在Access选项的“客户端设置”中，将默认打开模式设置为“共享”，避免某台机器以独占方式打开了整个数据库。程序连接时也可以在连接字符串中显式指定Mode=Share Deny None，确保采用共享方式打开而不是独占锁定。
日常预防与替代方案建议
Access的文件级锁机制决定了它在高并发场景下天然脆弱，日常使用中可以做一些预防工作：定期执行压缩和修复，控制同时编辑数据库结构的人数，重要数据定期备份，程序代码中统一使用连接池并保证异常分支也能释放连接。
如果系统访问量持续增长、锁定冲突已经影响正常业务，就应该考虑迁移方案了。将数据迁移到SQL Server或MySQL这类真正的服务端数据库，由数据库服务统一管理锁和事务，Access可以继续作为前端界面通过ODBC连接，这样既能保留现有窗体和报表，又能彻底摆脱文件锁定的困扰。总的原则是：小型单人场景用Access没问题，多人高频写入的场景尽早升级，才是治本之道。