[English]Kurze Information für die Leserschaft und gleichzeitig die Frage, ob jemand bereits betroffen ist. Ich habe eine Nutzermeldung erhalten, dass Microsoft Access plötzlich Probleme beim SQL-Datenbankzugriff habe. Alle Datenbanken zeigten in den Tabellen plötzlich den Wert '#DELETED' an. Problem ist der (mit Windows ausgelieferte) Microsoft SQL Server ODBC-Treiber, der wohl nach Office-Updates streikt.
Anzeige
ODBC-Zugriff auf SQL-Server fehlerhaft
Blog-Leser Axel H. hat mit am Samstag, den 28. Mai 2022 per Mail kontaktiert, um eine spezifische Beobachtung im Umfeld von Microsoft Access in Verbindung mit Zugriffen auf einen Microsoft SQL-Server zu berichten. Axel schrieb mir:
anbei eine Notiz von mir. Mich hat heute ein Kollege angerufen, dessen Microsoft Access plötzlich nicht mehr ordentlich mit dem SQL Server arbeiten wollte.
Alle in Microsoft Access eingebundenen ODBC-Tabellen zeigen als Inhalt nur noch '#DELETED' an.
Nach einigem Suchen habe ich herausgefunden, dass es am 'original' Microsoft SQL Server ODBC-Treiber liegt, also dem, der mit Windows ausgeliefert wird.
Hört sich nicht so sonderlich dolle an.
Neue ODBC-Treiberversionen funktionieren
Der Microsoft ODBC Driver for SQL Server ist eine einzelne Dynamic-Link Library (DLL), die Laufzeitunterstützung für Anwendungen bietet, die APIs mit nativem Code verwenden, um eine Verbindung zu SQL Server herzustellen. Microsoft ODBC Driver 18 for SQL Server sollte für die Erstellung neuer Anwendungen oder zur Verbesserung vorhandener Anwendungen eingesetzt werden, die die neueren SQL Server-Features nutzen.
Die aktuelle Version 18.0.1.1 vom 15. Februar 2022 wird für den SQL Server 2022 Preview hier angeboten , auf Github gibt es diese Übersicht dazu. Nach einigem Testen konnte Axel feststellen, dass neuere Versionen des ODBC-Treibers wie z.B. v13 und v17 das Problem beim Zugriff auf die Datenbanken nicht zeigen.
Anzeige
Es könnte knallen, Rollback von Office hilft
Axel schreibt dazu: Die von Windows mitgelieferte Version wird aber im Feld sicherlich zu >90% eingesetzt, da Windows sie ja mitbringt und nicht extra installiert
werden muss. Es könnte die nächsten Tage also heftig rappeln im Gebälk.
Ad Hoc ist mir aber unklar, ob dieser ODBC-Treiber durch Windows oder Office installiert wird (der Artikel hier beschreibt einen mit WIndows 10 mitgelieferten ODBC-Treiber). Axel schreibt, dass im konkreten Fall Microsoft Office Professional Plus 2019 C2R 32-Bit, Version 2205 Build 16.0.15225.20028 vom 2022-05-24, betroffen war. Nachdem er Microsoft Office auf die Version 16.0.15128.20248 vom 2022-05-17 zurückgesetzt hatte, lief sofort wieder alles.
Axel schließt daraus, dass das Problem demnach wohl nicht wirklich am ODBC-Treiber liegt, sondern am Office-Update und wie dieses mit dem ODBC-Treiber 'kooperiert'. Er hat die Office-C2R-Updates daher mittels Registry erst mal deaktiviert, damit nicht wieder sofort die neueste Version drüber gebügelt wird. Noch jemand mit solchen Erfahrungen?
Ergänzung: Beachtet auch den Blog-Beitrag Outlook: Mai 2022-Update Build (15225.20204) beschädigt HTML-Anzeige.
Anzeige
Hi, bei uns hat folgendes geholfen. Wir haben bei uns numerischer Primary Keys auf die Fehlerhaften Tabellen gesetzt.
https://community.spiceworks.com/topic/2157152-troubleshooting-deleted-result-for-a-linked-odbc-table-in-ms-access
Ich habe den Effekt hier auch bei einer Tabelle mit Primärschlüssel nvarchar(5).
Wegen deklarativer referentieller Integrität und Fremdschlüsseln kann ich den aber nicht einfach ändern, will das natürlich auch nicht. Ich werde gleich einfach mal einen neueren ODBC-Treiber installieren.
Hier eine sehr gute Analyse: https://codekabinett.com/rdumps.php?Lang=2&targetDoc=msaccess-bug-v2205-odbc-deleted-nvarchar-primary-key
Download-Link in https://answers.microsoft.com/en-us/msoffice/forum/all/access-linked-table-to-sql-server-shows-data-as/e8652e36-828b-4ece-a21e-3b1225b67c26
–> https://docs.microsoft.com/en-us/sql/connect/odbc/download-odbc-driver-for-sql-server
Funktioniert, auch ohne Neustart. Ich nutze nur eine DSN-Verbindung mit integrierter Windows-Authentifizierung. Daher brauchte ich nur die alte ODBC-Verbindung umzubenennen und eine neue mit ODBC 18 anlegen. Dabei ggf. die Verbindungsverschlüsselung auf "Optional" stellen, wenn man nicht komplett in einem Active Directory (ggf. mit PKI) arbeitet. An der Datenbank oder Anwendung musste ich nichts ändern oder etwas zurückrollen.
Im Bedarfsfall bei vielen Clients kann man die ODBC-Verbindung auch per PowerShell-Befehl Add-OdbcDsn anlegen.
Diese Mai-Update von Office hat auch im Outlook 2019 die Vorschau von HTML Mails beschädigt – die eMail ist in der Anzeige einfach "leer".
Nach einem Roll-Back auf April funktioniert es wieder einwandfrei.
Falls es jemand benötigt:
Administrative Eingabeaufforderung,
im Ordner : C:\Program Files\Common Files\microsoft shared\ClickToRun>
officec2rclient /update user updatetoversion=16.0.15128.20248
Die Version 18 des SQL Treibers forciert die Encyption und verursacht dadurch oft Probleme.
Jein, siehe meinen Beitrag oben von 11:09 Uhr: einfach die standardmäßig erzwungene Verschlüsselung auf optional stellen und gut ist.
Ändern der odbc Verbindung auf Version 17 oder 18 fixt bei uns auch das Problem.
Keine Probleme hier. Office 2019 auf Windows 10.
Ich hatte auf meinem Surface Pro 3 mit Windows 10 und Access 365 ebenfalls keine Probleme – trotz neuestem Patch Level, also identische, 64-Bit Office-Version. Ich vermute, es gibt das Problem nur unter Windows 11. Ein andere Client hier mit Windows 11 hatte ebenfalls wie ich das Problem mit dem standardmäßigen ODBC-Treiber.
In der Firma wird der ODBC-Treiber aus dem Paket SQL Server Native Client 11.0 eingesetzt. Der unterstützt wohl nicht alle neuen Features vom SQL Server.
Wundere mich aber wieso ich auf meinem Entwicklungrechner unter Windows 11 und installiertem SQL Server Developer die ODBC Driver 13 und 17 installiert habe. Ob ich das mal aus Testzwecken war oder es mit dem SQL Server oder dem Management Studio oder Visual Studio 2019 drauf kam?
Auf meinem Arbeits-PC ist stets das neueste Visual Studio 2019 (leider noch 2019 wegen nötigen Oracle Developer Tools, die es immer noch nicht gibt für VS 2022 – siehe und auch SSMS sowie einen lokalen SQL Server 2019 Express. Alles drei haben ganz offensichtlich keinen eigene ODBC-Treiber dabei.
Naja, was soll ich lange überlegen wie da die ODBC Treiber drauf kamen. Muss sie ja nicht nutzen. :-)
Und wenn ich selbst entwickle nutze ich die passende .NET-Klasse um benannte Parameter für Anfragen anstatt Fragezeichen bei ODBC einsetzen zu können.
Bin gerade im Fitness-Studio, kann also nicht nachschauen wie die heißen.
Ich nutze ODBC nur ohne Programmierung (sonst Entity Framework für .NET), aber mit Access-Datenbanken, in die SQL-Server-Objekte eingebunden sind, per ODBC-DNS-Name, um sehr einfach den Server bzw. die Datenbank zentral ändern zu können.
Oder mit Word für Serienbriefe aus Tabellen oder Sichten aus Microsoft-SQL-Server-Datenbanken – auch hier nur über den ODBC-DSN-Namen, damit die Word-/Excel-Dateien auf jedem System völlig problemlos laufen.
Office Version 15225.20204 – Outlook
ALLE E-Mails werden mit Nur-Text-Format angezeigt.
Kunden mit Windows 10 und Windows 11 betroffen.
Rollback auf ältere Version von Office und abschalten der automatischen Updates fürs Office, danach läuft Outlook wieder sauber.
Scheint wirklich MURKS zu sein, das Update
Kann ich hier nicht bestätigen, und bisher hat uns auch kein Kunde kontaktiert, auch nicht wegen ODBC. Outlook 365 64 Bit mit Exchange 365. Über IMAP/POP3 oder SMTP-Anbindungen kann ich nichts sagen.
Allerdings habe ich gerade mal mit Outlook eine übliche HTML-Mail über mein gmx-Testmail-Konto an Exchange und gmx gesendet. Beide im jeweiligen Posteingang sind ganz normal mit kursivem Testwort darin und sehen wie immer aus.
Das Problem betrifft nicht nur ODBC für MSSQL.
Wir konnten das gleiche Verhalten auch bei den ODBC-Treibern für PostgreSQL nachvollziehen (getestet unter 12.x, 13.x). Das Hinzufügen eines numerischen PKey half auch nicht immer. Zusätzlich erwartet Access aktuell scheinbar zusätzlich eine Rowsource-Spalte vom Typ Timestamp (Rowsource ist nicht Standard bei PG). Je nach Zugriff auf die Recordsets ADO/DAO muss unter Umständen auch am VB-Code nachgebessert werden.
Das Problem wurde von Microsoft behoben und seit gestern gibt es dafür Office-Updates. Meine Version (Insider Beta-Channel) wurde bereits bedient, die Versionsnummer, die das Problem behebt, lautet 2206 Build 15330.20004. Seit heute wird der Current Channel ebenfalls bedient. Für die langsamen Kanäle (Semi-Annual Channel / Preview) wurde das Update noch nicht freigeschaltet.
@Peter: Danke für diesen Hinweis.
Scheinbar hat Microsoft das Problem auch in 2205 gefixt. Diesen Aussagen von isladogs folgend liest sich das zumindest so:
> For info, MS have just announced that the #Deleted bug fix is now available to all in the Current Channel, Current Channel (Preview), Beta, and Semi-Annual Channel (Preview).
> It does not require a new build but will require closing and restarting Access to see the change. In other words, the fix was done by rolling back the change that caused the problem
und
> …they should be able to revert to 2205 now if they are in any of the listed channels
Quelle: https://www.access-programmers.co.uk/forums/threads/new-access-sql-backend-bug-deleted-showing-in-tables.323388/page-2
Ich habe es gerade am Rechner des Kollegen nachvollziehen können:
1. Microsoft Office 2019 C2R-Updates im UI (in dem Fall Microsoft Access, 64-Bit) wieder aktivieren.
2. Ebenfalls im UI von Access nach Updates suchen und diese installieren lassen.
3. Access neu gestartet und Version kontrolliert: 2205, Build 15225.20204. Also wieder der eigentlich fehlerhafte Patchlevel.
4. Funktionalität geprüft: Das Problem besteht nicht mehr!
Microsoft ist also tatsächlich in der Lage die Funktionalität/Auswirkung eines Patches online zu kontrollieren/beeinflussen (vermutlich mittels Phonehome beim Start einer Office-Anwendung), ohne dass ein neuer Patch installiert werden muss, und hat dies im vorliegenden Fall auch getan.
Eigentlich eine tolle Sache, nur geht das zu Lasten der Transparenz, da man nun nicht weiß, ob und was Microsoft am Patch deaktiviert hat. Kontrollieren lässt sich das wohl leider auch nicht.
Stelle ich mir für Mitarbeiter des Supports unbefriedigend vor…