[English]Microsoft hat den Datenbankfehler beim Zugriff auf Access 97 .mdb-Datenbanken per Jet Database Engine bestätigt. Das Problem wird in allen unterstützten Windows-Versionen durch die Sicherheitsupdates vom 8. Januar 2019 verursacht.
Anzeige
Einige Hintergrundinformationen
Ich hatte das Thema gestern im Blog-Beitrag Access Datenbankprobleme nach Januar 2019-Updates, dank des Kommentars hier (danke an Blog-Leser Ollert) und dieses administrator.de-Posts hier aufgegriffen. In Kurzfassung:
- In allen Windows-Versionen fixen die Sicherheitsupdates vom 8. Januar 2019 eine Schwachstelle in der in Windows enthaltenen Jet Database Engine.
- In Folge dieses Patches scheitern Zugriffe auf Datenbanken im Access 97 MDB-Format mit einem Datenbankfehler "unknown database format" – sofern die Datenbank Feldnamen mit einer Länge größer 32 Zeichen aufweist.
- Das Problem tritt bei Verwendung der Microsoft.Jet.OLEDB.4.0-Providers auf – die ältere Microsoft.Jet.OLEDB.3.51-Variante scheint zu funktionieren (ist wohl ungepatcht).
Einige Details sowie Workarounds, von der Deinstallation des Updates über Austausch einer DLL bis hin zum Ändern das Data Source-Strings für den beim Datenbankzugriff zu verwendenden Provider lassen sich im Blog-Beitrag Access Datenbankprobleme nach Januar 2019-Updates nachlesen.
Anmerkung: Blieb die Frage, wie man den Sachverhalt Microsoft zur Kenntnis bringt – auch wenn das bei MS-Answers diskutiert wird, schauen Entwickler selten da rein. Ich habe daher ein 'Spiel über Bande' versucht. Dazu haben ich das Problem im englischsprachigen Blog beschrieben, einen Link in diesem US MS Answers-Forenbeitrag gepostet und den Thread an die Microsoft Moderatoren eskaliert. So gab es die Chance, dass die Entwickler den Link auf meinen englischsprachigen Blog-Beitrag zu Gesicht bekommen und etwas damit anfangen können. Scheint funktioniert zu haben, wie man nachfolgend sieht.
Microsoft bestätigt das Problem
Heute Morgen bin ich über einen Post von Susan Bradley bei askwoody.com und in meinen Blog darauf aufmerksam geworden, dass Microsoft seine KB-Artikel überarbeitet hat. Hier die Liste der betroffenen Patches, wo das Access 97-Problem als 'known issue' aufgeführt ist.
- 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
Microsoft hat den 'known issue'-Abschnitt der KB-Artikel um die folgende Passage ergänzt:
Anzeige
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. he database will fail to open with the error, "Unrecognized Database Format".
Also ziemlich genau das, was ich in der Recherche, basierend auf den Hinweisen von Blog-Leser Ollert, bereits im oben verlinkten Artikel dokumentiert hatte. Microsoft verspricht einen Fix bis Februar 2019 und schlägt einige Workarounds vor.
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.
Diese drei genannten Optionen sind meines Erachtens mit äußerster Vorsicht zu genießen bzw. in der Praxis wenig realistisch. Korrigiert mich, wenn meine nachfolgenden Ausführungen unzutreffend sind – ich bin seit mindestens 15 Jahren aus dem Thema Jet Database Engine, ADO, DAO und OLEDB raus.
Vorsicht bezüglich der Microsoft-Vorschläge
Das Szenario, wo es momentan Probleme gibt, dürften compilierte Anwendungen sein, die über Laufzeitbibliotheken auf die Datenbanken im Access 97 MDB-Format zugreifen. Meist sind es auch Anwendungen, die historisch gewachsen sind und irgendwann geplant abzulösen sind. Da der Bug im Januar 2019 auftritt, sind jetzt Ad-Hoc-Lösungen gefordert. Schauen wir uns die Microsoft-Vorschläge mal genauer an.
Option 1: Datenbankfeldnamen kürzen
Der Microsoft-Vorschlag in Option 1, die Namen der Datenbankfelder auf eine Länge von 32-Zeichen zu begrenzen, um den Fehler zu umgehen, ist schlicht nicht praktikabel.
- Ändert man eine Felddefinition (Feldname) in der Datenbank, wird i.d.R. eine Anpassung des Codes der betreffenden Anwendung erforderlich. Abseits von Trivialfällen scheitert dieser Ansatz a) weil die Anwender keinen Zugriff auf den Code haben und b) weil bei nicht trivialen Anwendungen und Datenbanken der Aufwand zur Validierung dieser Anpassung schlicht zu groß wird.
- Wer sagt mir denn, dass dies der einzige Fehler in der Jet Database Engine ist? Die Begrenzung auf Feldnamenlängen von 32 Zeichen 'riecht' für mich danach, dass da bei der Compilierung der betreffenden DLLs eine strenger Typ-Prüfung oder Werteüberprüfung auf Pufferüberlauf erfolgt. Ob das nur bei 'zu langen Datenbankfeldnamen' oder auch an anderen Stellen zu Problemen führt, ließe sich nur per Code-Evaluierung klären. Das ist für Außenstehende nicht möglich – und Microsoft hat da nichts verlauten lassen.
Ein Administrator, dem gerade zig Anwendungen in einer Produktionsumgebung stehen, wird im Übrigen mit solchen theoretischen Konstruktionen wenig anfangen können. Fällt in die gleiche Kategorie wie die schlauen Kommentare zum heise-Artikel a la 'wer noch mit Access 97 arbeitet ist selbst schuld'. Das nutzt dem Admin nichts, der das Zeugs zum Laufen bringen muss und die Anwendung, aus vielfältigen Gründen nicht einfach ablösen kann.
Option 2/3: Datenbank konvertieren
Der zweite und dritte Vorschlag Microsofts lautet, die .mdb-Datenbank in (einer neueren Version von) Microsoft Access zu öffnen und dann konvertieren zu lassen. Anschließend liegt die Datenbank in einem neuen Format (z.B. *.accdb) oder ein einem mdb-Datenbankformat für Access 2002-2003 vor.
Klingt wie der Stein der Weisen – kann klappen, muss aber nicht. Ich erinnere mich an die Zeiten, wo ich noch Einsteigerbücher zu Access geschrieben habe. Selbst meine Trivialbeispiele mussten beim Wechsel auf eine neue Access-Version erinnerungsmäßig schon mal angepasst werden – und wehe, wenn VBA-Makros dabei waren. Mein letzter Microsoft Press 'Auf einen Blick'-Titel endete mit Microsoft Access 2002.
Bei einer nicht trivialen Datenbank und einer nicht trivialen Anwendung müsste die Lösung nach der Konvertierung vor Freigabe in einer Produktionsumgebung validiert werden. Selbst wenn die Software keine Fehler liefert, ist damit nicht gewährleistet, dass die Daten korrekt in die Datenbank mit dem neuen Format abgelegt werden.
Ich verweise hier schlicht auf meinen Kommentar, wo ich die Frage nach der Konvertierung und den möglichen Risiken gestellt hatte. Die Antwort eines Blog-Lesers war eindeutig und für mich nachvollziehbar. Und Detlef Jäger weist in diesem Kommentar sowie in Folgekommentaren auf Probleme im Zusammenhang mit ADO und bestimmen Befehlen (Datenbank komprimieren/reparieren) hin. Felder mit einer Länge größer 32 Zeichen werden bei Anwendung bestimmter ADO-Befehle geleert.
Anmerkung: Weil es gerade hier passt – ich bin in den heise.de-Kommentaren auf diesen Post gestoßen, der von einem neu implementierten Lease-Mechanismus in Windows 10 V1803 für Netzwerkzugriffe und Access-Problemen berichtet.
Damit ist die Information bekannt – ich habe bei MS Answers im eskalierten Forenthread auch die Information zu den ADO-Risiken eingestellt. Jetzt muss jeder Betroffene sehen, welche Workarounds und Fixes umsetzbar sind. An dieser Stelle danke an die Blog-Leser, die Sachdienliches zum Thema beigetragen haben.
Ähnliche Artikel:
Patchday Windows 10-Updates (8. Januar 2019)
Patchday: Updates für Windows 7/8.1/Server 8. Jan. 2019
Access Datenbankprobleme nach Januar 2019-Updates
Anzeige
Ich vermute mal wild in die Gegend: bei Access 97 Datenbanken waren wahrscheinlich gar keine Spaltenüberschriften größer 32 Zeichen vorgesehen. Dass es trotzdem funktionierte, war der Bug. Irgendwann hat man damit über den eigentlich dafür vorgesehenen Puffer hinausgeschrieben, was einen Pufferüberlauf auslöst. Und solche können dann schon ein Sicherheitsproblem sein bzw. das Auffinden eines solchen ermöglichen. Nun hat man bei der Korrektur des damaligen Bugs Nägel mit Köpfen gemacht und zieht das Limit streng durch. Damit fallen all die Datenbanken auf die Nase, bei denen die Entwickler damals bei den Spaltenüberschriften über dem Limit lagen.
Wie gesagt, nur vermutet. Meine Begegnungen mit Access sind noch länger her. Nach Access 2.0 für Windows hatte ich nichts mehr damit zu tun. ;-)
Ingo: Du könntest mit der Vermutung Recht habe – klingt jedenfalls logisch. Doof nur, wenn das nicht dokumentiert wird und plötzlich auftritt. Irgend etwas wird sich die MS-Entwicklung aber überlegen müssen, wenn man einen Fix im Februar 2019 bereitstellen will.
Vielen Dank für die Recherche und den Einsatz!
Vielen Dank für deinen Bericht. Du hast mir sehr dabei geholfen!