Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Microsoft Access Database corruption #934

Closed
Kevin-Meers opened this issue May 18, 2018 — with docs.microsoft.com · 22 comments

Comments

Copy link

commented May 18, 2018 — with docs.microsoft.com

Feature update 1803 causes an Access database to become corrupted when heavy recordsets are processed using DAO using access runtime (2016 or 2013 or 2003 versions). Had to roll back several of our client's PCs to 1709 which resolved the issue. Please investigate and resolve.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

@andreabichsel

This comment has been minimized.

Copy link
Contributor

commented May 18, 2018

Please submit this request via the Feedback Hub (see https://docs.microsoft.com/en-us/windows/deployment/upgrade/submit-errors). Thank you!

@russcummings

This comment has been minimized.

Copy link

commented May 23, 2018

Andrea, we too have several customers experiencing this same issue. Is there a resolution? Do we know what changes in 1803 are causing the issue?

@andreabichsel

This comment has been minimized.

Copy link
Contributor

commented May 23, 2018

The best way to get support on this issue is through the Feedback Hub (see https://docs.microsoft.com/en-us/windows/deployment/upgrade/submit-errors). Thank you!

This comment has been minimized.

Copy link

commented Jun 8, 2018 — with docs.microsoft.com

Same problem like Kevin-Meers.
Andrea, sorry but we can't enter in "Feedback Hub" and do the job of beta testers.
I suspect it may be related with SMB protocol changes in this Windows compilation (timeouts or something...)
Update 1803 caused a lot of problems that have affected windows users, and the corruption of Access Database is one more.
Please inform about news.
Thanks.
bbartres@binsa.com

@ITYIPMan

This comment has been minimized.

Copy link

commented Jun 22, 2018

For my scenario and many days and hours investigating this issue, the Windows 7 workstations had no issues accessing and sharing the network mapped backend database. The backend database became corrupted as the Windows 10 (1803) workstations were introduced into the database and performed extensive query and table operations. Evidently SMB changes are the culprit in the 1803 update and the following fix (and workstation reboot) worked for me which was applied to all the Windows 10 (1803) workstations in this environment. Copy and save the following text to notepad and save it as "SMBCacheFix.reg" (with quotes)

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"FileInfoCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
"DirectoryCacheLifetime"=dword:00000000

You may also review the "DisableLeasing" registry settings for Windows Server 2012 or above pertaining to the server side if the fix above does not resolve your problem.

@Fenious

This comment has been minimized.

Copy link

commented Jun 25, 2018

Exactly what I've been experiencing on my system. database becomes corrupted and unstable. it's not the kind of corruption when there's a bad write. it's unstable due to open handles , due to network interruption.

ITYIPMan, (with Adam) we applied the SMBCacheFix.reg to the windows 10 machines and so far, it seems to be working. If I experience a crash today, I'm rolling back the windows 10 to 1709. This has produced a lot of "unsettled" managers!

@TomDooher

This comment has been minimized.

Copy link

commented Jul 3, 2018

I got some feedback on the problem, their suggestion was changing the services from manual to automatic delayed start). I think your solution is the more accurate. so, when I go to add the dword string value, options are 32 or 64. Does that matter? The application is running on access 2003, but on both 32 and 64bit systems.

the test line I have:
FileInfoCacheLifetime REG_DWORD 0x00000000 (0)

Does that have correct values?

@ITYIPMan

This comment has been minimized.

Copy link

commented Jul 3, 2018

DWords registry keys are 32bit. All the systems that I've worked on are 64bit OS utilizing MSOffice 32bit applications. The registry settings above will work as they are but they need to be applied as a group of the 3 values as listed since they all interrelate to each other regarding the Windows OS network communication settings (not the MSOffice application). I did not apply this to the Windows 7 64bit machines but only the to the Windows 10 64bit OS which are all running the 1803 update. It's been just about 2 weeks with very stable operation and no database corruptions.

@TomDooher

This comment has been minimized.

Copy link

commented Jul 3, 2018

@Fenious

This comment has been minimized.

Copy link

commented Jul 3, 2018

Feedback...
It's now nearly two weeks since the problem. Accessfix1803.reg from ITYIPMan worked. yes. all three values were applied (just ran the .reg) So far, so good. not a single network interruption since.
And, yes, applied to just the Windows 10 1803 machines. I think they are all 64 bit.

@camtera

This comment has been minimized.

Copy link

commented Dec 22, 2018

Having this same issues with lots of Windows 10 PCs. Hopefully the @ITYIPMan registry fix will work (thank you).

Here is the @ITYIPMan registry file changes in zip format for easy download and install:
http://soft.cambus.com/scripts/SMBCacheFix3.zip
(please be very careful downloading registry mergers from the internet. this is provided as-is and incorporates the exact code seen above. please review the changes in notepad before merging)

Screenshot of before and after effects on the registry:
http://soft.cambus.com/scripts/smbfix-moreinfo.html

Please remember to reboot workstation after registry merge.

@ITYIPMan

This comment has been minimized.

Copy link

commented Mar 3, 2019

Just a follow-up for Spring 2019... It appears that newer Windows 10 feature updates (1809 and soon 1903) are being pushed out from Microsoft. With this in mind, it is unknown if these SMB settings will be reverted to their original settings. Attached is a "Check SMB Settings" batch script that can be run on each pc or from a network server to check the status of the applied registry settings. If settings need to be reapplied, use the SMBCacheFix3.zip link above to apply the SMB settings again. (Note: Please be very careful downloading scripts or registry settings from the internet. This is provided as-is and incorporates the read only query code to view the registry settings. Please review all scripts in notepad before executing any code.)

Check SMB Settings.zip

@alexmuch

This comment has been minimized.

Copy link

commented Apr 8, 2019

My machines are Windows 10 release 1809. What's the status on this registry fix? I don't see the FileInfoCacheLifetime, FileNotFoundCacheLifetime and DirectoryCacheLifetime keys. Was this issue fixed? Or do I need to manually create these registry keys?

@ITYIPMan

This comment has been minimized.

Copy link

commented Apr 9, 2019

By default, Windows 10 will not have these registry settings applied and will have to be applied manually or through a GPO. Some of our Windows 10 machines recently updated to 1809 from the 1803 version. The registry settings have remained intact after this upgrade. I personally have not tested 1809 without the registry settings since it was such an issue last April for the customers that I support. Personally, If its a new computer with 1809 and you are going to share a MSAccess database on the network, I would import the registry settings and reboot the Windows 10 computer. I haven't had any issues with the registry settings applied. The script that I posted above (Mar 3) allows you to easily "check" to see if the registry settings are applied.

@camtera

This comment has been minimized.

Copy link

commented Apr 9, 2019

Instead of my suggested fix above from Dec 22, 2018, we've found this registry tweak to work the best
http://soft.cambus.com/scripts/disableleasing-moreinfo.html

If you are seeing performance issues, I suggest using this approach ("DisableLeasing" entry), and remove the SMB fix. According to users in the below thread, there have been performance issues with smb fix although I never encountered them.

For more info, search 'performance' on this thread:
https://www.devhut.net/2018/06/13/access-bug-database-is-in-an-unrecognized-format/

@alexmuch

This comment has been minimized.

Copy link

commented Apr 9, 2019

Sorry, a couple more questions. How can I verify that my .mdb is in fact corrupted? I'm running into an "unrecognized format" error but I can still open my .mdb's in MS Access with valid data appearing. Does this mean my db's are not actually corrupt?

Also, is this fix exclusively for networked databases? My databases are created and used locally.

@illfated

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2019

It is difficult for anyone else to know if your DB is corrupt without being able to analyze it in person. The warning or error message is indication that something is not as good as it should be, so you should try to export your data to a new DB to test that all of your data is still valid for future use. Better safe than sorry, you know.

@camtera

This comment has been minimized.

Copy link

commented Apr 9, 2019

FWIW, Before the aforementioned fixes above, Access would indicate the database was corrupt and would always successfully repair. We never had to create a new DB and import tables from the corrupted DB.

@ZenMasta

This comment has been minimized.

Copy link

commented Apr 16, 2019

I have read that some people have moved the backend access mdb/accdb to Synolgy NAS with success. Has anyone here tried that?

@illfated

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2019

Please post discussions on more appropriate Microsoft Support forum pages.
This Github issue tracker is primarily aimed at improving the documentation pages.
Only post here if you have got constructive improvement suggestions for the page
https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features .

@mikedmd

This comment has been minimized.

Copy link

commented May 9, 2019

By default, Windows 10 will not have these registry settings applied and will have to be applied manually or through a GPO. Some of our Windows 10 machines recently updated to 1809 from the 1803 version. The registry settings have remained intact after this upgrade. I personally have not tested 1809 without the registry settings since it was such an issue last April for the customers that I support. Personally, If its a new computer with 1809 and you are going to share a MSAccess database on the network, I would import the registry settings and reboot the Windows 10 computer. I haven't had any issues with the registry settings applied. The script that I posted above (Mar 3) allows you to easily "check" to see if the registry settings are applied.

I just got the Access Corruption Errors again today! We installed 1809 a few weeks ago with no issue until now. My fix back in Aug 2018 was to add the Disableleasing reg entry on the Win 10 server, no workstation updates and that worked great. I just checked the server registry and that entry is missing! I put it back and will see how it goes tomorrow. I am assuming the server reg change, getting rid of the entry, was made with the 1809 install, and it took 2 weeks to show up as an error??

@alexmuch

This comment has been minimized.

Copy link

commented May 9, 2019

Hey everyone, I found the problem that was causing my "unrecognized database format" error. There was a KB released in January 2019 that caused this problem for '97 format Access databases that have fields containing >32 characters. A KB in February 2019 fixed this issue. For more information, look here

https://answers.microsoft.com/en-us/windows/forum/all/kb4480116-and-kb4480970-failure-getting-access-to/d701b681-2491-4891-baf6-e3a25b5d2bb7?page=3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.