Windows January 2019 Updates breaks access to Access DBs

[German]A brief warning for users are using Windows application accessing MS Access 97 databases. Windows security updates from January 8, 2019, breaks access to MS Access 97 databases (affects all Windows versions). An “unknown database format” error occurs. Here are some more details. Update: Microsoft has confirmed this issue.


Advertising


First user messages

The first message on this issue reached me from blog reader Ollat in this comment within my German blog (thanks for that). He wrote:

Caution! Since the update our software does not work anymore, which uses itself with Access 97 databases.

Are there similar cases? Can’t find anything on the net…

He linked to this forum post, where he blamed Windows 10 update KB4480116 and the Windows 7 update KB4480970, released on January 8, 2019. The post is written from the developer’s point of view and contains the following information.

After installing in Windows 10 the KB4480116, our application ( developed in VS2010 with Microsoft Access 97 database MDB ) detects an error “unknown database format” when accessing to Access 97 database. The exception starts on msvc100.dll provided by VS 2010. Removing the KB4480116 the issue disappears. How I can get support for this accident ?

The same problem we have on Windows 7 after the KB4480970 installation of January 8th

Addendum: Later on I received the information, that this error occurs, if a database has fieldnames with more than 32 characters. Another user wrote, that he received a ‘Runtime Error 3343 Unrecognized database Format’. Within the forum thread it is advised to convert the Access 97 database to the Access 2007 database format. But this is not possible for customers, who don’t have access to the source code. I also discussed this idea within the comments of my German blog. There was the feedback, that it will be risky, to convert a bigger Access 97 data base to the new Access 2007 data base format. It can end in a night mare (mission impossible), because the runtime environment for the later version of data base drivers has significant changed.

German blog reader Ollat also noticed, that the data base error “unknown database format” only occurs, if data table fields are longer as 32 characters.

Later I found at Microsoft Answers this forum thread, obviously startet from the same developer (I guess, it’s blog reader Ollat).

There are Workarounds

Uninstalling the Windows January 2019 updates will cure the issue. But this is risky, because those updates fixes critical vulnerabilities (for instance a PowerShell remote execution flaw). Within this MS Answers forum thread another user posted a (less riskier) workaround. Someone simply replaced the msrd3x40.dll v4.0.9801.7 from January 8, 2019 with an older version 4.0.9801.5 (from 25/09/2018). After that the Access 97 database was readable again. The DLL is located in the Windows subfolder syswow (see also this Microsoft article).


Advertising

Note: The file msrd3x40.dll belongs to the Jet Database Engine, as you can see within this Microsoft document.

The problem: Microsoft has updated the msrd3x40.dll file to fix vulnerabilities in the Jet Database Engine (see my blog post Patchday: Updates for Windows 7/8.1/Server Jan. 8, 2019 for instance). If an old version of the DLL is now copied to the Windows subfolder syswow, the Jet Database Engine vulnerability is still open (the patch is neutralized).

So you have two worse choices: Either you have to uninstall the complete security update (see below) and are unpatched. Or you can replace the DLL, and probably rip open the Jet Database Engine vulnerability. Unfortunately, Microsoft has not yet listed this as a known issue.

But there is another workaround user AJakobs mentioned within this MS Answers forum thread. He mentioned, that it’s possible to change the string defining the used Data Source Provider from:

“Provider=Microsoft.Jet.OLEDB.4.0;Data Source=<MyAccessDatabase>.mdb”

to

“Provider=Microsoft.Jet.OLEDB.3.51;Data Source=<MyAccessDatabase>.mdb”

AJakobs observed, that the Data Access Object interface (DAO 3.51) was able to access the Access 97 database, also after the Windows January 2019 patches has been installed, whilst the newer DAO 3.6 failed also with a data base format error.

All Windows January 2019 Updates affected

At German site administrator.de a user has published this post, mentions all Windows January 2019 Updates are affected. So I went into my blog and checked the update description for Windows 7 up to Windows 10. Indeed, alle security updates enlisted below are patching the Jet Database Engine.

Some of these updates are also available for the respective server counterparts. Details as well as the changes to the Jet Database Engine are mentioned in the following linked blog posts.

Note: I’ve escalated this MS answers forum thread to Microsoft’s moderators. Let’s hope, they bring the issue to attention of their software developers.

Addendum: Microsoft has confirmed the bug within the know issue section in the kb articles of all Windows security patches. Will write a follow up article, that also sheds light to Microsoft’s recommendation (and the pitfalls).

