Cannot open any more databases – Another Access Bug

Software Bug

It’s turning out to be a rough New Year for Microsoft Access as we appear to be hit with another bug which has a number of possible symptoms:

  • Error 3014: “Can’t Open Any More Tables”
  • Error 3048: “Cannot open any more databases”
  • Error 3211: “The database engine could not lock table ‘TableName’ because it is already in use by another person or process” (unconfirmed)
  • Even after closing, the access process, msaccess.exe, remains and the lock file, laccdb, remains as well
  • Error “Already in use by Admin”

I’ve seen reports that the issue relates to build 16.0.14827.20158, but i”m not sure if it is limited to just that one build or not.

Fixed - 2022-02-08
It has been reported that Version 2201, Build 14827.20192, was release late last night or early this morning and fixes the issue. Verifying the build’s release note, it does indeed confirm this is a fix.

So you may wish to try updating your Office/Access installation and the problem should resolve itself.

Threads On The Subject

As they say, misery loves company, so here are a few of the many posting related to this error.

Cannot open anymore databases - Access database
This morning I used an Access database application that I use every morning but got the following message:

Cannot open anymore databases

There have been no changes to the database for sometime and up until this morning it worked fine.
Access version 2201 problem with laccdb
I have a problem when closing Access program since Access version 2201 (26th January 2022).

There is still a "record-locking informations" laccdb not closing
Locking file not deleting
Microsoft Access Record Locking Information file is not deleting when I close my accdb front end application.
Error 3048 in Access 2016
We have a database running in Access 2016 Professional, with a front end on each computer and a backend on a NAS. It was running fine until this week, when everyone started to get error 3048 "too many databases open".
ACCESS database not closing properly in ACCESS 2019 leaving legacy shells or processes
Access 2019 running on Acer laptop with Windows 10 build no 19042.1466 a database written in Access 2010 now leaves an Access shell running in Task Manager(seeable in Apps) with DoCmd.Quit (and any of its variations).
Cannot open any more databases.
Today one of the users reported the error "Cannot open any more databases." and had to exit the database.
Re: Access doesn’t close properly. A remaining background process can only be terminated in task man
Same here. Adding the database folder to trusted locations seems to work. In my case it is a UNC path.

and there are countless more! Google should you want even more posting.

Officially

Update 2022-02-04 – We finally have an official response/workaround (same as what the community has been proposing for 2 days now).  You can read all about it at:

Access is unable to close and leaves lockfile active
A bug in Current Channel Version 2201 (Build 14827.20158) has been reported that prevents Access from closing and leaves the lockfile active, which may lead to the following errors even before shutting down Access.
 

Workarounds

There are currently 2 possible workarounds:

  • Uninstall the flawed update and revert your installation to a previously stable build number
  • Setup Trusted Locations for the folders housing both the Front-end and Back-End of your database

Reverting your Office Installation

Although a little daunting at first glance, setting your Office installation to a prior build isn’t truly that hard to do and I’ve explained the 2 necessary commands in my article:

Microsoft Office 365 - Uninstall an Update
With Microsoft’s major push of Office 365, more specifically Click-to-run (C2R or CTR), I think it important to briefly touch base on the entire update process. Do note that the following also applies to the C2R versions of Access 2013, 2016, 2019, 2021+ the only difference being the build numbers. While Office 365 will, unless…

Continue reading →

 

Setting Up Trusted Locations

Many forum users are reporting that defining a Trusted Location for the database with ‘Subfolders of this location are also trusted’ enabled solves the issue. (you have to do this for both the Front-End and Back-End!)  *** This has been confirmed to me as a valid workaround by Microsoft directly ***
 
File -> Options ->Trust Center -> Trust Center Settings… -> Trusted Locations -> Add new location…
 
* This should work as long as the group policy that enables AMSI for all documents isn’t in place. If it is, then even this workaround won’t help.
 
** You can also use VBScript to create a Trusted Location (this is useful for Runtime versions). You can find an example of the necessary code at VBScript – Create/Set Trusted Location Using VBScript
 

