Datum: 17.11.2021
Thema: Quellcodeverwaltung mit MS Access und Ivercy (Gastvortrag von Philipp Stiefel), Hilfe bei Problemen und allgemeine Diskussion – alles wieder virtuell und „experimentell“
Zum November-Stammtisch hatten unser virtuelle Access-Stammtisch Philipp Stiefel zu Gast. Phil dürfte vielen von den AEKs bekannt sein (www.ivercy.com).
In seinem Vortrag stellte er das Thema Quellcodeverwaltung mit Access und dem Tool Ivercy vor.
Einleitend stellte Philipp klar, dass sein Vortrag aus einem halbstündigen Theorieteil (produktunabhängig, ganz universell, Basis-Knowhow) und einem Praxis-Teil besteht.
Im ersten Teil gab es denn auch produktneutrale Wissensvermittlung zum Thema Quellcodeverwaltung. Zu Beginn stand die Frage im Raum, warum es überhaupt Quellcodeverwaltung braucht.
Dazu gab es 2015 einen Vortrag auf der AEK 18 (PDF-Datei, zip-komprimiert, ca. 0,91 MB).
Das „Fundament“ bildet in der Regel ein sog. Repository, also eine Art „Lager für Quellcode“.
Der Quellcode wird dort mit allen Änderungen gespeichert und wird auf dem Zeitstrahl quasi „hinzuaddiert“.
Immer, wenn man in Access arbeitet und testet, führt man dann einen Check-in durch (commit). Damit erfolgt die Weitergabe an die Quellcodeverwaltung: Ein Versions-Stand kommt hinzu, ein alter Stand geht jedoch nicht verloren.
Die zweite Stufe, die eine Quellcodeverwaltung ausmacht, ist die Versionshistorie.
Mit Hilfe von Labels bzw. Tags können hier Versionsstände definiert werden oder Dateien beliebiger Versionsstände verglichen werden (diff).
Für die Historie ist es empfehlenswert, sinnvolle Kommentare zu verwenden.
Wenn man ferner ein Bugtracking-System hat (z. B. Visual Devop-Server), kann man es mit einem Quellcodesystem verlinken.
Ein gutes Quellcodeverwaltungs-System unterstützt auch die Arbeit mit Zweigen (Branches).
Angenommen, ein Kunde findet einen Bug. Im Quellcodesystem kann man dann einen Branch erstellen. Daraus wird dann ein Bugfix für Kunden erstellt. Der Bugfix kann sodann in den Hauptbranch integriert werden. Man kann sich diese Arbeit als parallele „Zeitsträhle“ vorstellen.
Zuletzt sollte ein Quellcodeverwaltungssystem die Zusammenarbeit mit anderen Entwicklern ermöglichen. Dazu muss man dafür sorgen, dass andere Entwickler auch den Code bekommen
(Austausch z.B. per URL). Änderungen von anderen können so ganz einfach übernommen werden.
Unter der Prämisse, dass eine Quellcodeverwaltung Dateien verwaltet, sollte die Arbeit mit Access ja möglich sein (Access ist ja dateibasiert, oder?).
Immerhin stehen mit LoadAsText und SaveAsText zwei (undokumentierte) Funktionen zum Exportieren von Modulen (außer Tabellen) in Access zur Verfügung.
Zunächst werden in Ivercy also alle Bestandteile (Berichte, Formulare, Module, Makros) aus Access in ein lokales Arbeitsverzeichnis gespeichert.
Im zweiten Schritt werden diese Bestandteile in das SCC-Repository überführt. Hier finden sich dann auch die unterschiedlichen Versionsstände wieder.
Die neuen Versionsstände werden dann aus dem Repository über das lokale Arbeitsverzeichnis nach Access zurückgeschrieben.
Über Jahrzehnte wurde bei der Verwendung eines SCC-Repository und Access ein zentraler Ansatz verfolgt. Es gab eine SCC und damit waren Access-Datenbanken wechselseitig verbunden.
Heute wird eher ein verteiltes System verwendet. Damit hat jede Access-Datenbank ihr eigenes SCC-Repository.
Git ist dabei als de-facto-Standard beteiligt. Bei verteilter Quellcodeverwaltung hat jeder Entwickler sein eigenes Repository. Dieser Ansatz ermöglich auch die Zusammenarbeit z.B. mit einem weiteren Entwickler.
Ferner ist ein übergreifender Austausch mit Hilfe eines zentralen Repository möglich.
Über den Git-Befehl pull kann man dann die Daten in sein eigenes Repository holen. Umgekehrt können mit dem push-Befehl die Daten nach Git übertragen werden.
Allgemein hat eine verteilte Quellcodeverwaltung diverse Vorteile:
- (fast) alles kann offline erfolgen
- man hat die volle Kontrolle über sein lokales Repository
- ein flexibler Austausch zwischen Entwicklern ist möglich
Nachteilig ist jedoch dabei der höhere Komplexitätsgrad, da neue Befehle hinzukommen.
Im praktischen Teil zeigt Philipp dann Ivercy im Einsatz unter Access. Als Beispiel griff er dabei auf die bekannte Northwind-Datenbank zurück.
Das Ivercy-Add-In verbindet sich beim Start zu GitHub. Dann erfolgt die Auswahl eines lokalen Repository. Eine E-Mail-Adresse dient dabei als Benutzerkennung.
Dann wählt man einen Branch (Entwicklungsstrang) aus oder legt einen neuen Branch an (bei GitHub main).
Ivercy bietet dann über eine Objektliste an, die Access-Objekte auszuwählen und ggf. nach Objekttyp und SCC-Status zu filtern. Ferner können Kommentare eingegeben werden.
In Access werden dann alle Objekte mit einem grünen Haken versehen. D.h., ein Objekt ist nicht exklusiv ausgecheckt (nicht gesperrt).
Andere Entwickler könnten es daher auch auschecken (Normalzustand bei GitHub, da verteilte Arbeit).
Über Undo Checkout bzw. Get Latest Version kann der letzte Stand aus GitHub abgeholt werden.
Show Diff zeigt dabei die Änderungen an. Das aktuelle Access-Objekt wird mit dem letztem Repository-Objekt verglichen.
Ulrich fragt, ob das Formular physikalisch gespeichert ist. Diese Frage kann Philipp mit einem klaren „ja“ beantworten.
Klaus fragt, ob Dateien, die man in GitHub hat, mit SaveToText erstellt wurden. Auch dies ist laut Philipp der Fall.
Ulrich fragt, wozu Microsoft so viel Aufwand dafür betreibt.
Laut Philipp hat Microsoft ursprünglich SaveToText / LoadFromText für die Arbeit mit einer Quellcodeverwaltung vorgesehen, jedoch sind bei vielen Abfragen SaveToText / LoadFromText langsamer.
Mit dem Ivercy-Add-In können aus Access diverse Quellcode-Systeme angesprochen werden.
Pro Entwickler kostet das Tool 99 €, eine 5-User-Lizenz schlägt mit 419 € zu Buche.
Ulrich erkundigt sich, ob Ivercy ein Frontend für GitHub sei. Es ist eine einfache lokale Installation.
Andreas Summer empfiehlt Gitea. Das ist ein Open-Source-Forge-Softwarepaket für das Hosting der Versionskontrolle der Softwareentwicklung mit Git sowie anderen kollaborativen Funktionen wie Bug-Tracking, Wikis und Code-Review.
Stefan Hackentahl erwähnt die Möglichkeit, Git z.B. auch auf einem NAS-Server laufen lassen zu können.
Andreas Lotze fragt, ob ein Git-Key als Alternative zur 2FA in GitHub verwendet werden kann. Das wird von Philipp bestätigt.
Die offizielle Seite https://git-scm.com empfiehlt Philipp für alle, die was mit Git machen wollen.
Mit Tags kann man zusätzlich z.B. die Dokumentation vernünftig zusammenhalten, meint Klaus.
Andreas fragt, ob es Probleme mit Zeichencodierung gibt. Bei Access kann man einen Unicode-Export als UTF-16 (Little Indian) durchführen, weiß Philipp dazu zu berichten. Ivercy konvertiert nach UTF-8.
In der anschließenden Diskussion geht es zunächst um Modularität.
Andreas Summer will eine Access-Anwendung modularer gestalten. Seine Idee ist es, Formulare nur in einer Formular-Datenbank zu halten und sie per Verweis einzubinden. Das Problem: Sie werden nur in der Hauptdatenbank gesucht.
Vorteil: Erweiterung der Ressourcen. Der Grund für die Modularisierung ist, das Andreas zu viel Codezeilen im Gesamtprojekt hat.
Ulrich fragt, ob man DAO in der Access Redistributable benutzen kann.
Phil ist sich sicher: Aus Excel geht es und Andreas erwähnt, dass DAO Teil von Windows ist.
Aus Access kann man so über eine interne, eigene Engine z.B. aus Excel importieren.
Zum Ende des Stammtischs gibt es noch eine kurze AEK-Nachlese. Besonders die Online-Technik wurde lobend erwähnt.
Zuletzt bietet Stefan Hackenthal an, auf einem der nächsten Stammtische sein Projekt vorzustellen (Access Backend und Excel Frontend).
Access-Stammtisch Hannover 