{"id":55000662,"date":"2009-04-01T00:00:00","date_gmt":"2020-05-22T22:22:44","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=662"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Verknuepfte_Datenbanken_updaten","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Verknuepfte_Datenbanken_updaten\/","title":{"rendered":"Verknüpfte Datenbanken updaten"},"content":{"rendered":"

\"\"<\/p>\n

Wer Software für einen Kunden entwickelt und nicht ständig an der Produktiv-Version arbeitet, steht irgendwann vor der Anforderung, die Produktiv-Version gegen die neue Version auszutauschen. Dieser Beitrag zeigt eine Möglichkeit, ein solches Update ohne Reibungsverluste durchzuführen.<\/b><\/p>\n

Zum Update einer Datenbank können mehrere Faktoren gehören. Es kann sein, dass man nur einen kleinen Fehler im Code behoben hat und dem Benutzer die neue Version zukommen lassen möchte – kein Problem, man tauscht einfach das am besten in einer Frontend-Backend-Konfiguration enthaltene Frontend aus und verknüpft das neue Frontend mit den Tabellen des alten Backends.<\/p>\n

Oder man stellt fest, dass man ein wichtiges Feld im Datenmodell vergessen hat. Das wird schon schwieriger: Das Backend mit dem Datenmodell kann man nicht so schnell austauschen, denn es enthält ja die aktuell benutzten Daten. In dem Fall wird man am einfachsten zum Kunden fahren und das Datenmodell vor Ort ändern oder dies per Fernwartung erledigen. Ist beides nicht möglich, leitet man den Kunden durch diesen Vorgang, was erfahrungsgemäß je nach dessen Fertigkeiten kompliziert werden kann.<\/p>\n

Sobald jedoch mehr als ein Kunde mit derselben Datenbank arbeitet oder häufige oder viele änderungen vorgenommen werden sollen, fällt die oben beschriebene Vorgehensweise flach.<\/p>\n

Vielleicht treffen ja auch änderungen am Frontend und am Backend zusammen, was zumindest dann der Regelfall ist, wenn das Backend betroffen ist – änderungen am Frontend sind dann nicht ganz unwahrscheinlich.<\/p>\n

Diese Kombination trifft sich gut, denn wenn man dem Kunden ein neues Frontend mit geänderter Benutzeroberfläche oder Anwendungslogik verpasst, kann man änderungen am Datenmodell gleich durch diese neue Version des Frontends erledigen lassen.<\/p>\n

Genau wie einige andere Vorgänge, die normalerweise beim Öffnen der Datenbank ablaufen – also etwa das Prüfen des Backends und der Verknüpfungen zu den Tabellen im Backend oder die Konsistenzprüfung bestehender Daten -, können Sie hier auch änderungen am Datenmodell des Backends durchführen lassen.<\/p>\n

Von A nach B<\/b><\/p>\n

Wenn Sie eine Datenbankanwendung nur für einen Kunden erstellt haben und weiterentwickeln, liegt eine komfortable Situation vor. Ausgehend davon, dass der Kunde neue Versionen immer direkt einsetzt, brauchen Sie beim Start des neuen Frontends nur ein paar Codezeilen aufzurufen, welche die seit dem letzten Update angefallenen änderungen am Datenmodell durchführen.<\/p>\n

Jedes weitere Update geht dann vom jeweils durch die Vorversion hergestellten Zustand aus und passt das Backend seinerseits an.<\/p>\n

Ganz anders sieht es aus, wenn zwei oder mehr Benutzer die Dienste Ihrer Datenbank in Anspruch nehmen, wobei „mehrere Benutzer“ nicht im Sinne von Mehrbenutzerumgebung, sondern von eigenständigen Anwendern mit eigenem Front- und Backend gemeint ist.<\/p>\n

Nehmen wir an, es gäbe der Einfachheit halber nur zwei Benutzer, von denen der eine die Anwendung in Version 1.0 betreibt und der andere bereits ein Update auf die Version 1.1 vorgenommen hat – der erste Benutzer hat dies schlicht ausgelassen.<\/p>\n

Wenn Sie nun eine neue Version 1.2 veröffentlichen, können Sie nicht mehr einfach nur davon ausgehen, dass diese Version überall die gleichen Voraussetzungen antrifft, um die in Version 1.2 enthaltenen änderungen etwa am Backend durchzuführen.<\/p>\n

Eine Tabelle, die in Version 1.1 hinzugefügt wurde und in Version 1.2 um ein weiteres Feld ergänzt werden soll, wäre beim Update von Version 1.0 auf Version 1.2 noch gar nicht vorhanden und würde so zu einem Fehler beim Hinzufügen des Feldes zur nicht vorhandenen Tabelle führen.<\/p>\n

Bevor jemand auf die Idee kommt: Es kommt natürlich nicht infrage, dass der Kunde nacheinander alle Zwischenversionen installiert, wenn er den Schritt von Version 1.0 etwa zu Version 1.6 machen möchte.<\/p>\n

Sie müssen also zumindest eine Überprüfung einbauen, mit welcher Version die Anwender arbeiten, und selbst dafür sorgen, dass die änderungen der einzelnen Versionen inkrementell durchgeführt werden – auch wenn der Anwender gleich mehrere Versionen überspringt.<\/p>\n

Verknüpft und zugenäht<\/b><\/p>\n

Als kleines Bonbon kommt noch hinzu, dass neu im Backend angelegte Tabellen erst noch verknüpft und die Verknüpfungen geänderter Tabellen aktualisiert werden müssen.<\/p>\n

Bevor Sie eine neue Version der Software verteilen, werden Sie vermutlich schon alle notwendigen Verknüpfungen angelegt haben, sodass diese beim Update nicht mehr hinzugefügt werden müssen (es wäre auch Unsinn, ein Frontend auszutauschen und dieses beim ersten Start nach dem Austausch dazu zu bringen, sich selbst anzupassen, indem es einige Verknüpfungen hinzufügt).<\/p>\n

Normalerweise sollten Sie aufgeteilten Datenbanken aber ohnehin einen Mechanismus mitgeben, der jeweils beim Anwendungsstart prüft, ob das Backend an Ort und Stelle ist, und die Verknüpfungen aktualisiert.<\/p>\n

Und da dieser doch recht eng mit dem Anlegen neuer Tabellen beim Update der Anwendung verknüpft ist, liefern wir diesen Mechanismus in diesem Beitrag gleich mit.<\/p>\n

Aufbau<\/b><\/p>\n

Die nachfolgend vorgestellten Techniken setzen ein paar Faktoren voraus. Zunächst einmal besteht das besprochene System wie erwähnt aus einer Frontend- und einer Backenddatenbank, wobei die Benutzeroberfläche (also Formulare, Berichte und Menüleisten), die Anwendungslogik und die Abfragen im Frontend und die durch die Anwendung zu verwaltenden Daten in entsprechenden Tabellen im Backend gespeichert sind.<\/p>\n

Damit Sie im Frontend auf die in den Tabellen des Backends enthaltenen Daten genau so zugreifen können, als ob diese im Frontend enthalten wären, legen Sie im Frontend eine Reihe von Verknüpfungen an, die das Datenbankfenster (Access 2003) oder der Navigationsbereich (Access 2007) mit entsprechenden Symbolen ausgestattet im Bereich Tabellen <\/b>aufführt (siehe Bild 1).<\/p>\n

\"pic001.png\"<\/p>\n

Bild 1: Verknüpfte Tabellen werden durch besondere Symbole markiert.<\/span><\/b><\/p>\n

In dieser Abbildung sehen Sie gleich eine recht wichtige Tabelle, die entscheidend für die hier vorgestellte Technik ist: tbl_VersionBE<\/b>. Diese Tabelle enthält nur ein Feld namens Version<\/b>, das die Nummer der aktuellen Version speichert. In Bild 2 ist dies die Nummer 0.904<\/b>. Wichtig: Natürlich muss sich diese Tabelle im Backend befinden und ist mit dem Frontend lediglich verknüpft! Anderenfalls würde diese ja mit jeder neuen Version des Frontends ausgetauscht.<\/p>\n

\"pic002.png\"<\/p>\n

Bild 2: Tabelle zum Speichern der Versionsnummer des Backends<\/span><\/b><\/p>\n

Dem Frontend können Sie eine ähnliche Tabelle beispielsweise mit dem Namen tbl_VersionFE <\/b>hinzufügen. Einen neuen Wert enthält die Tabelle mit jeder neuen Version des Frontends.<\/p>\n

Es kann sehr nützlich sein, wenn Sie Informationen über die Version von Frontend und Backend an gut sichtbarer Stelle unterbringen, damit der Benutzer Ihnen diese bei Problemen gegebenenfalls leicht mitteilen kann; für die Fehlerbehandlung sind diese Informationen natürlich ebenfalls hochinteressant (vielleicht lassen Sie sich die Fehlermeldungen bei Laufzeitfehlern per E-Mail zusenden, dann sollten Informationen über die Version von Frontend und Backend nicht fehlen – neben Modul, Prozedurname, Zeile, Fehlernummer et cetera).<\/p>\n

Ablauf<\/p>\n

Bevor wir uns den Code ansehen, der für das Verknüpfen und Updaten des Backends sorgt (nicht vergessen: das Update des Frontends erfolgt ganz einfach durch seinen Austausch, das neue Frontend führt dann das Update des Backends aus!), schauen wir uns den Ablauf im Überblick an.<\/p>\n

Diesen verschafft Abb. 3, die alle Schritte der im Modul mdlGlobal <\/b>befindlichen Funktion StartDB <\/b>der Beispieldatenbank darstellt, wobei die einzelnen Schritte durchnummeriert sind, damit wir uns im Text besser darauf beziehen können (auch in den folgenden Listings taucht diese Nummerierung auf).<\/p>\n

\"Versionierung.emf\"<\/p>\n

Bild 3: Ablauf beim Verknüpfen und Updaten des Backends durch ein neues Frontend<\/span><\/b><\/p>\n

Im ersten Schritt (1) liest die Routine aus Listing 1 über die Hilfsfunktion GetCurrentBackendPath <\/b>(s. Listing 2) den Pfad und den Dateinamen des Backends aus, auf den sich die im Frontend enthaltenen Tabellenverknüpfungen beziehen.<\/p>\n

Listing 1: Die Routine StartDB steuert das Update des Backends und die Prüfung und Aktualisierung der Tabellenverknüpfungen.<\/p>\n

Const cStrVersionTable = "tbl_VersionBE"\r\nPublic Function StartDB()\r\n    Dim dbFrontend As DAO.Database, dbBackend As DAO.Database\r\n    Dim strBackendpath As String\r\n    Dim bolBackendFound As Boolean, bolTablesExist As Boolean, bolStartSuccessful As Boolean\r\n    Dim strOldVersion As String, strNewVersion As String, strCurrentVersion As String\r\n    Set dbFrontend = CurrentDb\r\n    GetCurrentBackendPath dbFrontend, cStrVersionTable, strBackendpath\r\n    On Error Resume Next\r\n    bolBackendFound = Len(Dir(strBackendpath)) > 0\r\n    On Error GoTo 0\r\n    If bolBackendFound = False Then\r\n        strBackendpath = dbFrontend.OpenRecordset("SELECT Optionvalue FROM tblOptions_Backend " _\r\n        & "WHERE Optionname = 'Backendpath'").Fields(0)\r\n        On Error Resume Next\r\n        bolBackendFound = Len(Dir(strBackendpath)) > 0\r\n        On Error GoTo 0\r\n    End If\r\n    Do While bolTablesExist = False\r\n        Do While bolBackendFound = False\r\n            strBackendpath = OpenFileName(Left(strBackendpath, InStrRev(strBackendpath, "\\")), _\r\n            "Backend auswählen", "Access 2007-Datenbank (*.accdb)|Access 2003 und älter-Datenbank " _\r\n            & "(*.mdb)|Alle Dateien (*.*)")\r\n            If Len(strBackendpath) = 0 Then Exit Function\r\n            bolBackendFound = Len(Dir(strBackendpath)) > 0\r\n        Loop\r\n        Set dbBackend = OpenDatabase(strBackendpath)\r\n        If CheckTables(dbFrontend, dbBackend, True) = True Then\r\n            strOldVersion = dbBackend.OpenRecordset("SELECT Version FROM tbl_VersionBE").Fields(0)\r\n            strNewVersion = dbFrontend.OpenRecordset("SELECT NeueVersion FROM tblVersionen " _\r\n            & "ORDER BY ReihenfolgeID DESC").Fields(0)\r\n            Do While Not strCurrentVersion = strNewVersion\r\n                If UpdateVersion(dbFrontend, dbBackend, strOldVersion, strCurrentVersion) = True Then\r\n                    strOldVersion = strCurrentVersion\r\n                Else\r\n                    MsgBox "Das Update wurde nicht durchgeführt."\r\n                    Exit Function\r\n                End If\r\n            Loop\r\n            bolTablesExist = CheckTables(dbFrontend, dbBackend, False) = True\r\n        Else\r\n            bolBackendFound = False\r\n        End If\r\n        If bolTablesExist = False Then\r\n            If MsgBox("In der Datenbank '" & strBackendpath & "' fehlen eine oder mehrere der benötigten " _\r\n            & "Tabellen." & vbCrLf & vbCrLf & "Klicken Sie auf 'OK', um eine andere Datenbank " _\r\n            & "auszuwählen oder auf 'Abbrechen', um die Anwendung zu beenden.", _\r\n            vbOKCancel + vbExclamation, "Falsche Datenbank") = vbCancel Then\r\n            DoCmd.Quit\r\n            Exit Function\r\n        End If\r\n    End If\r\nLoop\r\nIf ReconnectBackend(dbFrontend, strBackendpath) = True Then\r\n dbFrontend.Execute "UPDATE tblOptions_Backend SET Optionvalue = '" & strBackendpath _\r\n    & "' WHERE Optionname = 'Backendpath'", dbFailOnError\r\n    bolStartSuccessful = True\r\nEnd If\r\nEnd Function<\/pre>\n
Listing 2: Die Funktion GetCurrentBackendPath ermittelt die Datenbank, mit der die Tabellenverknüpfungen aktuell verknüpft sind.<\/p>\n
Public Function GetCurrentBackendPath(dbFrontend As _\r\n    DAO.Database, strTable As String, _\r\n    strBackendpath As String) As Boolean\r\n    Dim strTemp As String\r\n    strTemp = dbFrontend.TableDefs(strTable).connect\r\n    strTemp = Mid(strTemp, InStr(1, strTemp, "DATABASE=") + 9)\r\n    If InStr(1, strTemp, ";") > 0 Then\r\n        strTemp = Left(strTemp, InStr(1, strTemp, ";") - 1)\r\n    End If\r\n    If Not Len(strTemp) = 0 Then\r\n        strBackendpath = strTemp\r\n        GetCurrentBackendPath = True\r\n    End If\r\nEnd Function<\/pre>\n
<\/p>\n
Dazu ist noch kein Kontakt mit dem Backend erforderlich; die Information wird per DAO über die Connect<\/b>-Eigenschaft einer der Tabellenverknüpfungen ermittelt (siehe weiter hinten unter Aktuelle Backend-Datenbank ermitteln<\/b>).<\/p>\n
Hier gibt es zwei Möglichkeiten, die in (2) geprüft werden. Dabei testet die Routine mit der Dir<\/b>-Funktion, ob die für die Verknüpfung angegebene Datei überhaupt existiert, und findet eines der folgenden beiden Ergebnisse vor:<\/p>\n