MsAccess error 3046: "could not save; currently locked by another user" RRS feed

  • Question

  • The last couple of weeks (since the 6th of december, 2019) we get this error. 
    We work with a MsAccess application in a multiple user environment (split database).
    The program (frontend) did not not change. Also the server where the backend resides did not change and the way of working with the application did not change either. And now every day this message pops up and the proces stops.
    I am sure there is no one else blocking the work to be done and every day it is a different set of records being processed.
    The only way to proces the working set is to have everyone stop using the application and perform the task as the one and only person in the database.

    Does anyone experience the same problem? And if so, do you know what is causing it?

    Hoping for an answer,

    Tuesday, December 24, 2019 2:10 PM

All replies

  • Does each user have their own copy of the front end of their own hard drive? Or are they sharing a network copy of the FE?

    Is the BE an Access database or something else like SQL Server?

    • Edited by isladogs52 Tuesday, December 24, 2019 6:23 PM
    Tuesday, December 24, 2019 6:19 PM
  • Sorry for the late reply: Christmas holidays...

    The users have their own copy of the frontend and the backend is also an Access database.

    The weird thing is that has run for years this way and all of a sudden this runtime error pops up daily. At first I thought it was in the order of 'Query corrupt' and 'Unknown database format'. We suffered also from both these errors. But since I found no other signals lately about error 3046 I am puzzled. 

    Saturday, December 28, 2019 5:02 PM
  • I have the same new problem:
    "could not save; currently locked by..."
    in a multiple user environment
    Tuesday, December 31, 2019 11:50 AM
  • One way this can happen is if either the Share itself, or the folder of the share, don't have the right permissions. Assuming you are on a Domain network, make sure all users have update rights.

    Don't try to finesse NTFS permissions. It is more tricky than you may think. As a test, you may want to give Everyone full access (again, to the Share, and separately to the folder), then gradually back off. Be sure to test with 2 users.

    -Tom. Microsoft Access MVP

    Tuesday, December 31, 2019 8:41 PM
  • I have the same problem with vendor software using Access DB  started happening also Dec 6th.  

    Our vendor says it is a microsoft problems.

    They told us to roll back to earlier version of windows 10 which we did but did not help.

    I'd appreciate any suggestions.  This is causing a huge business issue!

    • Edited by Cspangler Friday, January 3, 2020 6:59 PM
    Tuesday, December 31, 2019 11:41 PM
  • We updated the permissions but we still have had 2 users get the error.
    Friday, January 3, 2020 6:56 PM
  • Let's recap. This is my current understanding:

    The app is deployed with the FE on each workstation, and an Access BE on the server. Server permissions have been checked and are OK.
    Sometimes without rhyme or reason some user gets the "currently locked" message.

    I am not convinced yet that there is an issue. It is normal in a multiuser application that this message or similar ones happen. Often a well-designed error handler can deal with it (e.g. by going to sleep for 100 msec and trying again). Of course a lot depends on many finer points of your implementation. For example there are properties at the form level that affect how records are locked.

    It is good to understand that 2 users do not have to be saving the SAME record. Access saves a memory page at a time, and such 4K page may contain several records. 

    Also, can you confirm that all users are on the same version of Office and all updates have been run? What is that version?

    -Tom. Microsoft Access MVP

    Friday, January 3, 2020 7:53 PM
  • Thank you Tom for sticking with me (with us so it seems). I appologize for my late responses. I cannot get the notification to work. I can reach the site but when I want to activate this function it asks me to try later. This has happened over a period of time (days). 

    Back to my problem.

    User rights have been checked and are OK. All users have the same version of Office: Microsoft Office 365 ProPlus, november, versie 1911 (12228.20332).

    I was able to track the problem ones with a debugged version of the application. The procedure works through a batch of records (recordset). For every record occurrence multiple records of other tables are updated. I was able to test it multiple times on the same recordset. Every time I ran the procedure the error popped up but the weird thing is: on different updates (tables).    

    Tuesday, January 7, 2020 8:11 AM
  • I can say that we also experience this problem intermittently in a similar environment and have for several months.  We use Access 2010 though which is deprecated and no longer supported.  I can't really complain because the first suggestion will be 'move to a newer version of Access' but I really don't think that's the problem.  I have tried implementing row locking as opposed to Access' default page locking scenario that Tom describes but it did not help in our case. I suspect that our planned move to SQL Server as a back end will take care of the problem though.


    Wednesday, January 8, 2020 11:36 PM
  • I can say that we also experience this problem intermittently in a similar environment and have for several months.

    Hi Bruce and Ron,

    When a problem is intermittently, I think of timing problems.

    And not hindered by any knowledge, just guessing, a timing problem of the lock-file? I can imagine that this could happen when some other running program consumes almost all cpu-power.

    Another reason for delays that I have experienced, is when the map-structure to the database is too deep leveled. In an experiment with too many levels the application did not even startup.

    Perhaps these two scenario's happen at the same time to reinforce each other?


    Thursday, January 9, 2020 8:28 AM
  • We are also experiencing the exact same problem. We are on Office 365 and maintain a multi-user MS Access database. We have a separate Front End which resides on each users PC and the Back End database (MS access database) sits on our server. The database has worked seamlessly for the better part of 10 years. Since around end of November we now regualrly (several times a day) get lock out. Typical pop-ups include:

    1. Could not save currently locked by another user

    2. Record locked out by other users

    3. Wait period for an event timed out.

    4. Software just stalls

    The current "fix" is to get everyone to exit the database and then rejoin. Not practical. Nothing has been changed regarding the system, access rights, shares etc or the database itself.

    Hopefully looking forward to a resolution!



    Friday, January 10, 2020 10:31 AM
  • We’ve been having issues with corruption on our MS Access Database lately. It started in early November with the new version of Office out into the wild as you stated. I’ve been getting people back on Version 1902 of Click to Run to keep it consistent. Last week we had a new corruption we haven’t seen before come up. It’s happened twice now –last Friday 1/3 and yesterday 1/9. I know enough about MS Access to be dangerous – so bear with me here on lingo.

    Patterns I could find lately:

      • MS Access will allow people to make changes but it gave two end users the lock out pop up at different times and both were not in the same area updating. Two end users have communicated with me that they get the error and they sit right next to each other. There could be potentially more than just these two users. 
      • Within at least 2 hours of those errors, the database will try to do a backup on it’s own and corrupt itself. VBA run time error crops up.
      • I’d say if I had to pin point an exact timeframe the error started around 10:59 AM 1/09/2020 since that's when the backup was created by MS Access. 
      • I pulled our Acronis backups from noon and midnight. I was able to get us back on track with a database that updated at 11:30 AM. We lost data from 11:30 til I was notified later at 12:30. There was still people in the database at this current time who didn't get any errors. Others who want to open the database get "Unrecognized database format .... Database.accdb"
      • From what I can find these are the errors that show up below when I try to open the database before I will attempt to Compact & Repair which fails to fix the issue and erases all of the VBA.
      1. note the way I’m doing this is changing the current database extension over from .accdc to .accdb in order to get into the database for the repair and then changing it back once completed.
      2. I  have to go and find a backup suitable to replace the current database corruption. 
    • Currently the database is at 38,044 KB
    • I would have screen shots but Microsoft isn't playing nicely with my existing account. 
    Friday, January 10, 2020 7:28 PM
  • Hi Bro,

    To make things more confusing, in reaction of your fourth point concerning "Unrecognised database format ...".

    We experienced this error in different situations. At first it was as you say, one user was blocked by it while other users could work with the application. If the user waited long enough he/she could work again without being blocked by this error. 

    An other issue we had was that from within the application data was written to another backend. In november 2019 it looked like almost every user got this error when using this function, but not all users! I worked around this problem by importing the tables into the main backend. The only thing here is that the backend has become large (> 500MB).

    Last week I had to do some analyzing on the database and had made a couple of queries. They ran fine but at some point when I wanted to requery them the "Unrecognized database ..." error popped up. This was all in the same session. I closed all of the queries, builded them again, ran them and no errors...

    Not very helpful but perhaps someone else can relate and possibly share an insight?
    Saturday, January 11, 2020 3:25 PM
  • This was all in the same session. I closed all of the queries, builded them again, ran them and no errors...

    Hi Ron,

    Interesting to know: did you have to build all the queries again, or could a rerun of the queries after some time had been sufficient?


    Saturday, January 11, 2020 6:14 PM
  • Hi Imd-hb,

    I did build the queries again. There was no time to wait (this time) for a rerun of the original queries.


    Monday, January 13, 2020 7:38 AM
  • Hi,

    Since November 2019 I have the same problem even when I am the only active user. At my job we have the same MS Access application as front on every machine with MS Access databases as back end on server. One solution I found is change the VBA code as follow:

    On Error GoTo Err_Handler


         Set rst=dbData.OpenRecordset("SELECT * FROM Table WHERE Condition") 'this causing the error!!




    Loop Until .EOF

    Exit Sub


    If Err.Number= 3046 And i < 100 Then


       Resume ' (yes, Resume to the same line that cause the error, next time will work)

       i = i +1



    End If

    The problem still remain when I have controls like combos with record source to the same table as above. Even open table by mouse click is impossible at that stage, and soon the problem is spreading to all tables in database.

    The only solution is to close all open files from Computer Management on server, but this is madness. Changing record-level locking doesn’t solve the problem, just make it less frequent. Default record locking is No locks.

    The big issue is the application has run for almost 10 years without problems like this.

    Tuesday, January 14, 2020 9:21 AM
  • Hi,

    I'm not sure if anyone is aware of the problem which is related to random disconnection since the Windows 10 updates.

    Query is Corrupt

    My solution is to use a Windows 7 OS for the shared folder. Had no problems from somewhere March 2019.

    An alternative is to install a SQL server or SQL server express.

    • Proposed as answer by Guvirti Wednesday, January 15, 2020 9:15 AM
    • Unproposed as answer by Guvirti Wednesday, January 15, 2020 9:15 AM
    • Proposed as answer by Ronpaii Tuesday, October 27, 2020 2:51 PM
    Wednesday, January 15, 2020 1:21 AM
  • Hi John,

    Our company has encountered exactly the same problem as you described in your post.
    I wonder whether you have found a solution for this problem in the meantime? We started to get this problem mid september 2020.

    Kind Regards


    • Edited by Steven Tss Tuesday, October 20, 2020 8:46 AM
    Tuesday, October 20, 2020 8:45 AM
  • Hi Steven,

    One of my clients experienced a similar issue last week and again today. Today 4 users saw error 3046 when each working in completely different areas of the application. Last week it affected many more users, perhaps because they left it longer before reporting it. I ran the compact and repair on the back end and this appears to have resolved the issue for 5 days until it occurred again today.

    Like Ron-St, I am suspecting that this is related to the long standing error 3343 bug:


    Perhaps a recent Windows Update has removed the work-around patch from the server? I'll ask their IT support provider to check.



    Tuesday, October 20, 2020 11:40 AM
  • Hi, All

    We had the same issue back in May 2020, we updated all our systems to latest Windows updates, including the Optional Updates and it was fixed. The issue came back in last week of September 2020. No changes were made to the Backend and Frontend. We updated all the systems to latest Windows update but the issue is persistent. I am skeptical of pushing out any new front end updates.

    Does anybody have any updates or work around.

    Much Appreciated.



    Tuesday, October 20, 2020 10:42 PM
  • I would suggest the Bro post be a separate post.

    The "Unrecognized database format .... Database.accdb" seems to have become prevalent in edition 2019 / 365.  

    I've spent some time with it and there is Q/A on this topic here at this forum.  this is in reference to the BE going into this state due to user activity - - and not where development has been done in a newer edition - which is an entirely different issue.

    My observations are:

    a. mostly seen in older apps that were originally .mdb format but now .accdb / one of the suggested fixes, that did work for me in one situation: change the BE file back to .mdb

    b. the FE design must avoid having the same table open in edit mode, at the same time.  If 2 forms both source on Table 1, in an editable function, both forms should not be open at the same time.

    c. strict adherence to a primary key in every table. and careful review of any look-up table/field properties being used.

    Tuesday, October 20, 2020 10:48 PM
  • Hi David, I 

    I believe you might be correct, we believe the problems in Access must be related to Windows 10. 

    We have a strange history of events:

    The errors started on 17deazfezffez september 2020.

    "Cannot close database because of lock by other user", "Cannot save due lock by other user", "Wait period for an event timed out", ... Or code errors related to locks on tables. Just like mentioned here before, the problem also seemed tI mo occur on tables that are related to eachother.

    The errors were very infrequent and it took us weeks to determine that the errors where only caused by one laptop. The colleage had no different office version (365) and an up-to-date access front-end like other users. We found out that a system restore did help, but only temporarily. After a week, the error was back. Then we concluded it must have been caused by an automatic update. 

    After lots of experimenting, we decided to reinstall Windows 10, (incl. removal of files), it had NO effect, the same problem occured immediatly.

    We became desperate and reinstalled the computer to Windows 10 with the option, redownload Windows 10 from the internet. To our own surprise, the error had been solved, it was 8 october 2020

    Suddenly on 15 october 2020, after a week without a single error. The problem reoccured, but now not by this user. The error seems to be caused by multiple users, maybe even all our windows 10 computers. We are already certain it happens because of multiple users. We are however uncertain whether the user with the completely reinstalled Windows still triggers the error. In theory we could reinstall every computer and redownload Windows 10.

    To respond to @msdnPublicIdentity. "the FE design must avoid having the same table open in edit mode, at the same time". This seems almost impossible to achieve, too many queries open multiple tables.

    Thanks everybody for their input. We keep searching. We are now installing the new Windows Version (20H2 19042.572) on the computers that we believe have already caused the error. 


    • Edited by Steven Tss Friday, October 23, 2020 8:35 AM I mean tables that are NOT related to each other*
    Friday, October 23, 2020 8:32 AM
  • I believe this post has too many different topics co-mingled in the dialog - - and other readers of this in the future will be confused.

    In regard to:  "the FE design must avoid having the same table open in edit mode, at the same time". 

    the FE design should not allow the user (same user, same PC) to have 1 table in edit mode multiple times simultaneously.  so this doesn't affect multi users working separately in their own FE and it doesn't affect reports since they don't put a table into edit mode.  so it is really about data entry forms.  or it is about direct entry into tables/queries (that shouldn't be happening anyways typically).  One should update the design so that only one form/object can be opened at a time.

    the BE will lock up when it has table/record confusion....the scenario just described is a candidate to cause it - - - the other is if the key field is left blank and not immediately provided in new records....   

    older editions of Access were a lot more forgiving of this than seems the most current edition.

    Friday, October 23, 2020 5:17 PM
  • I struggled "Locked by another user" issue for over a week. Tried the following

    Move database to older server 2008-r2

    Move shadow copy times to non-work hours

    Stopped mapped drive refresh from AD

    Verified no code was holding locks

    Verified all FE were using same version of Access.

    None of the above worked

    Found 4 tables in the BE had MultiValue fields. After disabling the problem ended:) 

    Tuesday, October 27, 2020 2:56 PM
  • None of the complex Access datatypes (MVFs, attachment fields, memo field version history) are compatible with SQL Server (or indeed any other RDBMS). One of the many very good reasons for avoiding their use. I'm surprised SQL Server allowed you to include those fields with your upsized data
    Tuesday, October 27, 2020 5:05 PM
  • My client appears to have resolved this issue with some user training, by instructing them not to leave an edited "note" record open. They have a table for user notes, with a memo field to accommodate large notes, which is simultaneously being added to by possibly 10 users. Most records are small. When adding a new note, the new record is automatically created and saved before leaving the cursor in the text box which is bound to the memo field. So when the user starts to type, the newly added record gets locked. I suspect that the issue occurs when the user leaves their session in this state while they do something else. No other user is ever able to edit this user's note, so I think the basic problem is that Access still does not do proper record locking. So occasionally, when another user tries to add a note, a page lock error occurs. So in this case there appears to be a fairly simple permanent solution; a change to the user interface to avoid any lengthy record lock.
    Tuesday, November 24, 2020 12:02 PM
  • So occasionally, when another user tries to add a note, a page lock error occurs. So in this case there appears to be a fairly simple permanent solution; a change to the user interface to avoid any lengthy record lock.

    Hi David,

    In those circumstances I use an unbound form, to gather all the needed information. When pressing some Accept-button the information is written in a record, and saved: minimal lock time.


    Tuesday, November 24, 2020 1:20 PM