ACCESS Benutzeroberfläche und SQL-Implementierung; ausführlichere Antwort.

[Auge]

Hallo

Und zwar habe ich eine ACCESS Datenbank. Dadurch das aber schon so viele Daten in der DB vorhanden sind, wird die Benutzeroberfläche immer und immer langsamer.

Du hast an dieser Stelle möglicherweise mehrere Aspekte.

1. Die Menge der in der Datenbank gespeicherten Daten wird größer und größer.
2. Der Aufbau der Formulare ist über Jahre oder gar Jahrzehnte gewachsen und (dann typischerweise) für größere Datenmengen ungünstig.

beides kann zu mangelnder Performance führen. Das auch gerne in Kombination und unter Hinzuziehung weiterer Störquellen, wie z.B. der Lagerung der Daten im Netzwerk bei schlechter Anbindung oder bei zu vielen™ Clients, die auf die Daten zugreifen.

Ist es möglich, von der ACCESS Datenbank einen SQL-Dump zu machen, diesen dann in einen SQL-Server zu importieren, und dann weiterhin die ACCESS Benutzeroberfläche zu verwenden, aber auf einem SQL Server?

Du kannst die Tabellen analog zu den lokalen Tabellen auf dem Server anlegen, in Access (z.B. über ODBC) verknüpfen und die Daten dann mittels SQL-Queries von den lokalen Tabellen auf die Servertabellen übertragen. Einen SQL-Dump brauchst du dazu normalerweise nicht. Damit bist du diese Beschränkung los. Davon wird die Datenbankoberfläche aber nicht einfach so schneller.

Das Frontend (Formulare, Abfragen, VB-Code) solltest du von vorne bis hinten prüfen.

Erfrage beim SQL-Server nur die gerade benötigten Daten.

Oft wird in Access-Projekten eine ganze Tabelle in ein Formular geladen und jeweils ein Datensatz dargestellt. Mit den Access-eigenen Schaltflächen wird zwischen den Datensätzen navigiert. Großes Kino sind dann auch Unterformulare für vom Hauptdatensatz abhängige weitere Datensätze in 1-n-Beziehungen. Dort wird dann auch gern die ganze Tabelle der abhängigen Datensätze geladen, obwohl zum Hauptdatensatz nur ein paar abhängige Datensätze existieren.

Frage explizit nur die benötigten Datensätze ab. Tue dies auch bei Unterformularen. Zudem meiner Erfahrung nach günstig: Setze die Datenquellen für Formulare und Unterformulare über den VB-Code des Moduls des Hauptformulars beim öffnen des Formulars und bei Bedarf bei weiteren Events.

Lagere Datenbankoperationen so weit wie möglich auf den Server aus.

Der SQL-Server ist dafür da und darauf optimiert, die dort gespeicherten Daten zu prozessieren. Server bieten neb en der reinen Datenhaltung in Tabellen z.B. Views, Prozeduren, Trigger.

• Mit Views sind die Ergebnisse von Abfragen, gern auch mit Joins, in tabellenähnlicher Form ständig verfügbar. Du kannst sie in Access wie Tabellen einbinden.
• Mit Prozeduren, die du auch aus Access heraus aufrufen kannst, kannst du Daten vom Server abfragen (statt die SQL-Abfrage z.B. im VB-Code zusammenzustückeln), Daten schreiben und verändern.
• Mit Triggern kannst du auf Serverseite augenblicklich auf Änderungen an Tabellen reagieren. Wenn z.B. ein Datensatz verändert wurde (per UPDATE), kannst du im Trigger veranlassen, dass dem Datensatz einem Datensatz in einer anderen Tabelle eine weitere Info hinzugefügt wird.

Du bekommst also die Möglichkeit, den Server mit Aufgaben zu betrauen, die du bisher im Access-Client erledigen musstest. Alles, was der nun nicht mehr selbst machen muss, sondern eventuell nur noch anzustoßen braucht, macht ihn tatsächlich schneller.

Du wirst dazu eventuell Bedienkonzepte deiner Programmoberfläche und den enthaltenen Code infrage stellen müssen. Sei darauf gefasst, dass die Umstellung der reinen Datenhaltung auf einen SQL-Server zwar fix erledigt ist, die Bearbeitung des Frontends aber eine langwierige Aufgabe ist.

Tschö, Auge