OData-ODBC-Treiber · für bestehende Access-Anwendungen
Bestehende Access-Anwendungen an einen Datendienst anbinden – ohne Neubau
Eine bewährte Anwendung, ein neuer Weg zu ihren Daten. Verknüpfte Tabellen, Formulare und Berichte bleiben.
Mit dem Treiber spricht Access statt mit der Datenbank mit einem Datendienst. Die Tabellen bleiben verknüpft, Datenblatt und Formular arbeiten wie gewohnt – geändert wird die Verbindungszeichenfolge.
- Access-Anwendung, unverändert
- OData-ODBC-Treiber
- Datendienst: Anmeldung, Rechte
Access verknüpft die Tabellen über den Treiber. Die Datenbank erreicht nur der Datendienst.
Ausgangslage
Access ist nicht das Problem, jedenfalls nicht immer. Oft ist es der Weg zu den Daten.
Eine gewachsene Access-Anwendung verknüpft ihre Tabellen meist direkt mit SQL Server. Bei der nächsten Sicherheitsprüfung oder dem ersten Wunsch, von außerhalb des Büros zu arbeiten, fällt dieser Weg auf:
- Das Kennwort steht in der Verknüpfung. Wurde beim Verknüpfen „Kennwort speichern“ gewählt, legt Access das Kennwort laut Microsoft unverschlüsselt in der Datei ab – und jede Kopie trägt es mit sich.
- Jeder Arbeitsplatz erreicht die Datenbank. Von außen geht das nur über VPN oder einen offenen Datenbankport.
- Rechte stecken in SQL-Anmeldungen und im Code. Eine zentrale Sperre, einen zweiten Faktor oder Regeln danach, woher jemand zugreift, gibt es so nicht.
VPN, Neubau oder Treiber?
Drei Wege – und was jeder kostet
- Direkt bleiben, von außen über VPN. Für die Arbeit im Büro reicht das vollständig. Kennwörter in den Dateien, Zugang jedes Arbeitsplatzes zur Datenbank und verstreute Rechte bleiben aber, und das VPN muss auf jedem Gerät laufen.
- Die Anwendung neu bauen. Richtig, wenn die Anwendung selbst das Geschäft begrenzt. Wenn nur ihr Weg zu den Daten nicht mehr genügt, ersetzt ein Neubau auch alles, was funktioniert: Formulare, Berichte, eingespielte Abläufe.
- Die Access-Verknüpfung mit „Datendiensten“. Sie beruht auf den Business Connectivity Services, nicht auf OData, und die verknüpfte Tabelle ist schreibgeschützt.
Der Treiber nimmt den dritten Weg ernst und macht ihn beschreibbar: Er liest Tabellen, Spalten, Typen und Schlüssel aus dem Dienst, und Access bearbeitet die Daten in Datenblatt und Formular. Umgestellt werden die Verbindungen; setzt eine Anwendung ihre Verbindungen im Startcode selbst zusammen, braucht dieser Code eine kleine Anpassung. Ausgangslage und Alternativen im Einzelnen
Mit dem Treiber
Was sich auf dem Weg zu den Daten ändert
Heute
Access-Anwendung
- verknüpfte Tabellen
- Formulare
- Berichte
die Verbindung mit Kennwort in der Datei
ODBC-Treiber von SQL Server · Datenbankport · von außen VPN
SQL Server
- eine Anmeldung je Person oder Anwendung
Mit dem Treiber
Access-Anwendung
- verknüpfte Tabellen
- Formulare
- Berichte
eine neue Verbindungszeichenfolge, kein Datenbankkennwort
OData-ODBC-Treiber · HTTPS · Windows-Konto oder persönlicher Schlüssel
Datendienst
- Anmeldung, zweiter Faktor
- Rechte je Tabelle
- Protokoll
Nur der Datendienst erreicht die Datenbank
SQL Server
Was die Anwender bemerken: Sie melden sich mit dem Windows-Konto oder einem persönlichen Schlüssel an, mit zweitem Faktor, wo der Dienst ihn verlangt – nicht mit einem Datenbankkennwort.
Dieser Weg reicht über Access hinaus. Über den Database Gateway erreichen auch Excel, Power BI und eigene Programme dieselben Tabellen, mit denselben Rechten und demselben Protokoll. Ein späterer Schritt, etwa ein Teil der Anwendung als .NET-Programm mit dem .NET-Client, kann auf demselben Dienst aufsetzen.
Was sich für wen ändert
| Wer | Was bleibt und was besser wird | Was es kostet |
|---|---|---|
| Anwender | Datenblatt und Formular wie gewohnt; ein Schreibkonflikt erscheint, wie Access ihn immer gezeigt hat. | Wo der Dienst es verlangt, ein zweiter Faktor bei der Anmeldung. |
| IT-Leitung | Am Arbeitsplatz liegt kein Datenbankkennwort mehr. Wer welche Tabelle lesen oder ändern darf, prüft der Dienst, an einer Stelle. | Ein Datendienst mehr im Betrieb, dazu ein Zertifikat, dem die Arbeitsplätze vertrauen. |
| Access-Entwicklung | Tabellen werden verknüpft, nicht neu programmiert. Datenblätter, Formulare und Abfragen auf eine einzelne Tabelle arbeiten weiter. | Neue Verbindungszeichenfolgen. Abfragen über mehrere Tabellen prüft und führt der Datendienst aus; nur ungeprüfte Pass-Through-Abfragen brauchen eine Freischaltung. Schleifen, die Zeile für Zeile abrufen, werden langsamer. |
| Betrieb | Ein Installationspaket für 32 und 64 Bit; die Arbeitsplätze brauchen keinen Zugang zur Datenbank mehr. | Den Treiber in der Bitbreite von Office verteilen und bei jeder neuen Fassung aktualisieren. |
Eignung
Passt Ihre Anwendung?
Eine erste Einschätzung in drei Stufen, aus den dokumentierten Grenzen des Treibers. Sie ersetzt keinen Test mit Ihrer Anwendung, zeigt aber, wo Arbeit entsteht.
Greift Ihre Anwendung heute mit dem ODBC Driver 18 direkt auf SQL Server zu, vergleichen Sie zusätzlich die Abweichungen von ODBC Driver 18, Punkt für Punkt: Prozeduraufrufe, Parameter, Ergebnismengen und Datentypen.
Läuft, wie es ist
- Verknüpfte Tabellen in Datenblatt und Formular lesen, filtern, anlegen, ändern und löschen – mit dem gewohnten Schreibkonflikt, wenn zwei denselben Satz ändern.
- Abfragen, die eine einzelne Tabelle lesen; der Filter läuft beim Dienst, der Treiber lädt nie stillschweigend die ganze Menge.
- Abfragen über mehrere Tabellen – Verbünde und Unterabfragen reicht der Treiber an den Dienst weiter. Der Datendienst des Database Gateway prüft sie gegen die Regeln des Anwenders und führt sie aus, ohne eigene Freischaltung; ein anderer Dienst braucht dafür eine Adresse für eigene Anweisungen.
BeginTrans,CommitTransundRollback– wo der Dienst Transaktionen anbietet; der Datendienst des Database Gateway tut das.
Braucht gezielte Nacharbeit
- Pass-Through-Abfragen, die das Schema ändern, temporäre Tabellen anlegen oder mehrere Anweisungen enthalten, laufen ungeprüft – das schaltet der Betrieb des Dienstes eigens frei, je Datenquelle und Aufrufer (eigene Anweisungen freischalten). Was der Treiber selbst übersetzt: Unterstütztes SQL.
- Ändern und Löschen brauchen eine Zeilenversion, die der Dienst deklariert; Tabellen ohne Schlüssel bleiben schreibgeschützt, sofern der Dienst nichts anderes anbietet. Die Abhilfe liegt beim Dienst, nicht in Access.
- Code, der Zeile für Zeile abruft, wird langsamer als über eine direkte Verbindung – große Mengen lesen.
- Mehrere Datenbanken, Schemata oder Identitäten in einer Datei brauchen je einen eigenen
DATABASE-Wert. Sonst bedient Access sie still über dieselbe Verbindung – vor dem Verknüpfen lesen. LIKEnur in den Formenx%,%xund%x%, ohne_als Platzhalter.
Geht nicht über den Treiber
- Ausgabe- und Rückgabeparameter von Prozeduren und mehrere Ergebnismengen.
- Dienste mit OData v2 oder v3 oder ohne
$metadata. - Teile des OData-Modells ohne relationale Entsprechung: komplexe Werte, Sammlungen, Beziehungen, Singletons und Funktionen.
Wo der Treiber freigegeben ist
- Umgebung: Windows 10 (ab Version 1607) und 11, Windows Server 2016 oder neuer; Access 2010 oder neuer bzw. die Access-Runtime, 32 oder 64 Bit, mit dem Treiber in der Bitbreite von Office.
- Programmierschnittstellen: DAO sowie ADO.NET unter .NET 10, .NET 8 und .NET Framework 4.8; Visual Studio mit Server-Explorer und TableAdapter-Assistent.
- Dienst: freigegeben mit dem Datendienst des Database Gateway auf SQL Server 2016 oder neuer; ein anderer OData-v4-Dienst muss die Anforderungen an einen OData-Dienst erfüllen. Was ohne Durchreiche, Gruppieren und Transaktionen geht, legt dabei der Dienst fest.
Voraussetzungen und freigegebene Umgebungen · Änderungen je Fassung
Was Ihre IT-Sicherheit wissen will
Wer den Umzug freigeben muss, fragt drei Dinge: was der Treiber leistet, was beim Dienst und im Betrieb bleibt und was der Treiber nicht übernimmt.
- Der Treiber leistet: kein Datenbankkennwort am Arbeitsplatz und kein Zugang der Arbeitsplätze zur Datenbank. Angemeldet wird mit dem Windows-Konto oder einem persönlichen Schlüssel, mit zweitem Faktor, wo der Dienst ihn verlangt. Kennwörter und persönliche Schlüssel gehen nur über HTTPS oder an einen Dienst auf demselben Rechner, und das Zertifikat des Dienstes wird gegen den Windows-Vertrauensspeicher geprüft.
- Beim Dienst und im Betrieb bleibt: wer welche Tabelle lesen oder ändern darf, entscheidet allein der Dienst. Vom Arbeitsplatz erreichen ihn die Anmeldung, nach dem zweiten Faktor eine Sitzung für alle Verbindungen des Programms und, wo gewählt, die Datenbank-Identität – über das Gerät selbst nichts. Ob ein privates Gerät oder ein Zugriff aus dem Ausland zugelassen wird, stellt der Betrieb deshalb am Dienst ein, nach Anmeldeverfahren, Herkunft und Land. Außerdem stellt der Betrieb das Zertifikat bereit, dem die Arbeitsplätze vertrauen, und verteilt den Treiber in der Bitbreite von Office.
- Der Treiber übernimmt nicht: er ist kein Sicherheitsfilter. Ein Programm, das den Dienst ohne ihn anspricht, hat dieselben Rechte. Bei einem anderen OData-Dienst gilt dessen Sicherheit; die prüfen Sie dort.
Das Sicherheitsmodell des Treibers, mit jeder Grenze · das des Datendienstes · Zero Trust und private Geräte
Hier beginnen
- Eine Tabelle in Access verknüpfenDer erste Schritt, mit Bildern jedes Schritts: Datenquelle einrichten, Tabelle verknüpfen, im Datenblatt bearbeiten.
- Den Treiber an die Arbeitsplätze verteilenEin Paket für 32 und 64 Bit, in der Bitbreite von Office, mit dem Zertifikat des Dienstes.
- Mit persönlichem Schlüssel anmeldenOhne Domäne und ohne SQL-Kennwort; mit zweitem Faktor, wo der Dienst ihn verlangt.
- Abfragen über mehrere TabellenVerbünde und Unterabfragen führt der Dienst aus, geprüft nach Ihren Regeln.
- Große Mengen schnell lesenWarum Schleifen Zeile für Zeile langsamer werden und was stattdessen hilft.
- Aus .NET und Visual Studio zugreifenADO.NET mit System.Data.Odbc, Server-Explorer und TableAdapter-Assistent.
Sie wollen wissen, was zum Treiber gehört und was Arbeitsplätze und Dienst dafür mitbringen müssen? Funktionen, Voraussetzungen und Grenzen stehen auf der Produktseite.
Zur Produktseite