Extra Instructions
As mentioned in a comment by Mike McElhaney, after closing Access, you should (i)Open the task manager and Kill any remaining msaccess.exe processes, (ii)Delete any remaining lock file (ldb, laccdb, …) for both the front-end and back-end files.
 
¡Double Check Your Existing Trusted Locations!
There have been a couple reports that this bug, or perhaps another bug, has deleted previously entered Trusted Locations.  So even though you think it is already in place, double check as you may need to recreate them again.
 
Adding the necessary Trusted Location(s) is probably the the quickest and easiest workaround to implement, IMHO.

64 responses on “Cannot open any more databases – Another Access Bug”

  1. Xavier

    “Many forum users are reporting that defining a Trusted Location for the database with ‘Subfolders of this location are also trusted’ enabled solves the issue. (for both the FE and BE!)”

    Thank you !
    For me FE was enough.

    2. Jean-Marie Almeras

      It worked for me
      I am running Microsoft® Access® 2019 MSO (Version 2201 Build 16.0.14827.20028) 32 bits
      Thank you SO MUCH for the tip

  2. MarkP

    Hi Daniel. Thanks for staying on top of this. I’m a developer and my client 1st reported this 3 days ago on 2 of 12 workstations. This morning it hit my machine! Both my client and I are running Version 2201 Build 14821.20158 Click-to-Run. After adding the db folders to the Trusted Locations of the Trust Center with the “Subfolders of this location are also trusted option” checked the issue seems to be solved. I had contacted MS support about the issue. They tried to walk me through uninstalling the 20158 update with the Office Deployment Tool however, the tool failed to remove the update. It would be helpful if you could post a how-to to rollback an update. I’m not sure if it’s different whether you have a 365 subscription or the retail version of Access. A link to the Official Fixes page would also be welcomed.

  4. George Hepworth

    At our user group meeting last night, someone said the Trusted Location method hadn’t worked for them. I suggested they make sure both the FE and BE were in Trusted Locations. I haven’t heard back yet if that resolved his client’s problem.

  5. Leon Manuel

    Hi Daniel, thanks for posting this, I have been wrestling this issue since yesterday, after just getting past a record locking issue a few hours earlier (which turned out to be a windows firewall filesharing setting). I couldn’t figure out what this was, I pretty much knew that none of the historic reasons for the 3048 error fit my problem, as the application has been stable for years, so I knew it must be something outside the application itself. I didn’t know if it was another general MS Access bug or some other weird Windows security setting someplace. I always keep the FE in a trusted location, but I tried the same thing with the BE, but it didn’t help. After all of these recent issues I am seriously considering moving the whole thing out of Access and redeveloping. I tried the roll back to a previous version steps, but when performing the last step (which requires you to click the “update now” button in office) I get error code 30183-27 (400).

    1. Leon Manuel

      UPDATE: The firewall filesharing setting did not fix the issue, it seemed to be fine for half a day or so, but the file-locking issue resurfaced again, which is causing the .laccdb file to blow up to 16kb quickly and the refuse any more connections.

      1. Daniel Pineault Post author

        Have you tried simply creating a Trusted Location for both the front-end and back-end of your database? This should resolve the issue (it has been confirmed by Microsoft themselves).

        1. Leon Manuel

          Hi Daniel, yes I have, but that didn’t solve the 3048 issue for me. The “file locking” issue however seems to be only present itself on the machines running Access Runtime, which makes sense since the machines running the full version of access ARE setup with trusted locations and don’t appear to have the locking issue. This however presents it’s own challenges as a registry entry is needed to add a trusted location for the runtime version of access. I am pursuing that option now.

          2. Hal Phillips

            Hi Leon, I have Access 2021 which I assume is the full version not Access Runtime. The built in trusted location was only for the …\root\Office16\ACCWIZ folder not the …..\root\Office16\ which has the exe files. I have added the BE file folder to Trusted locations and still have the problem. I changed the original trusted location up one level to …\Office16 and add subfolder. Still no joy. So having both FE and BE folders in trusted locations hasn’t fixed the problem for me. May be a totally different problem but something just corrupted my Outlook .pst file. Had to go back to old Windows 10 machine, create a new profile and use a backup from last week to fix the problem. All of this started when Windows 11 applied the latest update. I am about a week behind since my updates are delayed that long.

        2. Guy

          Hi,
          How do I do this? I can’t get hold of our support and I am a novice. I am in the Trust centre locations, but how do I create a front end and back end folder for the dbase? I don’t know which folders these are in order to add.
          Thanks.

  6. Leon Manuel

    Perfect, thanks, that will speed up the process, if it turns out to fix the file locking issue.

    Also The trusted locations fix DID seem to solve the 3048 error on the test computer, but I had to restart the machine first, simply quitting all the access processes that were running didn’t seem to do it, but upon a complete restart the issue appears to have cleared up.

  7. Mike McElhaney

    Just a PSA — I was able to get it to work using the Trusted Folder solution with and additional step.
    After you set the trusted location, then:
    -Close Access
    -Open the windows task manager
    -Look for any instances of Microsoft Access running in the background, if you find any, kill them with “End task”
    -Close task manager
    -In the windows directory where your Access program is located, find for the lock .laccdb file, and delete it.
    Once I did that, all worked correctly.

  8. Michael Brown

    Our office addins started giving us Error 3014: “Can’t Open Any More Tables” and it was fixed by adding trusted locations to our database location and our our office template located in program files. Both locations were needed.

    Thanks, as the new roll back method just fails… old method still works with much older version numbers it seems.

  10. Charles

    Oh thank GOD. I was afraid I was going to have to go through all my VBA code to figure out why this was happening. This bug hit me today and one of my forms was unusable and it took me an afternoon of on and off googling before I hit your site. The trusted locations thing (which I didn’t know even existed) seems to have put things back to normal. Thank you so, so much.

  11. Dan

    I agree – Thank God for this post! I was sweating this issue! I was going through the code trying to find the root cause on this critical application. Thank you for what you do here Daniel!

  12. David Nealey

    Thanks, Daniel for helping us resolve this problem.

    Question: if a database is not split, does this problem happen? Do any of the recent problems happen? I understand that splitting is required for multiuser databases.

    1. Daniel Pineault Post author

      From my understanding, yes, it would be impacted by the recent bug. One way or another, any database should always have a Trusted Location defined for it. So an unsplit db should also have one created.

      1. Neetu

        Hi Daniel, I created the trusted location and tried updating the office to previous versions. The database is perfectly fine when standalone. But when we split it to BE and FE the Run-time error 3048: Cannot open more databases pops-up. Kindly help

  14. Neville Wootton

    These settings fixed the ‘Error 3048: Cannot open any more databases’ bug for me:

    ACCESS SETTINGS

    Access > Options > Trust Center > Trusted Locations > Trust Center settings > Trusted locations > Access folder location(s)

    WINDOWS SETTINGS

    Settings > Windows security > Virus & threat protection > Manage settings > Real time protection > Off

    Settings > Windows security > Virus & threat protection > Manage settings > Exclusions > Add or remove exclusions > Access folder location(s)

    1. Daniel Pineault Post author

      But you shouldn’t need to make any security changes, only create a Trusted Location for both the front-end and back-end folders.

      It is dangerous to turn off Real time protection.

      1. Neville Wootton

        Hello Daniel

        All security is back on but nothing that you, or anyone else who has posted a fix to this problem would work permanently for me.

        So yesterday I decided to bite the bullet and spend some time talking to Microsoft support. Spoke to Joe who spent two hours with me to-ing and fro-ing with Level 2 Support to get me this fix…..apparently the only way to get around this problem is to uninstall Office first…..but it does work!

        Here it is:

        Create a folder called OfficeFix on C drive and put everything we do here in there.

        Download Microsoft Support and Recovery Assistant (SARA):
        Download Microsoft Support and Recovery Assistant from Official Microsoft Download Center

        Unzip then Extract to C:\OfficeFix
        Click/DoubleClick: ClickOnce
        Click/DoubleClick: SaraSetup.exe

        NOTE: This looks like a seriously useful tool for any problems with Office!

        Select: Office
        Select: ‘I have Office installed, but I’m having trouble uninstalling it’

        NOTE: Here SARA also provides a useful link to use for any other Users with the same issue:
        http://aka.ms/sara-officeuninstall

        Now it finds any Office installs on your PC – Usually only one
        Select the one to uninstall
        Let it run, including the PC Reboot
        Wait for SARA to automatically reopen
        *Ignore option to Reinstall Office
        Close SARA

        Now we are going to use another of Microsoft’s well kept secrets! This creates a proper Configuration.xml file that we can use to set up Office EXACTLY as we want it.

        Open Office Customisation Tool:
        Office Customization Tool – Products and releases

        NOTE: There are a few confusing options so here is my Configuration.xml to use as a guide.

        Now we can use ‘How to revert to an earlier version of Office’:
        https://support.microsoft.com/en-us/topic/how-to-revert-to-an-earlier-version-of-office-2bd5c457-a917-d57e-35a1-f709e3dda841

        Download: Office Deployment Tool to C:\OfficeFix
        Click/DoubleClick: officedeploymenttool_14729-20228.exe
        Install files in C:\OfficeFix
        We can delete all the configuration files it installs as we have our own
        We just need the setup.exe that it installs

        For this open Notepad and type:
        setup.exe /configure Configuration.xml

        Save as: OfficeFix.bat within our folder C:\OfficeFix

        Click/DoubleClick: OfficeFix.bat to run the batch file, it installs the Configuration.xml that was created by the Office Customisation Tool

        Your new Office will now install perfectly!

        1. Daniel Pineault Post author

          Over the years, I’ve seen a number of case in the past where Uninstalling/reinstalling Office seemed to resolve various issues. I find that to be especially true if they used trial versions that came with Windows. That is why I always perform a complete Option 2 Uninstall and then Install Office on every PC I manage.

          I don’t know why reverting your build didn’t work in your specific case, but countless people have confirmed that it does. Very odd! It would be great to understand these exceptional cases.

          At least MS came through for you and resolved the issue and thank you for sharing as it may help others.

  15. RICHARD MOORHOUSE

    Thanks for the advice/solution, creating a Trusted Location for both the front-end and back-end folders appears to have resolved the issue.

  16. Steve

    Hello,
    I have another issue with this Bug. While adding the trusted location to my development folder did manage to delete the lock-files properly. My Add-In for Version-Control System Integration https://github.com/joyfullservice/msaccess-vcs-integration has stopped Working. It is not showing up in the ADD-In Manager and trying to add it manually prompts an error which just states that an error occurred and the add in has not been added to the ms access directory.
    Has anyone experienced similiar behaviour? Are there any suggestions how to fix that?

      1. Steve

        Thank you for your time,

        I have a trusted location for the Add-Inn but come to think of it, i am not sure if its the right one. the .accda is located at c:/users/username/AppData/Roaming/vcsIntegration which is a trusted location. Is there another location Access saves its Add-Inns to, which i need to add to the trusted locations?

      2. Adam Waller

        Hi Daniel,

        Yes, the add-in adds the trusted location by default during installation. During the export and build process it writes files to the system temporary folder and the source code export folder (typically a subfolder under the database location.) During a build, it renames the original database, then recreates it from source in the same location.

        In case it is helpful for anyone else, we have a dedicated issue on GitHub tracking this bug in relation to the add-in at https://github.com/joyfullservice/msaccess-vcs-integration/issues/302

        – Adam
        (Owner of joyfullservice/msaccess-vcs-integration)

  18. FrankRuperto

    What a mess this bug has created, and the irony is that to me Trusted Locations are a security theater because it really offers no protection, go figure!

  21. Fiona Whitehouse

    Thank you so much for assistance. My client contacted me and I was stumped! came online and found this forum. Have done the Trusted Location on the FE and the BE on the server side – lets see if I need to do it on the FE of the client side. Again, thanks for helping

  22. B

    Thanks so much. This really saved our company! We were going crazy, tried so many things.
    Thanks a ton for this!

  23. Manny Insignares

    I very much appreciate your posting the confirmation of the problem by Microsoft, and for the solution!
    From looking at the replies on this thread, you have helped a great number of developers/solution providers.

  24. Aris

    Thank you! This worked for me.
    Before, I only put front-end in trusted location, and did not work.
    Now I also put back=end in trusted location, and the problem with the .ldb file and ghost processes remaining open disappeared.

  25. Sean Krummrich

    MS Released version 20192 today when i did a “check for updates”. I am currently testing with a machine that has this known issue to see if this remedies the problem…

  26. Sean Krummrich

    After updating to 20192, one of my users that had the issue “cannot open any more databases” reports that the update resolved her issue. For those that do not know, there is a button in Access under File->Account called “Update Options”. My user clicked this, Checked for Updates, waited for the update to download, then restarted Access and it is now working. No reboot required. If any additional issues arise, such as this error cropping up when opening too many tables or forms, I will post again.
    Thank you for this message board. It was helpful for me to be able to find this issue and read through the potential remedies, comments, and frustrations.

  27. Karl Donaubauer

    Yes, I’ve seen 5-6 positive reports so far from around the world, that the fix works. The community is again ahead of the Microsoft documentation, release notes etc. same as when receiving the bugs. 😉

  29. Stephen

    There are SO MANY companies stuck on this piece of doo and Microsoft should know that. Microsoft morons. This is a dying product. Why can’t they just stop breaking things every few months? The Access team is absolutely the worst of all the Microsoft products I’ve had to deal with. Maybe they are underfunded, I mean Microsoft is so impoverished what would a few competent people cost? They need a management shakeup to start operating this team better. This crap is costing us all time and money.

    1. Daniel Pineault Post author

      I agree with the general sentiment, but I will formally state that this issue didn’t originate with the Access Team. It was caused by another group, but they are the ones left holding the bag at the end of the day!

      It’s the typical right hand and left hand don’t ever speak to one another. This seems to be a MAJOR issue at Microsoft. You’d think after 4 decades of software development they’d have a system in place to avoid this, but apparently not.

      1. Stephen

        Daniel thank you for the correction! My apologies to the Access team, although, given the number of patches to patches that occur, they obviously have some problems.

        These types of “incidents” inflict a lot of pain, lost time, and company resources getting involved to deal with them. I wonder what the worldwide cost, not just in time wasted but lost productivity, has been for just this one incident.

        We’ve been suffering issues since last week and I just wrote them off as, you know, this is Access and it isn’t the most stable piece of software but we had multiple users, starting yesterday who had problems. At first I was changing code to work around the problems, where I could, but it escalated today on one of our business/time critical processes — that was not a simple code change — and it led to me finding this page (Thank you!!) and getting the information we needed to resolve and complete today’s tasks.

        Thank you for running the awesome web site and great user input. I have found help here on a number of occasions.

  30. Siegfried Unrein

    Hallo, Daniel und Community
    Ich hatte bei verschiedenen Kunden und verschiedenen Anwendungen tatsächlich alle der oben aufgeführten Fehler.
    Tatsächlich haben sich alle Fehler durch das Update …192 erledigt.
    Ich teste seit einigen Stunden alle Applikationen auf Herz und Nieren und bin sehr glücklich, dass ich Code-Veränderungen bisher gescheut habe, denn zum Glück scheint alles zu funktionieren.
    Vielen Dank für Deinen Einsatz, Daniel und ebenfalls Dank an alle, die hier berichten und Workarounds erarbeiten.

    Viele Grüße, Siegi
    PS. Das Workaround funktioniert bisher bei allen Anwendungen – egal ob die Workarounds beachtet oder unbeachtet sind.

    —
    Hello Daniel and community
    In fact, I’ve had all of the errors listed above for different customers and different applications.
    In fact, all errors have been resolved by the …192 update.
    I’ve been testing all applications thoroughly for a few hours and I’m very happy that I’ve shied away from code changes so far, because fortunately everything seems to be working.
    Many thanks for your commitment, Daniel, and also thanks to everyone who reports here and develops workarounds.

    Best regards, Siegi
    hp So far, the workaround has worked for all applications – regardless of whether the workarounds are observed or ignored.
    *****Translation by Google Translate and added by the site Admin*****

  31. BigJoe

    Just to add to the bugs there is currently one with the latest version of the MySQL ODBC Connector 8.0.28.
    Although this one is not Microsofts doing.
    We were working on updating the connector and re-linking tables and ran into a “Cannot define Field more than once” error.
    Turns out there is a bug in the last few versions when linking to MySQL tables with Access.
    https://bugs.mysql.com/bug.php?id=106204
    Just in case anybody stumbles upon this one that had us scratching our heads for a while.

  32. Aleks

    Daniel, your page has been the best place for info for the last two Microsoft Access bugs. Your work is much appreciated. Just wanted to thank you and let you know I dropped a couple of dollars through your Donate button.

  33. MarkP

    Version 2201, Build 14827.20192 has NOT fixed the issue for me.
    Running retail standalone version of 2016 32 bit.
    I’d be more than willing to upgrade if I knew it would fix the problem.
    I initially didn’t have the error but my clients did. I first got this on 02/21/2022.
    Checked my version and it was up to 14827.20198 with the error then reverted to the .20192 but still no joy.
    I have the Trusted Locations entered for the FE & BE for all my client databases as well as Allow Trusted Locations on my network (not recommended)
    Microsoft support REFUSED to connect me with a Level 2 support agent. If anyone has a link to get to one, I’d be very appreciative! As it is, being a consultant/developer, I’m unemployed.

    1. Daniel Pineault Post author

      There have been reports, similar to yours, that the issue has resurfaced even after all the ‘fixes’ have been released. Others notified the Access Dev Team of this last week, but I haven’t seen/heard anything from them on the subject.

      1. MarkP

        In case anyone wants to test their installation, here’s an easy way to push a test db to the error.
        1. Create a new Access database
        2. Create a Test table (Dual for me) with 1 autonumber field. Add a single row to the table.
        3. Create a new module with a recursive procedure that opens the dual table multiple times. If you have the error install, the procedure will generate the error after opening the dual table after 253 times. Here’s the procedure:
        Public Sub Test(Optional lvl As Long = 1)
        On Error GoTo errHandler
        Dim rs As DAO.Recordset
        Debug.Print “Level: ” & lvl
        Set rs = CurrentDb.OpenRecordset(“Select * from Dual”, dbOpenDynaset)
        If lvl < 256Then Test lvl + 1
        ExitSub:
        If Not rs Is Nothing Then rs.Close
        Set rs = Nothing
        Exit Sub
        errHandler:
        Debug.Print Err.Number, Err.Description
        Stop
        Resume ExitSub
        End Sub

  34. Jim Strutz

    I wrote a large Visual Basic 5 application 25 years ago that used OpenRecordset calls to Access 97 tables. It’s worked great all this time and I’m forced only now to upgrade because I can’t keep running old software (Crystal Reports) on newer 64 bit hardware – but that’s beside the point. Upgrading to VB6 was easy and I’m in the process of upgrading to VB.Net (2008 version for now). Suddenly, processes that have worked great for years are running into 3014 “Can’t open any more databases” errors. So, it seems the notion that this is a new Access bug is questionable, and does this change any of your workaround ideas?

    1. Daniel Pineault Post author

      If you’re talking about the ‘Monster Bug‘, it’s most certainly not new anymore, heading 4 years now!

      Does this change any of your workaround ideas?

      I guess they’re not really workarounds anymore, but rather fixes since Microsoft hasn’t provided any real support on the matter.

      You may like to read: https://www.devhut.net/does-microsoft-access-remain-a-good-choice-as-a-development-platform/

      At this point in time, see little forward movement in Access in 5-10 years IMHO, a pile of never ending bugs, a roadmap of missed targets and continual delays, little support, … one has to seriously question the validity of doing development with Access when there are so many other options on the market. I’m at the point now of seriously wondering, thinking of the above mentioned and the newest push towards Dataverse, if this isn’t all intentional from Microsoft to finally kill Access once and for all. Who knows, but if I were starting new work, I’d certainly be very seriously looking at alternatives. Maybe things will change, but right now, IMHO, things are ugly.