WKL Office SDK: Versionsverwaltung und Builds für Microsoft Access

Mit dem WKL Office SDK führen Sie eine Microsoft-Access-Anwendung in git oder Subversion und prüfen Änderungen je Formular, Abfrage und Modul. Die ACCDB oder ACCDE baut das SDK aus einem definierten Stand der Quellen – nicht aus der Datenbankdatei, die zuletzt gespeichert wurde. Formulare, Berichte und VBA-Code entwerfen Sie weiterhin in Access; das SDK überträgt sie zwischen Access und den Textquellen und baut daraus die Datenbank.

Unterstützte Konfiguration: Windows 11 mit Microsoft 365 Access in 32 oder 64 Bit. Access 2016 bis 2021, Windows 10 und Builds allein mit der Access Runtime werden in diesem Release nicht unterstützt. Was sich in den einzelnen Releases geändert hat, steht in der Datei CHANGELOG.md des Release-Pakets.

Eine Access-Anwendung steckt in einer einzigen Binärdatei: Formulare, Berichte, Abfragen, Code, Tabellen und Einstellungen zusammen. Solange ein Entwickler an einer Kopie arbeitet, genügt das. Es genügt nicht mehr, sobald eine dieser Fragen aufkommt:

• Was hat sich geändert? Zwei Kopien einer ACCDB lassen sich nicht zeilenweise vergleichen. Um herauszufinden, was die Anwendung beschädigt hat, werden alte Kopien nebeneinander geöffnet.
• Wer arbeitet daran? Zwei Entwickler können ihre Arbeit nicht in einer Datei zusammenführen. Einer überträgt die Formulare des anderen von Hand, und eine Änderung, die in der falschen Kopie gespeichert wurde, geht spurlos verloren.
• Was erhalten die Benutzer? Das Release ist die eigene ACCDB des Entwicklers, zur ACCDE kompiliert mit allem, was sie an diesem Tag gerade enthielt: Testformulare, eine alte Verknüpfung, ein unfertiges Modul.
• Lässt sich das ohne einen Menschen prüfen? Ob die Anwendung vollständig ist und sich kompilieren lässt, kann ein Skript nicht feststellen – nur das Öffnen in Access zeigt es.

Access selbst kann einzelne Objekte als Text schreiben (SaveAsText, LoadFromText). Microsoft dokumentiert diese Methoden jedoch nicht, und sie lassen Tabellen, Daten, Verweise und Datenbankeigenschaften aus. Eine vollständige Anwendung lässt sich allein daraus nicht wieder aufbauen.

Die vier Antworten bauen aufeinander auf: Ist die Anwendung Text, lassen sich ihre Änderungen lesen; lassen sich Änderungen lesen, können mehrere Personen daran arbeiten; sind die Quellen vollständig, lässt sich die Datenbank daraus bauen; und ist ein Build ein einziger Befehl, kann er ohne einen Menschen laufen.

graph TD
    A[Access: Formulare, Berichte, Code entwerfen] -->|wkl-office export / commit| S[Quellen in git oder svn]
    S -->|wkl-office build| B[build/Debug/App.accdb]
    S -->|wkl-office build -c Release| R[build/Release/App.accde]
    B -->|in Access öffnen| A
    S -->|CI: check, build, roundtrip| C[Exitcode + JSON]

Maßgeblich ist das Repository; ACCDB und ACCDE sind Build-Ergebnisse, die nie committet werden.

• Projektdatei (<name>.acproj): MSBuild-XML, das die Anwendung, ihren Quellordner und ihre Build-Konfigurationen benennt (Referenz).
• Quellen (source/): eine Datei je Objekt, Tabelle und Modell, in einer festen Struktur (Referenz). Objekte bleiben so erhalten, wie Access sie schreibt, bereinigt um Werte, die sich bei jedem Speichern ändern; Tabellen als JSON-Schema, Startdaten als JSON Lines, dazu Verweise, Datenbankeigenschaften, Design, Bilder, Menübänder und die Modelle der WKL Forms Object Library.
• Konfigurationen (Debug, Release, eigene Namen): legen fest, ob eine ACCDE entsteht, für welchen Modus des Anwendungsmodells sie entsteht und mit welchem Verbindungsprofil die Tabellen verknüpft werden.
• Access bleibt der Designer. Das SDK automatisiert das auf dem Rechner installierte Access prozessübergreifend (out of process). Es ersetzt weder den Formular- noch den Berichtsentwurf.

Ein Entwickler, der das Projekt ausgecheckt hat:

