Office SDK · für Entwickler von Access-Anwendungen
Access-Anwendungen in Git führen und aus Quellen bauen
Jedes Formular, jede Abfrage, jedes Modul als Textdatei. Die ACCDE entsteht aus einem Commit – nicht aus der Kopie, die zuletzt gespeichert wurde.
Entworfen wird weiter in Access. Das SDK überträgt die Anwendung zwischen Access und den Textquellen und baut daraus die Datenbank – auf der Befehlszeile, im Menüband von Access oder in der Build-Pipeline.
- Entwurf in Access
- Textquellen in Git
- ACCDE aus einem Commit
Sie entwerfen in Access, das SDK schreibt die Änderungen in die Quellen. Gebaut wird aus einem festgelegten Stand dieser Quellen.
Ausgangslage
Eine Access-Anwendung ist eine Datei. Das reicht, bis vier Fragen kommen.
Formulare, Berichte, Abfragen, Code, Tabellen und Einstellungen stecken in einer einzigen Binärdatei. Solange ein Entwickler an einer Kopie arbeitet, genügt das. Mit dem zweiten Entwickler, dem ersten Fehler in Produktion oder der ersten Frage der Revision nicht mehr.
- Was hat sich geändert? Zwei Kopien einer ACCDB lassen sich nicht zeilenweise vergleichen. Um herauszufinden, was die Anwendung beschädigt hat, öffnen Sie alte Kopien nebeneinander.
- 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 bekommen die Anwender? Das Release ist die eigene ACCDB des Entwicklers, zur ACCDE kompiliert mit allem, was sie an diesem Tag enthielt: Testformulare, eine alte Verknüpfung, ein unfertiges Modul.
- Lässt es sich automatisch prüfen? Ob die Anwendung vollständig ist und sich kompilieren lässt, kann kein Skript feststellen – nur das Öffnen in Access zeigt es.
Und SaveAsText oder ein Add-in?
Access schreibt einzelne Objekte als Text – die ganze Anwendung nicht
Viele Teams exportieren ihre Objekte heute schon mit SaveAsText und lesen sie mit LoadFromText wieder ein. Für Formulare, Berichte und Module funktioniert das. Microsoft dokumentiert diese Methoden aber nicht, und Tabellen, Daten, Verweise und Datenbankeigenschaften lassen sie aus: Eine vollständige Anwendung lässt sich allein daraus nicht wieder aufbauen.
Viele Teams gehen mit dem quelloffenen msaccess-vcs-addin einen Schritt weiter: Es exportiert Formulare, Abfragen, Module und mehr aus dem Menüband von Access und baut eine Datenbank aus den Quellen wieder auf. Für einen einzelnen Entwickler reicht das oft. Das SDK ergänzt, was ein Team und eine Build-Pipeline darüber hinaus brauchen: eine Befehlszeile und MSBuild-Anbindung mit festen Exitcodes, eine Prüfung, bevor Access startet, und einen Abgleich, der anhält statt zu überschreiben, wenn ein Objekt auf beiden Seiten geändert wurde.
Das SDK führt die ganze Anwendung als Quellen, einschließlich Tabellenschema, Startdaten, Verweisen und Eigenschaften. Führen Sie Ihre Anwendung schon mit einem anderen Werkzeug als Text – dem DATEC Access SDK, dem Build-Werkzeug der Forms Object Library oder dem Add-in Extensions –, wandelt wkl-office migrate das Projekt einmalig um; das alte Projekt wird dabei nur gelesen. Umstieg von einem anderen Werkzeug
Mit dem SDK
Die Anwendung als Text: lesbar, zusammenführbar, baubar
Die vier Antworten bauen aufeinander auf. Ist die Anwendung Text, lassen sich ihre Änderungen lesen; dann können mehrere daran arbeiten; sind die Quellen vollständig, lässt sich die Datenbank daraus bauen; und ist ein Build ein Befehl, läuft er ohne Zutun.
Maßgeblich ist das Repository. ACCDB und ACCDE sind Build-Ergebnisse und werden nie eingecheckt.
Kunden/ Kunden.acproj source/ forms/frmKunden.form.txt queries/ modules/ classes/ reports/ tables/tblLaender.table.json data/tblLaender.jsonl references.json application/properties.json build/ gebaut, nicht eingecheckt Debug/Kunden.accdb Release/Kunden.accde
- Was hat sich geändert?
git logzeigt, wann,wkl-office diffzeigt die Zeilen, undwkl-office changeslistet alles, was sich zwischen geöffneter Datenbank, Quellen und letztem Commit unterscheidet. - Wer arbeitet daran? Jeder committet Textquellen; git führt sie zusammen und zeigt Konflikte je Datei. Ein Merge ohne Konflikte ist inhaltlich nicht geprüft – bauen Sie das Ergebnis und testen Sie zusammengeführte Formulare in Access. Pull Requests zeigen Formulare, Abfragen und Module als Text.
- Was bekommen die Anwender?
wkl-office build -c Releasebaut die ACCDE aus den committeten Quellen. Dieselben Quellen mit demselben Access, denselben Verweisen und derselben Codepage ergeben dieselben Objekte, Tabellen, Daten und Einstellungen; die Datei selbst ist nicht bytegleich. - Automatisch prüfbar.
wkl-office checkfindet ungültige Quellen, fehlende Verweise oder ODBC-Treiber, eine falsche Bitbreite und Kennwörter in den Quellen, bevor Access startet.
Ein Entwicklungszyklus
Access bleibt der Designer: Das SDK steuert das installierte Access und ersetzt weder den Formular- noch den Berichtsentwurf.
-
Die Arbeitsdatenbank bauen
Allein aus den Quellen, nach
build/Debug/Kunden.accdb.wkl-office build Kunden.acproj -
In Access ändern
Ein Formular entwerfen, ein Modul bearbeiten, speichern – wie gewohnt.
-
Sehen, was sich geändert hat
Die geänderten Objekte mit dem nächsten Schritt für jedes, dazu die Zeilen eines Formulars.
wkl-office changes Kunden.acprojwkl-office diff Kunden.acproj form:frmKunden
-
Committen
Prüft erneut, exportiert die geänderten Objekte in die Quellen und committet sie. Gepusht wird erst mit
wkl-office push.wkl-office commit Kunden.acproj -m "Kundenformular: neues Feld für die USt-IdNr." -
Freigeben
Auf jedem Rechner mit demselben Access und denselben Verweisen entsteht die ACCDE aus genau diesem Commit.
wkl-office build Kunden.acproj -c Release
Änderungen von der anderen Seite – der Commit eines Kollegen, eine Bearbeitung in Visual Studio Code – bringt 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.
wkl-office test – zwei Prüfprozeduren, beide bestanden. Eine Anwendung testenPasst zu den Werkzeugen, die Sie schon nutzen
- In Access – dieselben Schritte auf einer Registerkarte des Access-Add-ins im Menüband.
- In Visual Studio Code – dort bearbeitete Quellen holt
wkl-office syncin die geöffnete Datenbank zurück. - In der Build-Pipeline –
dotnet buildführt denselben Build über MSBuild aus; jeder Befehl liefert einen festgelegten Exit-Code und mit--jsonein JSON-Objekt. - Mit Git oder Subversion – Subversion funktioniert über
svn.exe, ist aber noch nicht in einem Abnahmelauf nachgewiesen.
Stand und Grenzen
Passt das SDK zu Ihrem Projekt?
In Entwicklung
Es passt, wenn Sie mit Windows 11 und Microsoft Access aus Microsoft 365 entwickeln, in 32 oder 64 Bit, und Ihre Quellen in Git oder Subversion führen wollen. Prüfen Sie vorher diese Punkte:
- Access 2016 bis 2021, Windows 10 oder nur die Access Runtime: Diese Umgebungen unterstützt das aktuelle Release nicht.
- Gebaut wird in einer angemeldeten Windows-Sitzung mit Access, nicht in einem Dienst. Das Build-Konto anzumelden und seine Sitzung zu halten, ist Aufgabe des Build-Systems.
- Prüfen, was der Export auslässt: Teile, die das SDK nicht verarbeitet, werden nicht exportiert. Führen Sie bei einem neuen Projekt einmal
wkl-office roundtripaus. - Gebaut, nicht verteilt: Auf die Rechner der Anwender bringt die Anwendung der Bootstrapper. Die Daten produktiver Datenbanken versioniert das SDK nicht.
Hier beginnen
- SDK installierenEin Ordner, kein Setup: Windows 11 mit dem vollständigen Microsoft Access, die .NET-10-Runtime und Git im Suchpfad.
- TutorialVon einer vorhandenen ACCDB bis zum ersten Commit, mit einer echten Datenbank.
- AnleitungenAus Access committen, das Add-in nutzen, in Visual Studio Code arbeiten, mit dotnet build bauen, testen, übersetzen.
- BefehlsreferenzJeder Befehl, jede Option, jeder Exit-Code und jedes JSON-Feld.
- FehlerbehebungEin Dialog in Access, ungespeicherte Arbeit, ein Roundtrip mit Unterschieden und mehr.
- Quellstruktur und FormateWo jeder Teil einer Access-Anwendung in den Quellen liegt und in welchem Format.
Sie wollen wissen, was das SDK umfasst und was Ihr Entwicklungsrechner dafür mitbringen muss? Funktionen, Voraussetzungen und Grenzen stehen auf der Produktseite.
Zur Produktseite