• Question

  • We are a company in Greece called ADAsoft and we have developed few years back an Access2003 application in VBA. This application .mde  (frontend) connects to a backend database .mdb which is located in another network computer. After April update 1803 the following happened:

    When the .mde application runs on a computer that is updated with 1803 and accesses the database .mdb alone then works fine when a second computer that is also updated with 1803 accesses the same database immediately corrupts the database. 

    We managed to restore a computer before 1803 update and worked fine and the problem disappeared. This means that 1803 update did something and damaged Access 2003 frontend - backend working applications.

    Please report this problem. Many companies are still using Access 2003 and all of the sudden to not have any product.

    If you have any ideas please contact us to

    Monday, May 14, 2018 9:04 AM

All replies

  • Is cumulative update KB4103721 is correcting the problem?
    Monday, May 14, 2018 10:01 AM
  • Hello. Same problem here. After updating Windows 10 to 1803 version, everybody in the organization starts corrupting Access mdb frequently. I've tried everything. They are using Access 2003 runtime, not complete Microsoft Access 2003. Can anyone help me, please? I'm afraid of losing data, with this constant database corruptions.

    I also know that this update stops Excel 2003 from working properly but there is a workaround that involves Office 2003 SP3. But regarding Access 2003 I still haven't found a solution. any help would be truly appreciated.


    Bruno Bernardino

    Wednesday, May 23, 2018 4:01 PM
  • No does not. I see the OS build in the computers causing the problem and they have exactly the same build as my computer that has this update. Does the cumulative update affects the OS build?
    Wednesday, May 23, 2018 7:26 PM
  • I have some thoughts to share.

    Our frontend access the backend using map network drive maybe this is the problem. Try to use ip address with or direct path. We will try that.

    Another thing maybe the problem is caused because frontend reside under program files folder. In my computer which has 1803 and cumulative update when i try to copy something from file server through a map network drive in a folder under program files says that cannot access the network location. If i do the same outside program files does it perfectly STRANGE!!!!

    I think 1803 messed up network accesses.

    Please try to ppress Microsoft to see this problem. Thousands of people using Access 2003.

    Wednesday, May 23, 2018 7:34 PM
  • Hello! I think Program Files folder location may not be the issue. My mde frontend is in a C:\ folder and I have the same problems. However, it only happens when a big piece of instructions in a Function, with a lot of recordsets is called. And mdb backend (stored in a Windows 2012 R2 Standard Server), accessed through mapped drive, keeps constantly being corrupted. Microsoft hasn't said anything about this. I'm going crazy!!!
    Monday, May 28, 2018 8:55 AM
  • We also have this issue across multiple clients and locations and seems to affect all of the Access runtimes 2003, 2013 and 2016. Is not specific to one make of hardware or server OS

    Does seem to be when a vba function uses lots of recordsets but something in feature update 1803 immediately corrupts the data.

    We run the mde from a C:\Folder with a mapped drive to a server share for the data.

    Only way we have found to resolve is to roll back to 1709 and delay updates for as long as possible. 

    Can somebody from Microsoft please investigate and respond

    Thursday, May 31, 2018 2:42 PM
  • DO not use mapped drive use network adresses //SERVER//....... it solved the problem to us we have a compter updated to 1803 and works fine. NO MAPPED DRIVES
    Thursday, May 31, 2018 6:44 PM
  • DO not use mapped drive use network adresses //SERVER//....... it solved the problem to us we have a compter updated to 1803 and works fine. NO MAPPED DRIVES
    Thursday, May 31, 2018 6:44 PM
  • DO not use mapped drive use network adresses //SERVER//....... it solved the problem to us we have a compter updated to 1803 and works fine. NO MAPPED DRIVES
    Thursday, May 31, 2018 6:45 PM

    I can definetely confirm the problems cause. Running different Access 2002/2003/2007/2010 apps.

    We have a network with dozens!!! of PC where every network access through a mapped drive is NOT possible anymore.

    The phone call came in at 7 am and we're been furiously trying to locate the problem since then.

    This needs to be solved ASAP.

    • Edited by user7712 Friday, June 1, 2018 7:33 AM
    Friday, June 1, 2018 7:32 AM
  • Our company, too, is experiencing this issue, and my fellow employees are getting extremely irritated with the back-end corrupting regularly all day long.

    What is the best way to contact Microsoft about this issue?


    Friday, June 1, 2018 4:07 PM
  • DO not use mapped drive to access with the backend use network adresses //SERVER//....... it solved the problem to us we have a compter updated to 1803 and works fine. NO MAPPED DRIVES
    Friday, June 1, 2018 5:53 PM
    Sunday, June 3, 2018 3:18 PM
  • Using the UNC path for the tables does sometimes stop this but we have clients using UNCs for their linked tables that still experience immediate corruption of Access DBs when 1803 is installed.

    Not being able to roll the update back after 10 days is also a huge pain.

    Is anybody from Microsoft monitoring this thread??

    Wednesday, June 20, 2018 11:45 AM
  • So glad to read this thread. I'm having the same problem. We run Server 2016, 15  workstations, Win 10 PC's 1803. Office 365. Access 2016 32 Bit

    Since we upgraded all the workstations to 1803 our backend Data file gets corrupted 2-3 times a day.

    I've been going off in ten different directions trying to figure it out. Today I installed the front & backend on a 

    local workstation just to eliminate the network. Its working fine. 1803 seems to have problems with the Shared

    folder on the network. I found some blogs regarding SMB service in Win 10 & server 2016 where users claim SMB

    was corrupting their Datafile but the thread got a little over my head. I going to roll back to 1709 on a few workstations tomorrow.

    • Proposed as answer by ITYIPMan Friday, June 22, 2018 2:25 AM
    • Unproposed as answer by ITYIPMan Friday, June 22, 2018 2:25 AM
    Wednesday, June 20, 2018 10:02 PM
  • 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


    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.

    • Proposed as answer by ITYIPMan Friday, June 22, 2018 3:22 AM
    Friday, June 22, 2018 3:21 AM
  • Hello! Microsoft has finally launched a fix that addresses SMB v1 problem that keeps corrupting access databases.

    Has anyone installed it? Any improvement regarding this issue? I'll be installing this on monday in my client's workstations W10 1803. Thanks!

    Friday, July 6, 2018 12:36 PM
  • I have installed the KB4284848 upgrade on all of my Win 10 workstations and am STILL having the problem.  I have implemented other suggestions made in this thread such as using urls instead of mapped drives, etc.

    Has anyone out there really solved the problem?


    Monday, July 9, 2018 5:47 PM
  • I may be late to the party but I just discovered this from Microsoft:

    Monday, July 9, 2018 6:02 PM
    Monday, July 16, 2018 9:03 AM
  • Applied this to a customers windows 10 1803 PCs with the same problem they were having the problem several times day. They haven't had a problem in two weeks.


    Tuesday, July 24, 2018 7:58 AM
  • What did you apply what ?   patch ???  
    Wednesday, August 1, 2018 5:53 PM
  • What did you apply?


    Friday, August 3, 2018 10:37 PM
  • No Windows updates have fixed this for us.  We have installed the latest CU July 2018 for 1803  Trying the Registry change now located at:  To see if this helps.

    The registry change, made only on the server (windows 10), seems to have fixed the issue for us.  I hope leaving the registry change causes no issues.

    • Edited by Miked916 Thursday, August 9, 2018 11:57 PM
    Wednesday, August 8, 2018 4:29 PM
  • This fix in the article link above worked for me. 

    The environment is MS Access database back-end (2007 format) on Windows Server 2012 Standard.  Around 10 client Windows PCs, 2 with Windows 7, 2 with Windows 8, the rest with Windows 10 (with 1803 release) which I assume is the culprit.  The client PCs either use Access 2007 or Access 2013, which has never caused a problem in the past.

    The "Access error 3343" strangely began a couple of weeks ago, just once or twice.  This week, on Monday morning, the error occurred about 5 times within a 2 hour period.  Ridiculous! The last time of which badly damaged a table in the back-end database so that Compact/Repair had to be done several times and a couple of corrupted records removed before the primary index could be re-built. I ended up exporting the tables into a new .accdb file for good measure.

    Since applying the "DisableLeasing" fix above, "touch wood for luck", on Monday afternoon, there have been zero issues.  There are 10 or so regular simultaneous connections to the database.

    I have to confess I'm pretty angry about the whole thing!  It's caused much pain for my customers and a lot of sleepless nights for me.  Is this a kind of self-destruct action by Microsoft to kill off Access?

    According to the article dated June 14th. 2018 "The engineering team is aware of and working to fix this issue...".  I'm flabbergasted that this is taking so long to fix. I can only imagine how much downtime there has been worldwide, as this personally has brought my clients to a standstill.  Worthy of national news?

    Hope others are coping.

    Thursday, August 23, 2018 10:19 AM
  • Also for me the REG key solved the problem.

    "The engineering team is aware of and working to fix this issue..."

    June... July... August... September... any news?

    Collateral effect about DisableLeasing workaround?


    Friday, September 14, 2018 2:01 PM
  • Hello I have the same problem after installing update 1803, i hoped it will disappear with 1809 but still the same problem, Has somebody a solution found for the problem?
    Friday, November 2, 2018 10:14 AM
  • We have an Access application that uses a backend accdb database file. We have many clients using Windows server that get the inconsistent database problem with the backend database. Access compacts and repairs which usually works but it is a real nuisance. Sometimes the database is beyond repair which causes big problems. I have found the DisableLeasing registry entry on the server fixes the problem so far. However, I do get resistance when asking a customer to do this as it affects the entire server and all file sharing and may have performance ramifications. I think I ran across a way to turn off leasing mode on the server for a particular share instead of the entire server. I am wondering if anyone else has tried this and had any success. If it works, I can suggest to my clients to place our backend database in its own folder and share that folder. Then set the leasing mode to none on that share only. The command you can issue in powershell (run as admin to start powershell) is "set-smbshare <name> -LeasingMode None" where <name> is the share name. Has anyone tried this instead of the registry entry to disable leasing on the entire server? It may require Windows Server 2012 or Windows 8 or later. Lastly, it is worth asking I guess. Has Microsoft has come out with anything new as a fix or suggestion for this problem?
    Tuesday, February 5, 2019 9:56 PM