[English]Noch eine kurze Information für 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ört. Es kommt zum Fehler "unknown database format".
Anzeige
Erste Nutzermeldungen
Die erste Meldung zu diesem Sachverhalt kam von Blog-Leser Ollat in diesem Kommentar (danke dafür). Dort schrieb er:
Seit dem Update funktioniert unserer Software, welche sich mit Access 97 Datenbanken nutzt nicht mehr. Vorsicht!
Gibt es ähnliche Fälle? Kann im Netz leider nichts dazu finden…
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ält folgende Informationen.
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
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äre das sicher hilfreich.
Auf Microsoft Answers gibt es diesen Forenthread, wo der gleiche Entwickler das Szenario beschreibt. Die Deinstallation des Updates beseitigt das Problem – so dass die oben vorgeschlagene Konvertierung in ein neueres MDB-Format wenig zielführend ist. Ein zweiter Benutzer gibt noch den Hinweis auf den 'Runtime Error 3343 Unrecognized database Format'.
Anzeige
Ein windiger Workaround
Im Verlauf des MS Answers-Forenthreads gibt es einen Workaround, der allerdings Nebenwirkungen hat. Jemand hat schlicht die betreffende msrd3x40.dll vom 8. Januar 2019 durch eine ältere Version ersetzt. Danach lief der Datenbankzugriff wieder. Die DLL befindet sich im Windows-Unterordner syswow (siehe auch diesen Microsoft-Artikel).
Die Datei msrd3x40.dll gehört zur Jet Database Engine, wie man z.B. diesem Microsoft-Dokument entnehmen kann. Das Problem: Microsoft hat die betreffende msrd3x40.dll aktualisiert, weil auch Schwachstellen in der Jet Database Engine behoben wurden.
Ich hatte dies z.B. im Blog-Beitrag Patchday: Updates für Windows 7/8.1/Server 8. Jan. 2019 erwähnt. Wird jetzt eine alte Version der DLL in den Windows-Unterordner syswow kopiert, ist der Sicherheitspatch für die geschlossenen Schwachstellen natürlich wirkungslos.
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ßt wohl die Jet Database Engine-Schwachstelle auf. Leider hat Microsoft das noch nicht als 'known issue' aufgeführt.
Anmerkung: Ich habe jetzt diesen MS Answers Forumthread an die Microsoft-Moderatoren eskaliert, in der Hoffnung, dass das Thema an die Software-Entwickler weiter gereicht wird.
Nachtrag: Microsoft hat den Fehler – möglicherweise auf Grund meiner obigen Aktion – bestätigt – siehe meinen Blog-Beitrag Access 97-MDB-Fehler in Jet Datenbank Engine durch Windows Januar 2019-Updates bestätigt.
Ergänzung: Im MS Answers-Forenthreads gibt AJakobs noch einen interessanten Hinweis. Man kann versuchen, den Data Source-Provider von:
"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=<MyAccessDatabase>.mdb"
auf
"Provider=Microsoft.Jet.OLEDB.3.51;Data Source=<MyAccessDatabase>.mdb"
umzustellen. Zumindest die Data Access Object-Schnittstelle (DAO 3.51) funktioniert mit den Windows-Patches, während die neuere DAO 3.6 den gleichen Fehler bringt.
Alle Windows-Updates betroffen
Bei administrator.de hat ein Nutzer diesen Post eingestellt, der eigentlich alle Sicherheitsupdates vom 8. Januar 2019 für Windows nennt. Ich habe meine Update-Beschreibungen mal kontrolliert. Bei folgenden Sicherheitsupdates wurde die Jet Database Engine gepatcht.
- KB4480116 für Windows 10 Version 1809
- KB4480966 für Windows 10 Version 1803
- KB4480978 für Windows 10 Version 1709
- KB4480973 für Windows 10 Version 1703
- KB4480961 für Windows 10 Version 1609
- KB4480962 für Windows 10 Version 1507
- KB4480963 (Monthly Rollup) für Windows 8.1
- KB4480964 (Security Only) für Windows 8.1
- KB4480970 (Monthly Quality Rollup) für Windows 7 SP1
- KB4480960 (Security-only update) für Windows 7 SP1
Die Updates stehen teilweise auch für die jeweiligen Server-Pendants bereit. Details sowie die Änderungen an der Jet Database Engine sind in den nachfolgend verlinkten Blog-Beiträgen erwähnt.
Ähnliche Artikel:
Patchday Windows 10-Updates (8. Januar 2019)
Patchday: Updates für Windows 7/8.1/Server 8. Jan. 2019
Anzeige
Ich habe Access-DB's vom Format *.accdb (Access ab 2007) im Einsatz.
Laufen alle mit Access-Runtime 2010, 2013 und 2016.
Sowohl unter Windows 10 Pro 18.09 wie auch unter Windows 7 Home Premium SP1 tritt der beschriebene Fehler nach Installation der genannten Updates bei mir NICHT auf.
Danke: Dann liegt es eindeutig am Access 97 MDB-Format. Frage: Ließe sich eine Access 97 MDB-Datei ohne weiteres in Access 2007 *ACCDB konvertieren und eine Anwendung, die den Jet Database OLEDB 4.0-Data Source-Provider verwendet, würde noch funktionieren? Ich bin aus dieser Ecke seit 10 – 15 Jahren raus.
Wenn man eine umfangreiche Datenbank unter Access 97 hat, würde ich eine Konvertierung auf ein neueres Access nicht riskieren. Bei meinem damaligen Arbeitgeber war eine unter Access 97 entwickelte Datenbank mit etlichen Hundert größtenteils verknüpften Tabellen und sehr umfangreichen Programmroutinen fast 20 Jahre im Einsatz. Die Entwicklung dauerte 2 Jahre und war nicht gerade billig. Die Admins wollten auf ein neueres Office umstellen, der Programmierer warnte eindringlich davor. Es hätte der komplette Programmcode neu getestet werden müssen, da es etliche Änderungen im VBA der Nachfolgeversionen gab. Mit der Datenbank wurden Anteilsberechnungen durchgeführt und daraus mehrere hundertausend in sich schlüssige Buchungsdatensätze in den Großrechner automatisiert übertragen sowie Nachweise für den Jahresabschluss erzeugt. Bereits ein einziger Rundungsfehler hätte mehrere Tage Fehlersuche und -bereinigung bedeutet.
Das ist richtig, das Problem tritt anscheinend nur mit Access 97 .MdB Datenbanken auf.
Auch ist im Test aufgefallen, dass nur Datenbanken mit Spaltennamen>32 Zeichen betroffen sind.
Der Austausch der .dll Dateien oder die Deinstallation hilft.
Leider ist das beides keine wünschenswerte Lösung für tausende von Clients (…)
Hoffentlich nimmt MS sich dem Thema an :)
Ich habe es oben im Text nachgetragen: Ich habe das den Tread im US MS Anwers-Forum an die Microsoft Moderatoren eskaliert. Damit bekommen es einige Leute zu Gesicht – denke, die leiten es an die Entwickler weiter, da ich noch den MVP im MS Answers-Profil habe und die relevanten Details im Forenthread sowie in meinem englischsprachigen Blog-Beitrag zusammen getragen sind.
VM mit Win7Prof und Access 2000, KB4480960: Mitgebrachte Beispieldatenbank („Nordwind") und eine selbst erstellte (einfachere) Datenbank lassen sich ohne Fehler öffnen.
Trotzdem danke für die Warnmeldung, sonst hätte ich KB4480960 früher oder später auf meine Arbeitsrechner losgelassen.
Ein, zwei Monate ging's mit den Updates gut, nun wieder Russisches Roulette. Offenbar hat MS alle fähigen Leute als „EOL" ausgemustert.
Ich kann dieses Fehler bei Access 97 Datenbanken bestätigen.
Es liegt tatsächlich an einer Feldnamenbezeichnung mit mehr als 32 Zeichen.
Der Zugriff auf die Datenbank über DAO ist weiterhin problemlos möglich (übrigens auch nach wie vor deutlich schneller als ADO).
Besonders fatal: Wenn man mit ADO die Access 97 Datenbank komprimiert/repariert (JRO.CompactDatabase), so werden dabei alle Tabellen gelöscht, die Felder mit Feldnamenbezeichnung größer 32 Zeichen enthalten.
Es wurde nun in den Known Issues nachgetragen und es werden auch einige Tipps gegeben.
https://support.microsoft.com/en-us/help/4480960
https://support.microsoft.com/en-us/help/4480970
Danke, ich habe es gerade gesehen – bin noch am recherchieren, vermutlich hat mein Eingreifen (ich habe einen US-Forenthread an MS-Mods eskaliert) das Thema hochgespült. Ich schreibe gleich noch einen Beitrag zu – so einige Ansätze von MS sollten mit Vorsicht behandelt werden, wenn man sich nicht um Kopf und Kragen bringen will.
Die Lösungsvorschläge sind doch absurd.
Warum soll man die Spaltenbezeichnungen mit viel Aufwand (die Anwendung muss an allen Stellen entsprechend neu programmiert werden) auf 32 Zeichen kürzen, wenn 64 Zeichen laut Definition erlaubt sind.
Die Frage ist doch, warum hier ein offensichtlicher Fehler, der keinerlei Sinn ergibt, nicht unmittelbar von Microsoft behoben wird, und stattdessen alternative Lösungen vorgeschlagen werden, die mit viel Aufwand für Entwickler und entsprechenden individuellen Nachteilen verbunden sind.
Na ja, ganz so ist es auch nicht. Sie schreiben doch ganz eindeutig, dass sie an einer Lösung arbeiten und diese für Anfang Februar in Aussicht stellen.
Ich persönlich habe mit diesem Zeitfenster kein Problem, da wir mittels DAO auf die Datenbank zugreifen und somit keine Zugriffsprobleme haben. Lediglich das Komprimieren und Reparieren haben wir über ADO gelöst, da hier manche Fehler besser und schneller gelöst werden, als mittels DAO. Ich habe nun den freien Samstag dazu genutzt, diese Funktion zu fixen, so dass beim Kunden eben nicht Tabellen und damit Daten gelöscht werden.
Nun stelle ich mir aber einen Entwickler vor, der auch den Zugriff über ADO umgesetzt hat (er wird seine entsprechenden Gründe haben).
Und nun stelle ich mir vor, er hat seine Anwendung bei hunderten von Kunden im Einsatz.
Eine Lösung für Anfang Februar dürfte eine kleine Katastrophe sein.
Er muss entweder bei allen Kunden das Update entfernen, oder aber in vielen Stunden die Datenbank auf eine neue Version konvertieren.
Das kann man zwar schnell programmieren, aber dennoch wird man das gemeinsam mit allen Kunden kommunizieren/durchführen.
Und der Entwickler wird einen Grund haben, warum er bislang eben seine Datenbank nicht auf ein neue Version konvertiert hat (haben wir auch).
@Detlef: Genau diese Punkte möchte ich im Folgebeitrag aufgreifen. Auch das Konvertieren scheint Kollateralschäden zu haben.
Was man vielleicht noch dringend an Microsoft weitergeben sollte ist die Problematik mit CompactDatabase (ist aktuell nicht bei Known issues erwähnt). Denn wenn nun kein Zugriff möglich ist und dabei vermeidlich die Datenbank als beschädigt rückgemeldet wird, ist es naheliegend, dass die Datenbank repariert wird.
Führt man nun CompactDatabase aus, werden alle Tabellen (und damit die Daten) gelöscht, die Feldnamen mit mehr als 32 Zeichen haben. Sollte dann keine Sicherung vorhanden sein …
@Detlef: Danke für den Hinweis – ich versuche es über meine Funktion als Communitymoderator – es gibt einen Nachtrag von mir im betreffenden Forenthread – direkt Kontakte bei MS habe ich leider nicht.
Guten Tag,
Frage eines Laien: ich habe nach dem o.g. Windows-Update einfach die access database engine 2010 installiert, danach funktioniert alles wieder – anschließend manuell nochmal Windows-Update angestoßen, dann werden ein paar MS-Office 2010-Updates geladen. Sind dann die Schwachstellen in der Jet Database Engine wieder offen? Und kann das andere Probleme machen?
Hallo, ich habe derzeit auch ein Access-Problem. Ich möchte gerne ein Anwaltsprogramm vom Anwaltverlag testen. Die Testversion habe ich installiert. Das Programm läuft nicht. Es kommt der Hinweis: "Diese Datenbank weist ein unbekanntes Format auf. Die Datenbank wurde möglicherweise mit einer späteren Version von Microsoft Access als der, die Sie momentan ausführen, erstellt. Führen Sie für Ihre Version von Microsoft Access ein Update auf die aktuelle Version durch und öffnen Sie dann die Datenbank erneut.
Jetzt habe ich folgendes Problem: Ich arbeite unter Windows 7 noch mit Office 11, aus dem Jahre 2003, das mit Windows 7 kompatibel ist. Welche Version von Access in Office 11 enthalten ist, kann ich nicht erkennen (bin EDV-Laie). Es ist dann wohl nicht damit getan, daß ich "ein Update auf die aktuelle Version" durchführe.
Alle aktuellen Updates von Microsoft bis einschließlich heute 14.3.2019, habe ich installiert.
Was kann ich jetzt noch tun? Dem Verlag habe ich das Problem gemeldet. Denen war das unbekannt.
Vielen Dank für Ihre Unterstützung.
R. Binder
Ich habe aktuell ein Problem das sich genauso darstellt. Allerdings Windows 10 mit Access 2003 (Datenbank hat auch 2003er Format). Das System läuft seit 10 Jahren problemlos. Letze Woche 2 neue Rechner Windows 10/alle Updates inkl. "Updates für andere Microsoft Produkte" sind installiert. Frontend auf den Clients, Backend auf dem Server. Es laufen jetzt die 2 neuen Rechner und 2 ältere mit WIN7. Sobald jemand an einem von den 2 WIN 10 Rechnern arbeitet kann man die Minuten zählen bis die Meldung "Unbekanntes Datenbankformat" kommt. Die DB muss dann repariert werden. Danach läuft es wieder eine Zeitlang. Dann wieder Fehler.
Hat da jemand eine Info?
Gruss
Thomas
Hallo!
Ich habe das gleiche Problem.
Hast Du mittlerweile Abhilfe gefunden?