Ein Kunde hatte die Anforderung, dass das Backend grundsätzlich auf dem Server liegen sollte und der Benutzer vom Frontend auf seinem Rechner per Netzwerk vom Homeoffice darauf zugreift. Wegen instabiler Internetverbindung soll das Backend aber während der Bearbeitung besser auf den lokalen Rechner kopiert werden und nach dem Schließen der Anwendung wieder zurück auf den Server. Wie man dies realisieren kann und was dabei zu beachten ist, zeigen wir in diesem Beitrag.
Voraussetzung
Wir gehen an dieser Stelle davon aus, dass das Verzeichnis, in dem sich das Backend auf dem Server befindet, als Netzlaufwerk in den lokalen Rechner eingebunden ist, sodass das Backend mit den üblichen VBA-Methoden zum Kopieren von Dateien auf den lokalen Rechner und zurück zum Server kopiert werden kann.
Planung
Naiv betrachtet könnte man die Aufgabe herunterbrechen in folgende Schritte:
- Beim Öffnen der Anwendung wird das Backend auf den lokalen Rechner kopiert und die Tabellen werden in das Frontend eingebunden.
- Bei Schließen der Anwendung wird das Backend zurück auf den Server kopiert.
Das setzt jedoch voraus, dass das Fronted immer ordnungsgemäß geschlossen wird und niemals abstürzt. Wenn das Frontend einmal abstürzt, würde es beim erneuten Start das Backend erneut auf den lokalen Rechner kopieren und die Tabellen einbinden. Das wird zum Problem, sobald der Benutzer vor dem Absturz bereits Daten geändert hat.
Beim Starten wird nämlich dann die alte Version des Backends vom Server geladen und eingebunden und die vor dem Absturz durchgeführten Änderungen sind nicht mehr verfügbar.
Dem müssen wir Rechnung tragen, indem wir beispielsweise in einer Optionen-Tabelle festhalten, wann das Backend vom Server auf den lokalen Rechner kopiert wurde und umgekehrt.
Dann können wir beim Start der Anwendung prüfen, ob das letzte Kopieren auf den Server vor oder nach dem letzten Kopieren vom Server auf den lokalen Rechner stattgefunden hat und damit ermitteln, ob die Anwendung beendet wurde, ohne dass das Backend auf den Server kopiert wurde.
Erster Schritt: Backend erstellen
Sollten Sie eine solche Lösung ausgehend von einer Datenbank erstellen, deren Tabellen und Benutzeroberfläche noch in einer einzigen Datenbankdatei gespeichert sind, müssen Sie zunächst ein Backend erstellen und die Tabellen, die später auf dem Server liegen sollen, in das Backend verschieben. Danach löschen Sie diese Tabellen aus dem Frontend und erstellen entsprechende Verknüpfungen auf die Tabellen des Backends. Als Beispiel verwenden wir die Datenbank zum flexiblen Verwalten von Adressen aus dem Beitrag Flexible Adressen (www.access-im-unternehmen.de/1214). Diese enthält eine überschaubare Anzahl von Tabellen.
Aufteilen der Datenbank
Das Aufteilen der Datenbank lassen wir bequem von dem dafür vorgesehenen Assistenten erledigen. Diesen starten Sie über den Ribbon-Befehl Datenbanktools|Daten verschieben|Access-Datenbank (siehe Bild 1).
Bild 1: Aufteilen einer Datenbank
Auf der ersten Seite des so gestarteten Assistenten klicken Sie auf die Schaltfläche Datenbank aufteilen und wählen im nun erscheinenden Dialog Back-End-Datenbank erstellen den Pfad zu der zu erstellenden Backend-Datenbank aus. Wir geben hier einfach den Namen der aufzuteilenden Datenbank mit dem Suffix _BE an, also BackendKopieren_BE.accdb (siehe Bild 2).
Bild 2: Auswahl der Zieldatenbank
Bei der hier verwendeten Anzahl Tabellen schließt der Assistent den Vorgang recht zügig ab.
Die Änderungen im Frontend sind überschaubar: Statt der bisher vorhandenen lokalen Tabellen finden sich im Navigationsbereich nun die gleichen Tabellen, allerdings mit dem Verknüpfungssymbol (siehe Bild 3).
Bild 3: Das Frontend nach der Aufteilung
Wenn Sie diese öffnen, zeigen Sie die Daten allerdings genau so an, als ob Sie eine lokale Tabelle verwenden. Auch das Bearbeiten der enthaltenen Daten geschieht wie gewohnt.
Verknüpfungen löschen und neu erstellen oder aktualisieren
Nun stellt sich die Frage: Wollen wir die Verknüpfungen löschen, bevor wir die Backend-Datenbank, die ja aktuell im gleichen Verzeichnis wie die Frontend-Datenbank liegt, auf den Server verschieben und diese neu anlegen, wenn das Backend beim nächsten Öffnen des Datenbankfrontends vom Server geholt wird Oder reicht es aus, die Verknüpfungen zu aktualisieren Wenn Sie das Frontend immer vom gleichen Verzeichnis aus starten und sich das Backend ebenfalls immer in diesem Verzeichnis befindet, ist das grundsätzlich nicht nötig, wenn nur das Backend ausgetauscht wird. Allerdings kann es ja einmal vorkommen, dass der Benutzer die Frontend-Datenbank auf einen anderen Rechner kopiert oder sich der Verzeichnisname ändert. Dann müssen die Verknüpfungen doch aktualisiert werden.
Wir begnügen uns mit dem Aktualisieren aller in der Frontend-Datenbank enthaltenen Verknüpfungen – so kann man auch einmal eine neue Tabelle zum Backend hinzufügen und braucht diese nur manuell zu verknüpfen, damit diese Verknüpfung bei folgenden Starts der Anwendung in das Aktualisieren aller vorhandenen Verknüpfungen integriert wird.
Verknüpfungen per VBA aktualisieren
Das Aktualisieren der verknüpften Tabellen erledigen wir mit der Prozedur aus Listing 1. Diese deklariert ein Database– und ein TableDef-Objekt und weist der Database-Variablen db das Database-Objekt der aktuellen Datenbank zu. Dann durchläuft es alle TableDef-Objekte der Auflistung TableDefs des Database-Objekts und referenziert diese jeweils mit der Variablen tdf.
Public Sub VerknuepfungenAktualisieren() Dim db As DAO.Database Dim tdf As DAO.TableDef Set db = CurrentDb For Each tdf In db.TableDefs If Not Len(tdf.Connect) = 0 Then tdf.Connect = ";DATABASE=" & CurrentProject.Path & "BackendKopieren_BE.accdb" tdf.RefreshLink End If Next tdf End Sub
Listing 1: Verknüpfungen aktualisieren
Dabei prüft sie zunächst anhand der Eigenschaft Connect des TableDef-Objekts, ob es sich bei der Tabelle um eine lokale oder eine verknüpfte Tabelle handelt. Enthält diese Eigenschaft einen Wert, handelt es sich um ein verknüpftes Objekt. In diesem Fall stellen wir die Eigenschaft auf einen Wert ein, der aus ;DATABASE=, dem Pfad der Frontend-Datenbank, einem Backslash sowie dem angenommenen Namen der Backend-Datenbank besteht, also zum Beispiel folgenden Ausdruck:
;DATABASE=C:...BackendKopierenBackendKopieren_BE.accdb
Danach aktualisieren wir die Verknüpfung mit der RefreshLink-Methode.
Aktualisieren der Verknüpfungen testen
Um die Verknüpfungen nach der Aktualisierung zu testen, verschieben Sie die beiden Datenbanken beispielsweise in ein Unterverzeichnis namens Test. Wenn Sie dann die Frontend-Datenbank öffnen und versuchen, eine der Tabellen über die Verknüpfung zu öffnen, erhalten Sie die Fehlermeldung aus Bild 4. Logisch: Die Verknüpfugn zeigt über die Connect-Eigenschaft noch auf den alten Speicherort der Backend-Datenbank.
Bild 4: Fehler beim Versuch, eine verknüpfte Tabelle nach dem Verschieben zu öffnen
Erst nachdem Sie nun die Prozedur VerknuepfungenAktualisieren aufrufen, funktioniert das Öffnen der verknüpften Tabellen wieder.
Übrigens reicht es nicht aus, Frontend und Backend einfach nur in ein anderes Verzeichnis zu kopieren, um den Fehler beim Zugriff auf eine der verknüpften Tabellen auszulösen. Genau genommen resultieren aus dieser Aktion oft Verwirrungen, weil man über das Frontend vermeintlich Daten der verknüpften Tabellen im neuen Verzeichnis vornimmt. Tatsächlich greift das Frontend aber, wenn Sie die Datenbankdateien nur kopieren und nicht verschieben (beziehungsweise die Datenbankdateien am alten Speicherort löschen) noch auf das Backend im alten Speicherort zu.
Optionen für das Kopieren
Nun wollen wir das Backend bei jedem Öffnen der Anwendung neu vom Server in das lokale Verzeichnis kopieren und die Verknüpfung aktualisieren. Dazu muss die entsprechende Prozedur wissen, unter welchem Pfad sie auf die auf dem Server liegende Datei zugreifen kann. Dazu wollen wir eine Optionen-Tabelle namens tblOptionen anlegen. Neben einem Feld namens Backendpfad wollen wir noch weitere Informationen in dieser Tabelle speichern. Wir müssen nämlich in irgendeiner Form festhalten, ob das Backend zuletzt vom Server auf das lokale Verzeichnis oder vom lokalen Verzeichnis auf den Server kopiert wurde.
Wenn das Backend zuletzt vom lokalen Verzeichnis auf den Server kopiert wurde, ist das offensichtlich beim vorherigen Schließen der Anwendung geschehen. Wenn hingegen beim Öffnen des Frontends die Information vorliegt, dass der letzte Kopiervorgang vom Server zum lokalen Verzeichnis erfolgte, dann wurde das Frontend bei der letzten Verwendung offensichtlich nicht korrekt geschlossen.
In diesem Fall wollen wir prüfen, ob das auf dem Server oder das im lokalen Verzeichnis gespeicherte Backend ein aktuelleres Bearbeitungsdatum hat. Ist das Backend im lokalen Verzeichnis neuer, soll der Benutzer gefragt werden, ob das neuere Backend weiter genutzt werden soll oder ob das ältere Backend vom Server über das vorhandene Backend kopiert werden soll.
Wie speichern wir diese Information ab Wir könnten zwei Felder definieren, die wir etwa ZuletztVomServerKopiert und ZuletztZumServerVerschoben nennen und die den Datentyp Datum/Uhrzeit erhalten. Oder wir verwenden einfach ein Boolean-Feld etwa namens ZuletztVomServerKopiert. Wenn es den Wert True enthält, wurde das Backend zuletzt vom Server in das lokale Verzeichnis kopiert, im Falle von False wurde es vom lokalen Verzeichnis zum Server verschoben.
Die Datumsangaben zu speichern, ist schon interessant, da wir dem Benutzer im Falle eines unterwarteten Schließens zusätzliche Informationen liefern können, wann das Backend zuletzt wohin kopiert oder verschoben wurde – also legen wir zwei Felder namens ZuletztVomServerKopiert und ZuletztZumServerVerschoben an.
Die Tabelle tblOptionen sieht damit wie in Bild 5 aus.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo