Ausgangslage, Anwendungsfälle und Alternativen
Diese Seite erklärt, welches Problem Database Gateway löst, für welche Anwendungsfälle es gebaut ist und welche anderen Wege geprüft und warum sie nicht gewählt wurden. Sie richtet sich an alle, die über den Einsatz entscheiden oder ihn begründen müssen.
Zusammenfassung
Fachdaten liegen in SQL-Server-Datenbanken; die Anwender arbeiten mit Access, Excel und Power BI, dazu kommen eigene Programme. Die Arbeitsplätze sollen die Datenbank nicht direkt erreichen – auch nicht im Homeoffice, unterwegs oder beim Kunden. Gebraucht wird deshalb ein Zugang über HTTP, der Anmeldung und Rechte zentral prüft und den die Office-Programme so nutzen können, wie sie heute eine Datenbank nutzen: in Access mit verknüpften Tabellen, die sich in Datenblatt und Formular bearbeiten lassen; in Excel und Power BI mit Abfragen, deren Filter auf dem Server laufen.
Die eingebaute Verknüpfung von Access mit Datendiensten („Datendienste“) erfüllt das nicht: Sie beruht auf einer XML-Verbindungsdefinition der Business Connectivity Services, nicht auf OData, und die verknüpfte Tabelle ist schreibgeschützt (Microsoft: Link to a Data Service). Zum Bearbeiten im Datenblatt braucht Access einen ODBC-Treiber, der die Parameter von Access als Werte bindet und Filter an den Server weitergibt. Database Gateway besteht deshalb aus einem Datendienst, der OData v4 und einen eigenen HTTP-Vertrag anbietet, und einem eigenen ODBC-Treiber, der Access über diesen Dienst schreiben lässt.
Ausgangslage
Warum kein direkter Datenbankzugang. Eine direkte Verbindung von Access oder Excel zu SQL Server setzt voraus, dass jeder Arbeitsplatz den Datenbankserver im Netz erreicht (Standardport 1433) und dass jede Person oder jede Anwendung eine Anmeldung in SQL Server hat. Daraus folgen drei Probleme:
| Problem | Folge |
|---|---|
| Außerhalb des Firmennetzes ist der Datenbankserver nur über ein VPN oder einen offenen Port erreichbar | Ein offener Datenbankport im Internet ist ein bekanntes Angriffsziel; ein VPN muss auf jedem Gerät eingerichtet, betrieben und von jedem Anwender bedient werden |
| Die Anmeldedaten liegen in den Anwendungen | Access speichert die Verbindung einer verknüpften Tabelle in der Datenbankdatei; jede Kopie der Datei trägt sie mit sich |
| Rechte und Protokoll entstehen an vielen Stellen | Was eine Anwendung darf, entscheiden die Berechtigungen der Anmeldung in SQL Server und der Code jeder Anwendung; eine zentrale Sperre, ein zweiter Faktor oder eine Abstufung nach Ort gibt es so nicht |
Was der Betrieb verlangt. Im vorgesehenen Betrieb ist der Datendienst der einzige Weg zur Datenbank: Die Arbeitsplätze erreichen SQL Server nicht. Jeder Zugriff einer Anwendung – auch eine Abfrage, die SQL unverändert an die Datenbank reicht (Pass-Through), oder ein Zugriff aus VBA über ADO – muss deshalb über den Dienst gehen.
Anwendungsfälle
| Anwendungsfall | Wer | Weg |
|---|---|---|
| Tabellen einer bestehenden Access-Anwendung verknüpfen, lesen, filtern, in Datenblatt und Formular bearbeiten, mit Schreibkonflikt bei gleichzeitiger Änderung | Sachbearbeitung | Access über den OData-ODBC-Treiber |
| Pass-Through-Abfragen und ADO-Zugriffe derselben Access-Anwendungen | Sachbearbeitung | derselbe Treiber, Durchreiche des Dienstes |
| Auswertungen und Berichte | Controlling, Leitung | Excel und Power BI über Power Query (OData-Feed), ohne Treiber |
| Arbeiten im Büro, im Homeoffice ohne VPN, beim Kunden, unterwegs | dieselben Personen | dieselben Programme; im Firmennetz einfache Anmeldung, außerhalb mit zweitem Faktor; beim Kunden ein befristeter, nur lesender Schlüssel |
| Die Datenbank soll wissen, wer gehandelt hat („angelegt von“, Trigger, Sichten je Person) | Fachanwendung | Weitergabe der Person an SQL Server |
| Eigene Programme greifen auf Daten zu | Entwicklung | HTTP mit JSON oder XML; .NET-Client, VBA-Klasse |
| Personen, Schlüssel, zweite Faktoren und Rechte verwalten | Administration | Verwaltungsanwendung für Access über die Verwaltungsschnittstelle |
Geprüfte Alternativen
| Alternative | Ergebnis |
|---|---|
| Direkter Zugang zu SQL Server, im Firmennetz und über VPN | erfüllt die Anwendungsfälle im Büro vollständig; widerspricht aber dem Betrieb ohne direkten Datenbankzugang und lässt die Probleme der Ausgangslage bestehen |
| Eingebaute Verknüpfung von Access mit Datendiensten („Datendienste“) | beruht auf Business Connectivity Services, nicht auf OData; die verknüpfte Tabelle ist schreibgeschützt (Microsoft: Link to a Data Service) |
| Power Query allein | genügt für Excel und Power BI zum Lesen; Schreiben ist nicht vorgesehen |
| Eine Programmschnittstelle mit eigenen Funktionen oder Prozeduren je Tabelle | jede neue Tabelle und jede Änderung am Schema verlangt eine Änderung der Schnittstelle; Office-Programme können eine solche Schnittstelle nicht als Tabelle verknüpfen. Gewählt wurde stattdessen ein Dienst, der aus der Anfrage (Methode, Tabelle, Schlüssel, Felder) die Anweisung erzeugt und die Tabellen aus dem Katalog der Datenbank liest |
Wirtschaftliche Sicht
- Lizenzkosten je Arbeitsplatz entfallen. Datendienst, Treiber und Client tragen keine Lizenz je Arbeitsplatz.
- Bestehende Access-Anwendungen bleiben. Sie werden nicht neu geschrieben; umgestellt werden die Verbindungen ihrer Tabellen und Abfragen, Formulare und Berichte bleiben, wie sie sind. Setzt eine Anwendung ihre Verbindungen im Startcode selbst zusammen, braucht dieser Code eine kleine Anpassung.
- Laufende Kosten entstehen für Betrieb und Pflege von Datendienst und Treiber.
Grenzen dieser Lösung
- Nur SQL Server als Datenbank. Der Dienst bindet Datenbanken über nachladbare Provider an (siehe Konfiguration des Dienstes (Referenz)); mitgeliefert ist der Provider für SQL Server.
- Der OData-ODBC-Treiber bietet nicht jede Fähigkeit des ODBC-Treibers von SQL Server. Welche fehlen, nennt die Dokumentation des Treibers („Grenzen und bekannte Einschränkungen (Referenz)“).
- Eine Instanz je Verwaltungsspeicher; eine Ausfallsicherheit über zwei Instanzen gibt es nicht (siehe Verwaltungsspeicher und Hauptschlüssel).
- Neue Abhängigkeit: Fällt der Dienst aus, erreicht kein Arbeitsplatz die Daten. Bei direktem Zugang hängt die Erreichbarkeit allein am Datenbankserver.