This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
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?
A family of Microsoft relational database management systems designed for ease of use.
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.
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?
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.
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
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?
What about the hack as mentioned before (and on Daniel Pineault's site) of changing the Client's File cache as below. Does anyone report an impact performance with this? This is the option I have chosen in the past 2 weeks.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters] "FileInfoCacheLifetime"=dword:00000000 "FileNotFoundCacheLifetime"=dword:00000000 "DirectoryCacheLifetime"=dword:00000000
This is the SMB registry fix that was mentioned above. It works well but with a huge performance impact