Microsoft Access Database App Error 3046

[Julian-Cooper-KPP]

Help!!!

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

[#2]

@Julian-Cooper-KPP 

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. 

[#3]

@Julian-Cooper-KPP 

Yes, we have the same problem. Also since the the Bug "Query Corrupt". 

Did you find any solution?

[#4]

Nothing concrete yet im afraid.

I have been playing with registry settings to no prevail.

Next test is to set FlushTransactionTimeout to zero top force asynchronous transactions but this may invariably slow the db down.

[#5]

@Julian-Cooper-KPP 

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.

[#6]

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. 

[#7]

@AA_Capacity  @Julian-Cooper-KPP 

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..  

[#8]

Can you try closing all Office applications, and restarting Access to see if the issue goes away (you need to do this to pick up some configuration changes made on Friday that may be affecting this issue).

[#9]

Hi Shane

Could you confirm, has an update been rolled out that may solve this?

What is the build number so can check if it's been installed?

Thanks

[#10]

@Shane Groff 

We restart all Access applications on our clients and server. But yesterday and today we got the same errors 3046 at the most of the time and sometimes 3218.

[#11]

@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.

[#12]

Are there any details on the actual changes as its almost impossible to test this issue without doing it in a live environment due to the irregularity of it. At present, I have moved the back end db to the rds session host where the front end app launches from as the assumption is its network related and this overcomes this but this limits all users onto a single session host so load balancing goes out the window.

[#13]

@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.

[#14]

Hi Shane

Thanks for the update.

If it helps to identify the cause.

I was seeing the 'corrupt database' issue being caused by the windows 10 latest release. The disableleasing workaround had sorted this for the most part. However, when the build that caused the corrupt query error was rolled out, it was roughly this point where I started seeing the error locking issue.

I moved all users front ends to an rds session host and rolled back office 365 to until three fixed build was released.

It is since this point that the record locking issue has started and happens from anywhere the front end app is located.

Having now moved the back end to a vhdx and attached directly to the session host, thus avoiding network comms altogether, this seems to have resolved the issue further.

I still have another session host running the same front end and communicating over the network but doing less heavy processing and this also seems ok since 3rd January so something has improved although not sure if it would reoccur if I tried to do heavy transactions over the network again.

I have never had a 3046 error on this network with this application (or any of my many apps to be honest on other networks) so I am confident that it's nothing to do with the programming.

I have even gone as far as to double check no connections after left open any longer than necessary within the code.

Hope that helps.

[#15]

@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.

[#16]

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.

[#17]

@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.

[#18]

Following are the possible reasons that can result in the ‘Access database inconsistent state’ error:

If you’re using Data Access Objects (DAO) to open the database from VBA code, you can face the error code 3343 “Unrecognized database format error.”
If your database is stored on a network file share and is used by multiple database users simultaneously.

Read this articles: https://support.microsoft.com/en-us/topic/access-error-query-is-corrupt-fad205a5-9fd4-49f1-be83-f216...
(third party link removed by moderator)

[#19]

Hi Stacy,
I fixed this problem by the shared references.