Access Database is getting corrupt again and again

Anonymous
2018-06-01T17:47:41+00:00

We have an application which was working okay till last month. But after the last windows update our clients are getting issues with access database. access database got corrupted.  We ran compact and repair. But it still getting corrupted again and again.  This issue started right after the window update. clients are on different OS. Like server 2018, server 2012 and windows 10.

Is there anything i have check in new windows update or any other step to prevent database corruption?

Microsoft 365 and Office | Access | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

604 answers

Sort by: Oldest
Most helpful Newest Oldest
  1. Anonymous
    2020-02-26T04:51:07+00:00

    Really? A huge Performance impact!  I have applied this to numerous sites with NO performance impact for the past 6-9 months with the corruption problem being fixed every time. Are you sure you are applying it correctly and that there is not some other factor that is causing the performance impact you are observing?

    Was this answer helpful?

    0 comments
  2. Anonymous
    2020-02-26T06:07:01+00:00

    Yes I am 100% sure. Followed all the steps to many clients. The speed decrasement issue with this solution is when you are performing complex queries with dlookups as also if you are using continous forms with a few thousands of records. 

    Otherwise you notice just a slight speed decrease. 

    On the other hand, the disable leasing on server is by far faster under these db operations

    Was this answer helpful?

    0 comments
  3. Anonymous
    2020-02-26T06:56:12+00:00

    Using dLookup inside a complex query is a disaster anyway as the function is called again and again for every row that is returned. Not sure why the server side solution would be much better. Using any of the  Access functions inside complex or even simple queries is not recommended - they are as slow as a wet week. They should never be used in such situations. Think about doing such queries in 2 steps - use a MAKETABLE to store intermediate results in a tmp table followed by an INNER JOIN on that table in a second query. It will speed up your application by a factor of many hundreds.

    Anyway the upshot is that client side registry fix DOES WORK, preventing continuous corruptions,  and should be used in every case where you do not have direct access to the central server - due to IT not allowing registry changes to shared servers. The speed problem you are dealing with can easily be overcome.

    Was this answer helpful?

    0 comments
  4. Anonymous
    2020-02-26T14:19:39+00:00

    Regarding using the client side registry fix/hack...

    has anyone noticed any general speed issues with the client PC

    or any other unwelcome side effects in the general use of the PC for other apps etc?

    Was this answer helpful?

    0 comments
  5. Anonymous
    2020-02-26T14:30:11+00:00

    Thanks for the reply. 

    Regarding your comments:

    1. Smb registry fix as you mentioned, works well and if someone uses it, then corruption dissappears. Same results we have with server fix, so smb is a solution when someone is not having access to the server
    2. Smb registry fix is slower than server solution. Dlookup in complex queries is one reason of extreme slowing (as you mentiomed) for accrss applications in general. Bit It becomes terrible with smb registry fix while the same bad queries are performing faster with server fix. So I guess server solution is faster in everything since it handles very fastet these bad queries. 

    But smb registry fix is also slower in other situations as well like:

    1: complex dlookups (not inside queries) 

    2: when viewing continous forms with many (thousands) records.. Form is opening very slowly

    The make table query is a good and fast solution but if you perform it on eg on a big mde file locally, then size might increase and corruption issues of the mde might appear. So ot needs to be done perhaps to a seperated db dedicated for this

    Was this answer helpful?

    0 comments