Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
Immer wieder tauchen in Newsgroups und Foren Fragen wie die folgende auf: „Hilfe, meine Datenbank funktioniert nicht mehr. Was kann ich tun“ Neben diversen Rettungsstrategien für korrupte Datenbanken wird dann häufig auf die letzte Sicherungskopie verwiesen. Wenn überhaupt eine Sicherungskopie existiert, ist diese meist mehrere Tage alt. Das Problem beim Einsatz dieser Sicherungskopie ist, dass alle änderungen der letzten Tage verworfen werden. Dabei ist die Lösung relativ einfach: Verwenden Sie für die Entwicklung Ihrer Access-Datenbank eine Quellcodeverwaltung.
In diesem Beitrag finden Sie die Grundlagen zum Thema Quellcodeverwaltung mit Access. In einem weiteren Beitrag zeigen wir dann, Schritt für Schritt, von der Einrichtung der Quellcodeverwaltung bis zur Erledigung von Alltagsaufgaben, wie Sie mit einer Versionsverwaltung in Access arbeiten.
Akzeptanz
Zum Thema Quellcodeverwaltung haben Access-Programmierer anscheinend noch keinen rechten Zugang gefunden. Diesen Eindruck legt zumindest das Ergebnis einer kleinen Umfrage nahe:
- Haben Sie schon von Quellcodeverwaltung gehört – 100 %
- Haben Sie bereits über den Einsatz eines Quellcodeverwaltungssystems nachgedacht – 75 %
- Haben Sie schon eine Quellcodeverwaltung ausprobiert – 66 %
- Haben Sie ein Quellcodeverwaltungssystem systematisch eingesetzt – 10 %
Es haben zwar schon fast alle Access-Entwickler von Quellcodeverwaltung gehört. Über deren Einsatz nachgedacht und sie einmal ausprobiert haben auch schon sehr viele Programmierer. Beim regelmäßigen Einsatz hapert es aber. Ganze 10 % der Befragten gaben an, regelmäßig für ihre professionellen Projekte eine Quellcodeverwaltung zu verwenden.
Das grundsätzliche Interesse am Thema Quellcodeverwaltung scheint also gegeben zu sein. Woran liegt es aber, dass nur so wenige Access-Programmierer regelmäßig eine Quellcodeverwaltung einsetzen Von den Interessenten werden folgende Vorbehalte genannt:
- Quellcodeverwaltung ist nur etwas für Profis.
- Quellcodeverwaltung ist bestimmt kompliziert.
- Die notwendigen Tools für die Quellcodeverwaltung sind (zu) teuer.
Lassen Sie uns diese Vorbehalte in umgekehrter Reihenfolge beleuchten.
In dem zweiten Beitrag in der kommenden Ausgabe von Access im Unternehmen zum Thema Quellcodeverwaltung werden verschiedene Tools genannt werden. Darunter sind auch einige eher kostspielige Varianten zu finden. In dem Beitrag werden wir uns aber ausführlich auf ein Freeware-Tool konzentrieren. Um dieses Tool mit Access einsetzen zu können, ist noch ein zusätzliches Add-In erforderlich. Die Anschaffung dieses Add-Ins ist aber relativ günstig.
Zur Aussage, dass Quellcodeverwaltung kompliziert sei, ist zu sagen, dass man seine bisherige Arbeitsweise etwas an die Verwendung einer Quellcodeverwaltung anpassen muss. Wenn man sich aber erst einmal damit vertraut gemacht hat, kommt man schnell in den Genuss der Vorteile, die eine Versionsverwaltung mit sich bringt.
Bleibt noch das letzte Argument: „Quellcodeverwaltung ist nur etwas für Profis.“ Es ist sicher richtig, dass zu einer professionellen Softwareentwicklung der Einsatz einer Quellcodeverwaltung gehört. Dies soll Sie aber nicht davon abhalten, in den Genuss der Vorteile einer Versionsverwaltung zu kommen.
Vorteile einer Versionsverwaltung
Es ist schon mehrfach erwähnt worden, dass die Verwendung einer Quellcodeverwaltung Vorteile mit sich bringt. Doch worin liegen diese Vorteile genau
Der wichtigste Vorteil ist, dass immer eine Sicherungskopie Ihrer Datenbank existiert. Ihre Datenbank wird, in ihre einzelnen Objekte zerlegt, in der Quellcodeverwaltung gespeichert. Die Daten der Quellcodeverwaltung werden an einem anderen Ort als Ihre Datenbank hinterlegt. Sie können jederzeit aus der Quellcodeverwaltung eine neue Kopie Ihrer Datenbank erstellen.
Durch die Verwendung einer Quellcodeverwaltung wird eine effiziente Teamarbeit in einer Access-Datenbank ermöglicht. Wenn Sie ohne Quellcodeverwaltung gemeinsam an einer Datenbank arbeiten, erhält jeder Entwickler eine Kopie der Datenbank, die er dann bearbeitet.
Am Ende müssen Sie dann alle änderungen an allen Objekten der verschiedenen Entwickler in einer gemeinsamen Version zusammenführen. Dieser Prozess ist mühsam und fehleranfällig. Zum einen laufen Sie Gefahr, nicht alle bearbeiteten Objekte in die gemeinsame Version zu kopieren.
Zum anderen kann es passieren, dass zwei Entwickler das gleiche Objekt geändert haben. Dann müssen Sie die änderungen mühsam zusammenführen.
Mit dem Einsatz einer Quellcodeverwaltung gestaltet sich das gemeinsame Arbeiten an einer Datenbank wesentlich einfacher. Alle Entwickler arbeiten mit einer Kopie der Datenbank, die mit der Quellcodeverwaltung „verbunden“ ist.
Das mühsame Zusammenfügen der geänderten Objekte entfällt also. Außerdem kann die Quellcodeverwaltung so eingestellt werden, dass sichergestellt wird, dass immer nur ein Entwickler an einem Objekt arbeitet.
Durch den Einsatz einer Quellcodeverwaltung gelangen Sie in den Genuss einer Protokollierung. Sie können damit die Frage beantworten, wer wann welches Objekt wie geändert hat.
Die Protokollierung wird dadurch erreicht, dass Sie jedes Objekt nach der Bearbeitung mit einem Kommentar versehen und wieder in die Quellcodeverwaltung einchecken. Auf diesem Weg können Sie feststellen, wann an einem Objekt welche änderung vorgenommen wurde.
Ein weiterer wichtiger Vorteil ist, dass Sie jederzeit von jedem Objekt jede vorherige Version wiederherstellen können.
Diese Möglichkeit versetzt Sie in die Lage, schnell auf auftretende Fehler reagieren zu können. Sie stellen einfach die letzte als funktionierend bekannte Version wieder her. Während Ihre Benutzer weiterarbeiten, können Sie in aller Ruhe den Fehler suchen und beseitigen.
Teamarbeit
Nachdem die Vorteile einer Versionsverwaltung aufgezeigt wurden, ist es an der Zeit, sich mit der grundsätzlichen Problemstellung und möglichen Lösungsansätzen vertraut zu machen.
Die nachfolgende Darstellung dieses Themas ist an das Handbuch zu TortoiseSVN [1] angelehnt.
Gehen wir im Beispiel davon aus, dass zwei Entwickler (nennen wir sie Adam und Eva) eine Datei bearbeiten wollen. Was passiert
- Im ersten Schritt kopieren sich sowohl Adam als auch Eva die zu bearbeitende Datei aus der gemeinsamen Dateiablage in ein lokales Laufwerk. Im zweiten Schritt bearbeiten dann beide Entwickler ihre jeweilige Kopie (siehe Bild 1).
- Adam kopiert seine Datei zuerst wieder in die gemeinsame Dateiablage zurück. Kurz darauf kopiert Eva ihre änderungen ebenfalls zurück und überschreibt damit Adams änderungen (siehe Bild 2).
Bild 1: Die gemeinsame Bearbeitung einer Datei …
Bild 2: … und die daraus resultierenden Probleme
Der Vorteil an diesem Vorgehen ist, dass beide Entwickler unabhängig voneinander arbeiten können. Das ist aber auch gleichzeitig der größte Nachteil. Keiner der Entwickler weiß, welches Dokument der andere gerade bearbeitet. So kommt es, dass sich die änderungen gegenseitig überschreiben. Es gilt das Prinzip „Last one wins“.
An diesem Beispiel können Sie sehr schön sehen, welche Probleme sich ergeben, wenn mehrere Entwickler gemeinsam an einer Datei arbeiten.
Lock, Modify, Write
Zur Lösung des Problems gibt es zwei grundlegende Strategien. Die erste Strategie trägt den Namen Lock, Modify, Write. Der Name beschreibt bereits den wesentlichen Kern. Wer eine Datei bearbeiten möchte, muss diese zuerst sperren. So wird sichergestellt, dass immer nur ein Entwickler zur gleichen Zeit änderungen durchführen kann.
Schauen wir uns an, wie die Strategie Lock, Modify, Write genau funktioniert:
- Wieder sollen zwei Entwickler an einer Datei arbeiten. Diesmal befindet sich die Datei unter Quellcodeverwaltung. Statt in der Dateiablage wird die Datei in einem sogenannten Repository verwaltet.
- Adam möchte als Erster die Datei bearbeiten. Damit er das darf, muss er zunächst die Datei im Repository sperren. Danach ruft Adam die aktuelle Kopie der Datei zur Bearbeitung ab (siehe Bild 3).
- Im nächsten Schritt ändert Adam seine lokale Kopie. Mittlerweile möchte auch Eva die Datei bearbeiten. Auch sie muss dazu die Datei erst im Repository sperren. Das funktioniert jedoch nicht, da die Datei im Repository schon zugunsten von Adam gesperrt ist.
- Nachdem Adam seine Arbeit abgeschlossen hat, schreibt er die geänderte Datei zurück in das Repository und hebt die Sperre auf (siehe Bild 4).
- Jetzt kann Eva die Datei im Repository sperren. Als Nächstes ruft sie die aktuelle Datei zur Bearbeitung ab. Auf diesem Weg erhält sie die soeben von Adam durchgeführten änderungen. Jetzt kann Eva die Datei bearbeiten.
Bild 3: Mit der Strategie Lock, Modify, Write kann …
Bild 4: … eine Datei nur nacheinander bearbeitet werden.
Die Vorteile dieser Lösung liegen auf der Hand. Es kann immer nur ein Entwickler die Datei sperren und somit ändern. Das vorherige Sperren verhindert konkurrierende änderungen.
Der Nachteil dieser Lösung liegt ebenfalls in der erforderlichen Sperre der Dateien. Diese verzögert eventuell die weitere Bearbeitung durch andere Entwickler. Dabei wäre die Sperre unter Umständen unnötig, wenn sich die änderungen nicht überschnitten hätten.
Copy, Modify, Merge
Die Kritik an der Strategie Lock, Modify, Write greift die Strategie Copy, Modify, Merge auf. Bei dieser Strategie kann jeder Entwickler ohne Sperre eine Datei ändern. Wenn er die Datei zurückschreiben will, werden seine änderungen in die bestehende Datei eingefügt. Weil hier die änderungen mit dem bestehenden Dokument gemischt werden, wird der Vorgang mergen genannt.
Schauen wir uns auch hier an, wie diese Strategie genau funktioniert:
- Erneut sollen zwei Entwickler eine Datei bearbeiten, die sich unter Quellcodeverwaltung befindet.
- Dieses Mal rufen beide Entwickler die Datei zur selben Zeit zur Bearbeitung aus der Quellcodeverwaltung ab (siehe Bild 5). Da keine Sperre erforderlich ist, funktioniert das. Im nächsten Schritt nehmen beide Entwickler ihre änderungen vor. Es existieren jetzt drei verschiedene Versionen der Datei.
- Eva speichert ihre änderungen als Erste zurück in die Quellcodeverwaltung (siehe Bild 6). Als Zweiter möchte Adam seine änderungen in der Quellcodeverwaltung speichern. Dies funktioniert jedoch nicht, da die in der Quellcodeverwaltung gespeicherte Kopie der Datei seit seinem letzten Abruf geändert wurde.
- Damit Adam seine änderungen zurückschreiben kann, muss er zuerst die aktuelle Version der Datei aus der Quellcodeverwaltung abrufen und diese mit seiner Kopie vergleichen (siehe Bild 7). Adam erstellt im nächsten Schritt eine neue Datei. Dies tut er, indem er seine änderungen in die heruntergeladene Datei einfügt.
- Dieser Vorgang, den man mergen nennt, wird von der Quellcodeverwaltung unterstützt. Im Idealfall ist kein manueller Eingriff erforderlich, weil alle änderungen konfliktfrei eingefügt werden können.
- Im letzten Schritt kann Adam dann die Datei mit seinen änderungen in der Quellcodeverwaltung speichern (siehe Bild 8). Dort ist die Datei für Eva verfügbar. Wenn sie sich diese Datei abruft, haben wieder beide Entwickler den gleichen Stand.
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
Testzugang
eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel
diesen und alle anderen Artikel mit dem Jahresabo