{"id":213643,"date":"2019-01-11T12:23:59","date_gmt":"2019-01-11T11:23:59","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=213643"},"modified":"2021-02-15T02:33:19","modified_gmt":"2021-02-15T01:33:19","slug":"access-datenbankprobleme-nach-januar-2019-updates","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2019\/01\/11\/access-datenbankprobleme-nach-januar-2019-updates\/","title":{"rendered":"Access Datenbankprobleme nach Januar 2019-Updates"},"content":{"rendered":"

[English<\/a>]Noch eine kurze Information f\u00fcr Nutzer, die mit Access-Datenbanken arbeiten. Seit der Installation der Sicherheitsupdates vom 8. Januar 2019 ist der Access-Datenbank-Zugriff unter allen Windows-Versionen gest\u00f6rt. Es kommt zum Fehler \"unknown database format\".<\/p>\n

<\/p>\n

Erste Nutzermeldungen<\/h2>\n

\"\"Die erste Meldung zu diesem Sachverhalt kam von Blog-Leser Ollat in diesem Kommentar<\/a> (danke daf\u00fcr). Dort schrieb er:<\/p>\n

Seit dem Update funktioniert unserer Software, welche sich mit Access 97 Datenbanken nutzt nicht mehr. Vorsicht!<\/p>\n

Gibt es \u00e4hnliche F\u00e4lle? Kann im Netz leider nichts dazu finden\u2026<\/p><\/blockquote>\n

Der Blog-Leser hat dann noch diesen Forenpost verlinkt, wo er das Windows 10-Update KB4480116 und das Windows 7-Update KB4480970 vom 8. Januar 2019 als Ursache nennt. Der Post ist aus Entwicklersicht verfasst und enth\u00e4lt folgende Informationen.<\/p>\n

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 ?<\/p>\n

The same problem we have on Windows 7 after the KB4480970 installation of January 8th<\/p><\/blockquote>\n

Im Forenthread wird zwar geraten, die Access-Datenbank auf das Access 2007-Datenformat umzustellen. Das nutzt Endkunden nichts, und ich bin auch nicht sicher, dass das wirklich was bringt. Falls Blog-Leser Ollat da was zu sagen kann, w\u00e4re das sicher hilfreich.<\/p>\n

Auf Microsoft Answers gibt es diesen Forenthread<\/a>, wo der gleiche Entwickler das Szenario beschreibt. Die Deinstallation des Updates beseitigt das Problem \u2013 so dass die oben vorgeschlagene Konvertierung in ein neueres MDB-Format wenig zielf\u00fchrend ist. Ein zweiter Benutzer gibt noch den Hinweis auf den 'Runtime Error 3343 Unrecognized database Format'.<\/p>\n

Ein windiger Workaround<\/h2>\n

Im Verlauf des MS Answers-Forenthreads<\/a> gibt es einen Workaround, der allerdings Nebenwirkungen hat. Jemand hat schlicht die betreffende msrd3x40.dll<\/em> vom 8. Januar 2019 durch eine \u00e4ltere Version ersetzt. Danach lief der Datenbankzugriff wieder. Die DLL befindet sich im Windows-Unterordner syswow <\/em>(siehe auch diesen Microsoft-Artikel).<\/p>\n

Die Datei msrd3x40.dll<\/em> geh\u00f6rt zur Jet Database Engine, wie man z.B. diesem Microsoft-Dokument<\/a> entnehmen kann. Das Problem: Microsoft hat die betreffende msrd3x40.dll<\/em> aktualisiert, weil auch Schwachstellen in der Jet Database Engine behoben wurden.<\/p>\n

Ich hatte dies z.B. im Blog-Beitrag Patchday: Updates f\u00fcr Windows 7\/8.1\/Server 8. Jan. 2019<\/a> erw\u00e4hnt. Wird jetzt eine alte Version der DLL in den Windows-Unterordner syswow <\/em>kopiert, ist der Sicherheitspatch f\u00fcr die geschlossenen Schwachstellen nat\u00fcrlich wirkungslos.<\/p>\n

Damit kann man nur Teufel mit Belzebub austreiben: Entweder man deinstalliert das komplette Sicherheitsupdate (siehe unten) und ist ungepatcht. Oder man ersetzt die DLL, und rei\u00dft wohl die Jet Database Engine-Schwachstelle auf. Leider hat Microsoft das noch nicht als 'known issue' aufgef\u00fchrt.<\/p>\n

Anmerkung:<\/strong> Ich habe jetzt diesen MS Answers Forumthread<\/a>\u00a0an die Microsoft-Moderatoren eskaliert, in der Hoffnung, dass das Thema an die Software-Entwickler weiter gereicht wird.<\/p>\n

Nachtrag: Microsoft hat den Fehler – m\u00f6glicherweise auf Grund meiner obigen Aktion – best\u00e4tigt – siehe meinen Blog-Beitrag\u00a0Access 97-MDB-Fehler in Jet Datenbank Engine durch Windows Januar 2019-Updates best\u00e4tigt<\/a>.<\/p><\/blockquote>\n

Erg\u00e4nzung:<\/strong> Im MS Answers-Forenthreads<\/a> gibt AJakobs noch einen interessanten Hinweis. Man kann versuchen, den Data Source-Provider von:<\/p>\n

\"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=<MyAccessDatabase>.mdb\"<\/p>\n

auf<\/p>\n

\"Provider=Microsoft.Jet.OLEDB.3.51;Data Source=<MyAccessDatabase>.mdb\"<\/p>\n

umzustellen. Zumindest die Data Access Object-Schnittstelle (DAO 3.51) funktioniert mit den Windows-Patches, w\u00e4hrend die neuere DAO 3.6 den gleichen Fehler bringt.<\/p>\n

Alle Windows-Updates betroffen<\/h2>\n

Bei administrator.de hat ein Nutzer diesen Post<\/a> eingestellt, der eigentlich alle Sicherheitsupdates vom 8. Januar 2019 f\u00fcr Windows nennt. Ich habe meine Update-Beschreibungen mal kontrolliert. Bei folgenden Sicherheitsupdates wurde die Jet Database Engine gepatcht.<\/p>\n