AEK 17: Logik auf SQL-Server (Bernd Jungbluth)

Die Migration von Access-Datenbanken auf den SQL-Server umfasst nicht nur die Daten. Auch die Logik (z.B. VBA, Abfragen, Beziehungen, Makros) ist von entscheidender Bedeutung für die Applikation. Der Migrations-Assistent kann uns dabei helfen, aber er wird nicht alles zuwege bringen. Er migriert nämlich nur Auswahlabfragen, nicht jedoch Aktionsabfragen, und Makros und Module schon gar nicht. Auch die Daten werden verändert: Leere Ja/Nein-Felder werden auf den Standardwert „Nein“ gesetzt, anstatt das NULL beizubehalten. Bernd Jungbluth gibt Hinweise auf Fallstricke und sinnvolle Migrationsstrategien.

Der Zugriff auf den SQL-Server wird über ODBC hergestellt. Der erforderliche Treiber muss natürlich auf allen PCs installiert sein (oder werden), auf der das neue Nur-Noch-Access-Frontend laufen soll (ggf. über das Setup durchführen). Dabei spielt die Version eine entscheidende Rolle, je nachdem welchen SQL-Server man ansprechen will.

Für den Zugriff brauchen alle Tabellen einen Primärschlüssel, da sie sonst nicht geändert werden können. Einen wichtigen Unterschied gibt es dabei für die neue Programmlogik: Der Autowert wird bei Access zu Beginn der Datensatzbearbeitung gesetzt, beim SQL-Server aber erst beim Speichern selbst.

Interessant ist die Datenaktualisierung, deren Rate Microsoft seit Access 2007  auf 1500 Sekunden (= 25 Minuten) gesetzt hat. Reduziert man diesen Wert, hat man zwar schneller aktuelle Daten, es entstehen aber auch häufigere Datenzugriffe über das Netzwerk. Bernd zeigte sehr anschaulich anhand der Extended Events (Nachfolger des „Profilers“), was im Hintergrund bei gebundenen Formularen so alles passiert.

Beachtung sollte man auch den SQL-Abfragen selbst schenken, denn Access und der SQL-Server sprechen unterschiedliche SQL-Dialekte. Diese harmonieren, obwohl beide von Microsoft sind, nicht so gut miteinander, wie man denken würde. Daher ist die Migration keineswegs trivial. Es ist noch eine Menge Handarbeit nach dem Lauf des Migrationsassistenten notwendig.

Anders sieht es aus, wenn die Logik in Form von Stored Procedures auf dem SQL-Server abgebildet wird. Da diese compiliert werden (was bei ad-hoc-SQL-Abfragen jedesmal erfolgen muss), laufen sie schon a priori schneller. Der Ausführungsplan auf dem SQL-Server sorgt außerdem dafür, dass jede Prozedur sehr effizient abgearbeitet wird. Dass dieser dabei ebenfalls wiederverwendet wird, konnten wir am Bildschirm beobachten.

Stored Procedures werden dabei nicht nur als Ersatz für „normale“ Access-Abfragen verstanden, sondern sie erhalten einen spezifischen Auftrag, z.B. die Speicherung von Rechnungsposten einschließlich der Prüfung, ob alle Artikel verfügbar sind. Sicherheitstechnisch betrachtet braucht der Benutzer dann nur noch das Recht, die Prozeduren auszuführen. Lese- oder Schreibrechte auf den Tabellen sind nicht erforderlich. In Access wird diese Stored Procedure dann nicht als Tabelle eingebunden, sondern von einer Pass-Through-Abfrage aufgerufen („EXEC Prozedurname;“). Notwendige Parameter müssen durch etwas VBA in den Codes der PT-Abfrage eingebaut werden, bevor diese ausgeführt wird. Die Verwendung von temporären PT-Abfragen (CurrendDB.CreateQueryDef(„“)) ist hierbei sinnvoller, weil sich dadurch die Anzahl der gespeicherten Datenbankobjekte reduziert. Die Tatsache, dass hierbei der lokale Ausführungsplan (ja, auch Access arbeitet mit so etwas) jedes mal neu compiliert werden muss, ist irrelevant, denn das geschieht bei einer gespeicherten Abfrage, die geändert wird, ebenso.

Auch Änderungen an der Logik sind erheblich einfacher als wenn sie im Frontend erfolgen müssen. Soll z.B. eine Protokollierung eingebaut werden, sobald ein Artikel unter Einkaufspreis verkauft wird, so ist das in der entsprechenden SP schnell gemacht. Dazu muss kein Frontend geändert und neu installiert werden.

Im Ergebnis erhalten wir eine Client/Server-Struktur, bei der jeder das macht, das er am besten kann: Access als Frontend, SQL-Server als Backend. Das gibt es aber nicht mit einem Mausklick, es erfordert eine Menge Gehirnschmalz und Handarbeit. Aber es ist den Aufwand wert, denn das System läuft performant, stabil und hinreichend sicher.


SmallInvoice Logo

Ähnliche Artikel:

AuthorChristoph Jüngling

Selbständiger Softwareentwickler und Seminarleiter

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

neunzehn − 4 =