OData-ODBC-Treiber
Access über OData an SQL Server – ohne Datenbankkennwort am Arbeitsplatz
Mit dem Treiber spricht Ihre Access-Anwendung statt mit der Datenbank mit einem Datendienst: kein Datenbankkennwort am Arbeitsplatz, Anmeldung und Rechte an einer Stelle. Verknüpfte Tabellen, Formulare und Berichte bleiben.
Ausgangslage
Access ist nicht das Problem, jedenfalls nicht immer. Stehen heute Datenbankkennwörter in den Verknüpfungen, und erreicht jeder Arbeitsplatz die Datenbank direkt, fällt das bei der nächsten Sicherheitsprüfung auf. Ein Grund, eine bewährte Anwendung zu ersetzen, ist das nicht: Die Modernisierung beginnt dort, wo sie nötig ist, und nicht zwangsläufig mit einem Neubau.
Die Lösung
Der Treiber setzt zwischen Access und die Datenbank einen Datendienst. Tabellen werden verknüpft, nicht neu programmiert: Der Treiber liest Tabellen, Spalten, Typen und Schlüssel aus dem Dienst. Er arbeitet mit dem Datendienst Data Gateway ebenso wie mit anderen OData-v4-Diensten.
So stellen Sie um:
- Den Treiber installieren – ein Paket für 32 und 64 Bit, in der Bitbreite von Office.
- Die Datenquelle auf den Datendienst richten.
- Die Tabellen in Access neu verknüpfen; Formulare, Berichte und Abfragen arbeiten weiter.
- Anwender: Datenblatt und Formular wie gewohnt. Angemeldet wird mit dem Windows-Konto oder einem persönlichen Schlüssel, nicht mit einem Datenbankkennwort.
- IT-Leitung: Am Arbeitsplatz liegt kein Datenbankkennwort mehr. Wer welche Tabelle lesen oder ändern darf, prüft der Dienst, an einer Stelle.
- Access-Entwicklung: Datenblätter, Formulare und Abfragen auf eine einzelne Tabelle arbeiten weiter; neu sind die Verbindungszeichenfolgen.
- Betrieb: Ein Installationspaket für 32 und 64 Bit; die Arbeitsplätze brauchen keinen Zugang zur Datenbank mehr.
- Über Access hinaus: Über den Datendienst Data Gateway erreichen auch Excel, Power BI und eigene Programme dieselben Tabellen, mit denselben Rechten.
Eine Datenquelle einrichten, dann verknüpfen wie immer
Statt Server und Datenbankkennwort tragen Sie die Adresse des Dienstes ein. Danach verknüpft Access die Tabellen über den Dialog, den Ihre Anwender schon kennen.
Der Weg einer Abfrage
Access fragt wie bisher über ODBC. Der Treiber übersetzt in OData und spricht über HTTPS mit dem Dienst; nur der Dienst erreicht die Datenbank.
Funktionen
- Tabellen in Access verknüpfen und im Datenblatt bearbeiten, mit dem gewohnten Schreibkonflikt
- Anmeldung mit dem Windows-Konto oder einem persönlichen Schlüssel, mit zweitem Faktor, wo der Dienst ihn verlangt
- Abfragen über mehrere Tabellen, vom Dienst nach Ihren Regeln geprüft und ausgeführt
BeginTrans,CommitTransundRollback, wo der Dienst Transaktionen anbietet- Ein Installationspaket für 32 und 64 Bit, in der Bitbreite von Office
- ADO.NET mit System.Data.Odbc, Server-Explorer und TableAdapter-Assistent in Visual Studio
Persönlicher Schlüssel statt Datenbankkennwort
Verlangt der Dienst eine Anmeldung, fragt der Treiber nach dem persönlichen Schlüssel. Windows kann ihn in der Anmeldeinformationsverwaltung aufbewahren.
Zweiter Faktor, wenn der Dienst ihn verlangt
Fordert der Dienst einen zweiten Faktor, gibt der Anwender den sechsstelligen Code aus seiner Authenticator-App ein.
Abfragen, die der Treiber nicht übersetzt
Joins und Unterabfragen laufen als Pass-Through-Abfrage, wenn der Dienst eigene Anweisungen annimmt – beim Data Gateway als geprüfte Anweisungen mit Rechten je Objekt.
Weitere Ansichten
Die verknüpfte Tabelle dbo_Artikel im Datenblatt – die Daten kommen aus dem Dienst. 
Entwurf der Pass-Through-Abfrage mit ihren Eigenschaften. 
Ergebnis der Pass-Through-Abfrage: Umsatz je Kunde. 
Tabellen verknüpfen: die Tabellen, die der Dienst anbietet.
Technische Daten
- Voraussetzungen: Windows 10 (ab Version 1607) und 11 oder Windows Server 2016 und neuer; Access 2010 oder neuer bzw. die Access Runtime, 32 oder 64 Bit. Freigegeben für den Datendienst Data Gateway auf SQL Server 2016 oder neuer; andere OData-v4-Dienste nach den Anforderungen an einen OData-Dienst. Dazu ein Zertifikat, dem die Arbeitsplätze vertrauen. Technische Daten und Voraussetzungen
Häufige Fragen
Was ändert sich an unserer Access-Anwendung?
Die Verbindungszeichenfolgen. Verknüpfte Tabellen, Formulare und Berichte bleiben. Wo Code Zeile für Zeile abruft oder Pass-Through-Abfragen nutzt, zeigt die Prüfung in drei Stufen vorab, was gezielt anzupassen ist.
Mit welchen Diensten arbeitet der Treiber?
Mit Data Gateway, für den er freigegeben ist, und mit anderen OData-v4-Diensten. Was ohne Durchreiche, Gruppieren und Transaktionen geht, legt der Dienst fest; prüfen Sie ihn vorab an den Anforderungen an einen OData-Dienst.
Was merken die Anwender?
Datenblatt und Formular arbeiten wie gewohnt; ein Schreibkonflikt erscheint, wie Access ihn immer gezeigt hat. Angemeldet wird mit dem Windows-Konto oder einem persönlichen Schlüssel, mit zweitem Faktor, wo der Dienst ihn verlangt.
Wir nutzen heute ODBC Driver 18 direkt auf SQL Server. Wie steigen wir um?
Datenblätter, Formulare und Abfragen auf eine Tabelle arbeiten weiter. Für Prozeduraufrufe, Parameter, Ergebnismengen und Datentypen nennt die Referenz jede Abweichung von ODBC Driver 18 mit ihrem Weg.
Einrichtung, Beispiele und Referenz, Schritt für Schritt: Alles steht in der Dokumentation.
Dokumentation öffnen