Similar articles:
Patchday: Updates for Windows 7/8.1/Server Jan. 8, 2019
Patchday Windows 10-Updates (January 8, 2019)
Update KB971033/KB4480960/KB4480970 bricks Windows 7 Genuine (0xc004f200)
Microsoft explains the Windows 7 KMS activation issue
Network issues with updates KB4480970 and KB4480960


Advertising


This entry was posted in issue, Security, Software, Update, Windows and tagged , , , , , . Bookmark the permalink.

9 Responses to Windows January 2019 Updates breaks access to Access DBs

  1. Susan Bradley says:

    I just noticed that in the Windows 10 release notes it has this info:
    Applications that use a Microsoft Jet database with the Microsoft Access 97 file format may fail to open if the database has column names greater than 32 characters. The database will fail to open with the error, “Unrecognized Database Format”.
    Use one of the following options:
    Option 1: Modify the database to ensure that all column names are less than or equal to 32 characters.
    Option 2: Convert the database to the .accdb file format. To use the .accdb file format, you must change the Connection string after conversion.
    The easiest way to convert is to use Microsoft Access 2010 or earlier.
    Use Microsoft Access to open a database that has an older file format.
    You will be asked if you would like to convert. Click Yes and save the database with the .accdb extension.
    Option 3: Convert the database to a newer .mdb file format. This doesn’t require a change to the Connection string.
    Use Microsoft Access to open a database that has an older file format.
    You will be asked if you would like to convert. Click Yes and save the database with the .accdb file extension.
    Open the .accdb.
    From the File menu, click Save as and select Access 2002-2003 Database.
    Microsoft is working on a resolution and estimates a solution will be available early February.

    • guenni says:

      Susan: Thanks, I just read your post at askwoody.com. I had to take a ‘nap this night’ – while it’s ‘workday in the US’. It seems, that the thread in MS Answers I’ve escalated Friday (evening here in Europe, Morning in US west coast) brought things to attention of the right people.

      I will write an additional article, because I won’t recommend all suggestions from MS in the know issues section. I’ve discussed several scenarios like converting the database format. There are many pitfalls – and I would not take the risk, that a huge application with a complex .mdb database will work flawless after conversion. Even, if all program access operation works without an error message – you need to be sure, that the data integrity is given after conversion. Think about a book keeping system – if you change the database and math operation are causing wrong rounding errors, it will be fatal. I’ve also read this morning reports from users, that warns: Conversion with ADO for instance will strip the fieldnames with length > 32 characters of the database.

      • Paul says:

        Thanks! I’ve been using a book keeping application that works fine other than i’m not being able to open the print or layout-adjustment dialog when making new invoices since the January updates. e.g. I cannot print new invoices or save them to PDF.

        I’ve tried opening the DB in acces and resaving it in a newer format, but it makes no difference. I ended up installing my software in a Win7 VM to do my bookkeeping.

        I hope your effort will result in Microsoft fixing the issue, thanks in advance!

  2. Pingback: Patch Lady – issues with Win10 Access 97 @ AskWoody

  3. AJakobs says:


    He mentioned, that it’s possible to change the string defining the used Data Source Provider from:

    “Provider=Microsoft.Jet.OLEDB.4.0;Data Source=.mdb”

    to

    “Provider=Microsoft.Jet.OLEDB.3.51;Data Source=.mdb”

    Mind you, you’ll ofcourse need to have the 3.51 provider installed, in contrary to 4.0, 3.51 does not ship by default with windows.

    • guenni says:

      Thx for your addendum.

      • AJakobs says:

        And another addendum which is more interesting:

        “Provider=Microsoft.ACE.OLEDB.12.0;Data Source=.\.mdb;User Id=admin;Jet OLEDB:Database Password=;Jet OLEDB:Engine Type=4”

        Works perfectly for also creating databases (at least the one we created). And the advantage is that ACE is already available on more PC’s, but it’s also still available directly from Microsoft (3.51 is only available from CNET and not 100% sure ofcourse if it’s still the original from microsoft).

        • AJakobs says:

          oh my god… After installing AccessDatabaseEngine 2016 the ACE.OLEDB.12 provider doesn’t work anymore. Only with AccessDatabaseEngine 2010 will it work (without 2016, so ACE.OLEDB.16 installed), it won’t even work installing 2010 after 2016.

  4. chris says:

    We have been experiencing this datafile crash thing since last may 2018 … not sure it has anything to do with a 2019 update… I will tell you that we are on automatic update in windows.

Leave a Reply to guenni Cancel reply

Your email address will not be published. Required fields are marked *