1. Arbeitsdatenbank bauen aus den Quellen: wkl-office build Kunden.acproj schreibt build/Debug/Kunden.accdb.
2. Anwendung in Access ändern wie gewohnt: ein Formular entwerfen, ein Modul bearbeiten, speichern.
3. Änderungen ansehen: wkl-office changes Kunden.acproj listet die geänderten Objekte jeweils mit dem nächsten Schritt auf; wkl-office diff Kunden.acproj form:frmKunden zeigt die Zeilen.
4. Committen: wkl-office commit Kunden.acproj -m "Kundenformular: neues Feld für die USt-IdNr." prüft erneut, exportiert die geänderten Objekte in die Quellen und committet sie. Gepusht wird erst mit wkl-office push.
5. Release: Auf jedem Rechner mit demselben Access und denselben Verweisen baut wkl-office build Kunden.acproj -c Release die ACCDE aus diesem Commit.

Änderungen, die von der anderen Seite kommen (der Commit eines Kollegen, eine Bearbeitung in Visual Studio Code), übernimmt wkl-office sync in die geöffnete Datenbank. Ein auf beiden Seiten geändertes Objekt wird nie überschrieben: Der Lauf hält an, bis Sie entscheiden, welche Seite gilt. Das Tutorial führt mit einer echten Datenbank durch diesen Zyklus; das Access-Add-In bietet dieselben Schritte auf einer Registerkarte des Menübands in Access an.

• Windows 11 mit dem vollständigen Microsoft Access, installiert und aktiviert für den Benutzer, der baut, die .NET 10 Runtime und git (oder svn.exe) im PATH. Einzelheiten: WKL Office SDK installieren.
• Builds benötigen eine interaktive Windows-Sitzung mit Access, keinen Dienst. Access läuft verborgen, jeder Schritt hat ein Zeitlimit, und ein Dialog, den Access anzeigt, wird abgebrochen und gemeldet, statt den Lauf hängen zu lassen. Das Build-Konto anzumelden und seine Sitzung aufrechtzuerhalten ist Aufgabe des Build-Systems.
• Was der Export auslässt. Werte, die Access bei jedem Speichern neu schreibt, und rechner- oder benutzerbezogene Zustände werden bewusst entfernt. Teile einer Anwendung, die das SDK nicht verarbeitet (einige Objektarten, unbekannte Tabellen-, Feld- und Datenbankeigenschaften, verknüpfte Tabellen außerhalb des Linked Tables Managers), werden ebenfalls nicht exportiert; Eigenschaften werden als Warnung gemeldet, Objektarten nicht. Prüfen Sie ein neues Projekt einmal mit wkl-office roundtrip und lesen Sie Was der Export nicht erhält.
• Das SDK verteilt die Anwendung nicht auf die Rechner der Benutzer (das übernimmt der WKL Bootstrapper) und versioniert nicht die Daten produktiver Datenbanken.

• WKL Office SDK installieren
• Tutorial: Access-Anwendung unter Versionsverwaltung stellen – von einer bestehenden ACCDB zum ersten Commit

Nur von Belang, wenn Ihre Anwendung bereits mit einem anderen Werkzeug als Text geführt wird; wkl-office migrate wandelt ein solches Projekt einmalig um, das alte Projekt wird dabei nur gelesen.

• DATEC Access SDK (msaccess-sdk), ein eigenständiges Werkzeug, das Access-Objekte ebenfalls als Text führt: Projekt des DATEC Access SDK migrieren.
• Build-Werkzeug der WKL Forms Object Library (access-app.json), der Vorgänger dieses SDK für Anwendungen, die mit der WKL Forms Object Library gebaut werden: Projekt des Build-Werkzeugs migrieren.
• Add-In WKL Extensions (WklExtensions.accda), dessen Menü die Designer der WKL Forms Object Library öffnete: Vom Add-In WKL Extensions umsteigen.

• Tägliche Arbeit: In Access Geändertes committen, Access-Add-In verwenden, In Visual Studio Code arbeiten, Quellen in eigenen Ordnern ablegen, Eine Anwendung übersetzen
• Automatisierung: Mit dotnet build bauen, Eine Anwendung testen, Befehlszeilenreferenz – alle Befehle, Optionen, Exitcodes und JSON-Felder
• Auslieferung: Anwendung aus dem SDK ausliefern, Build-Konfiguration und Auslieferungsprofil
• Formate: Projektordner, Projektdatei, Quellstruktur und Formate
• Sicherheit: Sicherheit und Pflichten des Herstellers, Pflichten als Herausgeber nach der Cyberresilienz-Verordnung
• Sprachen, Tastenkombinationen, Hinweise zu Drittanbieterkomponenten
• Problembehandlung