Versionsnummern in einer Datenbank-Applikation (Update)

Letzte Änderung am 24. Dezember 2023 by Christoph Jüngling

Die Aufgabenstellung habe ich bereits vor knapp 2 Jahren in dem Artikel Versionsnummern in einer Datenbank-Applikation beschrieben, und an der Ausgangssituation hat sich auch nichts geändert. In diesem Artikel will ich jedoch eine vereinfachte Version der Lösung vorstellen, die mir in der Zwischenzeit gute Dienste geleistet hat und die für die meisten Fälle vermutlich ausreichend sein wird.

Aufgabenstellung

Wir erinnern uns: Es geht um die Frage, wie ich sowohl die Applikations- als auch die Datenbank-Version so verwalten kann, dass es keine “Missverständnisse” gibt. Es soll also vermieden werden, dass eine zu alte Applikation auf eine Datenbank zugreift, deren Tabellenstruktur sich in der Zwischenzeit bereits geändert hat. Das mag nur eine kleine Änderung sein, aber manchmal steckt der Teufel halt im Detail.

Umgekehrt muss aber auch der Fall, dass die Applikation neuer ist, berücksichtigt werden. Die Frage, wie wir die Datenbank aktualisieren, lasse ich hier mal außen vor.

Einfache Lösung

Backend

Die einfache Lösung sieht im Backend (in der Datenbank) eine Tabelle namens USysVersion vor, die nur ein einziges Feld enthält, DBVersion.

Um die Frage zu beantworten, welchen Datentyp dieses Feld haben soll, möchte ich etwas ausholen. Man kann wohl davon ausgehen, dass Datenbanken in der Regel eine zentrale Rolle einnehmen. Während es viele Applikationen geben kann, die darauf zugreifen, wird es umgekehrt nur eine einzige Datenbank geben. Ferner gehe ich davon aus, dass die Veränderungen an dieser Datenbank linear sind, das heißt, dass es hierbei keine Verzweigung gibt. Es gibt immer einen neuesten Stand, und jeder weitere Stand wird auf diesem aufbauen. Wenn diese Voraussetzung in deinem Projekt nicht erfüllt ist, wird meine Lösung vermutlich nicht brauchbar sein.

Unter der oben genannten Voraussetzung wird nicht mehr als eine Nummer erforderlich sein, um den Stand der Datenbank eindeutig zu kennzeichnen. Die Nummer beginnt bei 1 und wird mit jeder Änderung an der Datenbankstruktur um 1 erhöht. Dann reicht der Datentyp Integer oder Long Integer für das Tabellenfeld sicher aus.

Frontend

Im Frontend muss es nun eine Stelle geben, die prüft, ob die Datenbank die richtige Struktur hat. Es wird aber nicht die Struktur selbst überprüft, sondern nur die Versionsnummer aus dem Feld DBVersion der Tabelle USysVersion gelesen, die natürlich im Frontend verknüpft sein muss. Zur besseren Lesbarkeit verknüpfe ich die Tabelle aus dem Backend unter dem Namen USysBackendVersion in das Frontend.

Die vom Frontend in der aktuellen Version benötigte Datenbankversion speichere ich in einer Public Const in meinem Modul “Globals”. Dadurch ist die Konstante im ganzen Projekt verwendbar und muss bei einem Update nur an dieser Stelle einmal geändert werden.

Public Const DB_VERSION = 123

Nun kann ich die Backend-Version mit einer einfachen Funktion ermitteln:

Public Function getBackendVersion() As Long

    getBackendVersion = Nz(DFirst("DBVersion", "USysBackendVersion"), -1)

End Function

Die Logik zum Überprüfen und die Reaktion im Problemfall ist dann ziemlich einfach:

Select Case getBackendVersion()
    Case Is > DB_VERSION
        MsgBox "Das Backend ist neuer als die Applikation benötigt!", vbCritical
        DoCmd.Quit acQuitSaveNone
        
    Case Is < DB_VERSION
        MsgBox "Das Backend ist älter als die Applikation benötigt!", vbCritical
        DoCmd.Quit acQuitSaveNone
End Select

Selbstverständlich können die beiden Meldungen auch ausführlicher sein oder ganz anders lauten. Ein Hinweis darauf, wo der Anwender ein Update herbekommt, wäre natürlich sinnvoll.

Auch eine Verbindung mit der Prüfung, ob eine neuere Applikation vorliegt, ist denkbar. Und sicher wäre es dann auch schön für den Anwender, wenn das Update automatisch angestoßen wird. Aber das ist eine andere Geschichte.

Fazit

Mit dieser einfachen Lösung sind wir gerüstet für Datenbankänderungen im Mehrbenutzerumfeld. Dabei muss das Backend keineswegs immer ein Access sein. Das gleiche Prinzip lässt sich für jede beliebige Datenbank umsetzen, zum Beispiel auch für den SQL-Server. Denn es ist ja keine datenbankspezifische Logik, die hier verwendet wird. Auch das Frontend kann sowohl in Access/VBA, als auch in einer beliebigen anderen Programmiersprache geschrieben sein.

Der Anwender profitiert von der klaren Kommunikation. Es wird erklärt, was das Problem ist, und wie es gelöst werden kann (oder das geschieht automatisch). Zufriedenheit ist wichtig, denn Meldungen wie “es ist ein unerwarteter Fehler aufgetreten, wenden Sie sich an Ihren Administrator” sollten nach Möglichkeit vermieden werden.

Ähnliche Artikel:

1 Ping

  1. […] Inzwischen gibt es einen Nachfolgeartikel, der eine einfachere Lösung […]

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

13 + 9 =