Dec 19 2019 08:53 AM
Dec 19 2019 08:53 AM
I have a multi user (front end / back end) access application.
My users are now receiving intermittent 3046 record currently locked error messages.
I have tried various regedit suggestions regarding file locks, buffer size but none work.
This problem started at the same time as the "Query Corrupt" issue (https://support.office.com/en-us/article/access-error-query-is-corrupt-fad205a5-9fd4-49f1-be83-f2163...) and I have a feeling its also linked to Microsoft attempts at fixing (https://support.office.com/en-gb/article/access-reports-that-databases-are-in-an-inconsistent-state-...) issue.
Does anyone have any suggestions?
Thanks in advance
Dec 19 2019 11:35 AM
Hello! You've posted your question in the Community Discussion space, which is intended for discussion around the Tech Community website itself, not product questions. I'm moving your question to the Microsoft Access discussion space - please post Microsoft Access questions here in the future.
Dec 30 2019 09:11 AM
Jan 02 2020 01:05 AM
We have updated our system up to 64 Bit, but there is the problem still active.
Most of the time we got the error 3046, sometimes we get error 3218.
We use Server 2012 as File Server. And 10 clients on Win10, O365, V1911 12228.2034. All 64 Bit.
It dosen't make any effect if we use DisableLeasing or not.
The problem exist since mid of December. Update KB4524445 was at the same time.
We need help, our company use Access as the only one ERP software.
Jan 03 2020 06:04 AM
We experience the exact same issue at one of our clients. They are using Access 2016 64 bits and first had the query issue, the update did fix that, but it seems as if the extreme amount of locking issues appeared shortly after.
They use a frontend separated from the backend.
- Repairing the databases does not help;
- Setting the registry key (lease time) as suggested as a work-around on the database server has no effect;
- Increasing the retry attempt from 2 to 20 has no effect.
- Disable opening the database in lock mode even does not resolve anything.
If the error occurs they could go to debug mode, wait a couple of seconds and resume by pressing F5, the "lock" then probably resolved and execution continues, but only for a while until the next lock hits.
This client is unable to work with more than 1 client at the moment. Any help or update on this will be highly appreciated.
Jan 03 2020 06:24 PM
I have myself experienced it quite regularly since December 10, 2019. I am in a multi-user environment, each user having its own copy of the same ACCESS 2016 program on his desktop running WINDOWS 10 while the data is in a separated ACCESS 2016 database on a server. The problem happens when the program just loaded tries to do a very simple update to one record of a table. This ACCESS program has been working fine for years and all of a sudden, the error 3046 appeared on December 10 exactly as described by others above. I have no idea if any patch has been developped for this but would like to know if any..
Jan 04 2020 08:43 PM
Jan 05 2020 05:28 AM
Jan 08 2020 12:07 PM
@Julian-Cooper-KPP There was no build update that would impact this, but there were configuration changes (each time Access starts, it downloads configuration changes that may change behavior) that were made on Jan 3 that might impact this.
Jan 08 2020 01:58 PM
Jan 09 2020 03:47 PM
@Julian-Cooper-KPP There was a significant change to address some of the issues around the errors with corrupt/inconsistent databases, which was being rolled out to production, but we have turned back off, and it is possible that this change could cause the 3128/3046 errors. That change has been turned off via configuration so if users are still seeing this issue after restarting Access, then there must be some other cause. As many posters have pointed out, this may legitimately be a case where there is locking contention (multiple users trying to modify the same data at the same time), so it may just be an application error or appropriate behavior, it is hard to say without access to the application reporting the error. We do not have evidence that this is an issue being experienced broadly.
Jan 09 2020 04:09 PM
Jan 10 2020 08:07 AM
@Shane Groff We work in a live environment. Since the new configuration, the errors occur less frequently. So it had to have an impact.
Our code has not changed in 6-8 weeks. So that we can rule out that it is a programming error. The hardware has also not changed.
Jan 29 2020 12:38 AM
Since 10 January 2020, we got no errors again. Last week was a update for O365. Since this, we have the errors again. Not so much, but again.
Jul 15 2020 01:17 PM
@Julian-Cooper-KPP I concur with your evaluation. I am trying to find the update dates that precluded this issue, both in windows 10 and in Access 16. Our library keeps good copies of each update & want to to "get back" to where things were good. Can you supply accurate dates or build/update numbers? Thank you.
Apr 13 2021 02:24 AM