Final2.accdb: Wie versioniert man eine Access-Anwendung, die in einer einzigen Datei steckt?

Final.accdb, Final2.accdb, Final2_Kopie.accdb, Final2_wirklich_korrigiert.accdb. Wer eine Access-Anwendung länger als ein paar Monate betreut, kennt diesen Ordner. Er sieht nach Unordnung aus. In Wahrheit ist er eine Versionsverwaltung – die einzige, die eine einzelne Binärdatei ohne weitere Werkzeuge zulässt.

Um 2010 stellten sich viele Access-Entwickler dieselbe Frage: Wie versioniert man eine Anwendung, deren Formulare, Berichte, Abfragen und Code zusammen in einer Datei liegen? Am Anfang des Weges, der zum Office SDK geführt hat, stand genau diese Frage.

Montagmorgen, eine Fehlermeldung vom Auftraggeber: Der Rechnungsbericht rechnet die Rabatte falsch. Die erste Rückfrage lautet: seit wann? Die ehrliche Antwort wäre: Wir wissen nicht einmal genau, welcher Stand bei Ihnen läuft. Also öffnen Sie drei Kopien nebeneinander und vergleichen Eigenschaftenblätter mit dem Auge. Währenddessen hat ein Kollege in seiner Kopie ein Formular geändert. Eine der beiden Änderungen wird später von Hand übertragen, oder sie geht verloren, ohne dass es jemand merkt. Und das Release? Es ist die ACCDB, die an diesem Tag zufällig auf dem Rechner des Entwicklers lag, zur ACCDE kompiliert – samt Testformular, alter Verknüpfung und halb fertigem Modul.

Das hat wenig mit Disziplin zu tun. Eine ACCDB ist eine Datenbankdatei. Welches Objekt sich darin geändert hat, zeigt Ihnen kein Vergleichswerkzeug. Die Schwierigkeit liegt im Format, nicht bei Ihnen.

Bemerkenswert ist der Widerspruch: Viele dieser Anwendungen sorgen dafür, dass in Buchhaltung, Lager oder Fertigung jeder Vorgang nachvollziehbar ist. Woraus sie selbst bestehen, können sie nicht sagen. In mancher IT-Abteilung laufen sie deshalb unter Schatten-IT: geschäftskritisch, aber ohne Tests, ohne Dokumentation, ohne nachweisbaren Stand. Das Urteil ist hart. Ganz unberechtigt ist es nicht – nur liegt die Ursache seltener bei den Entwicklern als im Format.

Bevor es weitergeht, lohnt ein Blick auf das Wort „versionieren“. Im Access-Alltag heißt es oft: Kopien der ACCDB aufheben. In der übrigen Softwareentwicklung heißt es: jede Änderung an jedem Bestandteil einzeln festhalten, vergleichen, zusammenführen und zurücknehmen können. Zwischen diesen beiden Bedeutungen liegt der ganze Weg, um den es hier geht.

Fangen wir fair an. Für Access 2010 stellte Microsoft ein kostenloses Add-In bereit, „Microsoft Access 2010 Source Code Control“. Es verband Access über die gemeinsame Schnittstelle MSSCCI mit Visual SourceSafe oder einer anderen Quellcodeverwaltung, die diese Schnittstelle bediente. Abfragen, Formulare, Berichte, Makros und Module ließen sich einzeln ein- und auschecken. Team Foundation Server ließ sich über einen eigenen MSSCCI-Provider an Programme anbinden, die Team Explorer nicht kannten.

Was daran richtig war: Die Einheit der Versionierung war das Objekt, nicht die Datei. Und das Auschecken verhinderte, dass zwei Entwickler gleichzeitig dasselbe Formular änderten. Für kleine Teams mit einem zentralen Server war dieses Sperrmodell damals der übliche Weg. Den Gedanken, dass ein Formular eine eigene Geschichte hat, nehmen alle späteren Werkzeuge auf.

Dann kam Access 2013. In Microsofts Liste der eingestellten Funktionen steht seitdem der Satz, dass die Source Code Control des Entwicklers für Access 2013 nicht mehr als Add-In verfügbar ist. In der Spalte „Ersatz“ steht: N/A.

Wer seinen Entwicklungsablauf auf diese Integration gebaut hatte, stand beim Umstieg ohne sie da. Ein gebrochenes Versprechen im vertraglichen Sinn war das nicht – Microsoft hatte nie zugesagt, die Integration für immer zu pflegen. Es fühlte sich aber so an. Die Plattform hatte gezeigt, dass Versionsverwaltung zur Entwicklung gehört, und nahm sie dann wieder weg. Gelernt haben viele daraus vor allem eines: Den eigenen Entwicklungsprozess sollte man nicht an ein Add-In hängen, das jemand anderes abschalten kann. Wer eine Anwendung zehn Jahre und länger wartet, plant in anderen Zeiträumen als ein Office-Release.

Geblieben sind zwei Methoden, die Access schon lange kennt: SaveAsText schreibt ein Formular, einen Bericht, eine Abfrage, ein Makro oder ein Modul als Textdatei; LoadFromText lädt es zurück. Jahrelang galten sie in der Gemeinschaft als verborgen und undokumentiert. Heute hat Microsoft Learn kurze Referenzseiten dazu und nennt ausdrücklich die Versionsverwaltung als Einsatzzweck. Zu LoadFromText steht dort allerdings auch: nicht unterstützt, aber unter Entwicklern weit verbreitet.

Auf diesen beiden Methoden ist eine ganze Generation von Werkzeugen entstanden. Das bekannteste ist wohl das quelloffene msaccess-vcs-addin von Adam Waller, seit 2015 auf GitHub. Es exportiert Formulare, Berichte, Abfragen, Module, Tabellendaten und Designs als Text und baut daraus wieder eine vollständige Datenbank. Ivercy von Philipp Stiefel setzt den integrierten Weg der alten Source Code Control fort, für Access 2007 bis Microsoft 365, mit jeder MSSCCI-fähigen Quellcodeverwaltung bis hin zu Azure DevOps Server. Wer heute mit Access und Git anfängt, findet bei beiden ausgereifte Lösungen.

Mit dem Export beginnt allerdings ein zweites Missverständnis: Eine Datei versionieren ist nicht dasselbe wie ein Projekt versionieren.

• SaveAsText erfasst keine Tabellen, keine Daten, keine Verweise und keine Datenbankeigenschaften. Aus den Texten allein entsteht keine lauffähige Anwendung.
• Access schreibt bei jedem Speichern Werte neu, die mit Ihrer Änderung nichts zu tun haben. Ein Formular, das Sie nur geöffnet und gespeichert haben, erscheint im Vergleich als geändert. Wer solche Werte entfernt, muss vorher messen, welche wirklich überflüssig sind.
• Und der Text muss auch zurück: Wer in den Quellen etwas ändert, braucht eine Datenbank, die genau diese Quellen enthält.

Auf unserem eigenen Weg lagen drei Vorgänger, deren Spuren heute im SDK stecken. Das DATEC Access SDK, ein eigenständiges Werkzeug, führte Access-Objekte schon als Text, mit Befehlszeile, MSBuild, einem Add-In und der Projektdatei .acproj. Das Build-Werkzeug der Forms Object Library, ein PowerShell-Skript mit einer Beschreibung in access-app.json, baute Anwendungen dieser Bibliothek aus Textquellen. Das Add-In WklExtensions.accda öffnete in Access die Designer der Bibliothek. Wann genau welches Werkzeug entstanden ist, belegen die heutigen Repositories nicht. Wir ordnen diese Geschichte deshalb nach Problemen, nicht nach Jahreszahlen.

Das Office SDK ist eine neue Codebasis. Die Formate des DATEC Access SDK wurden übernommen, sein Code nicht. Projekte der beiden Build-Werkzeuge überführt wkl-office migrate einmalig, das alte Projekt wird dabei nur gelesen. Die Designer, die WklExtensions.accda öffnete, liegen heute im Menüband des SDK.

Was sich damit ändert, zeigt am deutlichsten ein Ordner. Vorher, eine Datei je Stand:

\\fileserver\Access\Kunden\
  Final.accdb
  Final2.accdb
  Final2_Kopie.accdb
  Final2_wirklich_korrigiert.accdb

Heute führt von diesem Ordner ein einziger Dialog des Access-Add-Ins zum Projekt. Ausgangspunkt kann die letzte Kopie sein, Final2_wirklich_korrigiert.accdb: Gehört die geöffnete Datenbank zu keinem Projekt, bietet das Projektmenü des SDK Neues Projekt aus dieser Datenbank… an. Das SDK legt den Projektordner an und exportiert die Datenbank hinein; die Datei selbst bleibt unverändert. Wer später belegen muss, wovon das Projekt ausging, hat sie also noch.

Der Schritt vom Kopienordner zum Projekt. Markierte Tabellen bringen ihre Zeilen als Startdaten in die Quellen mit; Tabellen mit den Arbeitsdaten der Benutzer, etwa Aufträgen, lassen Sie besser unmarkiert. Der Hinweis unter dem Projektordner sagt vorab, was sonst erst beim ersten Öffnen auffiele: Solange der Ausgabeordner kein vertrauenswürdiger Speicherort ist, öffnet Access die dort gebauten Datenbanken mit deaktiviertem Code.

Nachher, eine Datei je Objekt: das Projekt Kunden aus dem Tutorial nach dem ersten Export.

Kunden/
  Kunden.acproj                  Projektdatei (MSBuild-XML)
  source/
    forms/frmKunden.form.txt     ein Formular als Text
    queries/  modules/  classes/  reports/
    tables/tblLaender.table.json Tabellenschema
    data/tblLaender.jsonl        Startdaten, eine Zeile je Datensatz
    references.json
    application/properties.json
  build/                         gebaut, nicht eingecheckt
    Debug/Kunden.accdb
    Release/Kunden.accde

Jede Lücke aus der Liste oben hat hier ihren Platz: Tabellen als Schema, Startdaten als Zeilen, Verweise und Datenbankeigenschaften als eigene Dateien. Die ACCDB unter build/ ist kein Original mehr, sondern ein Ergebnis. Für den Auftraggeber heißt das: Abgenommen wird ein Stand im Repository, nicht eine Datei, die zufällig auf einem Rechner lag.

Sobald eine Anwendung aus Text besteht, kann jedes Werkzeug sie lesen, das Text versteht. git log zeigt, wann sich ein Formular geändert hat. Ein Pull Request zeigt eine Abfrage zur Durchsicht als Text. Und ein Editor zeigt Code, ohne dass Access dafür laufen muss.

Für Visual Studio Code sprach, was es bereits mitbrachte: eine Ansicht für Git, ein Terminal, Tasks und eine Liste von Problemen, in der ein Klick zur Fundstelle führt. Das SDK nutzt genau das. wkl-office new legt im Projekt die Datei .vscode/tasks.json an, mit den Tasks Build, Rebuild, Run, Run as Runtime, Check, Status, Export und Sync. Strg+Umschalt+B baut. Jeder Task ruft wkl-office mit --format msbuild auf. Jedes Problem erscheint damit als eine Zeile im Format des MSBuild-Compilers, die Visual Studio Code von sich aus lesen kann.

Echte Aufnahme: das mit wkl-office new angelegte Projekt in Visual Studio Code. Der Task Check hat die Zeile von wkl-office check --format msbuild geschrieben, die Ansicht Probleme zeigt sie an, und ein Klick öffnet die Datei an der gemeldeten Zeile.

Viele Ideen stammen nicht von uns, und das ist gut so. Die Projektdatei ist MSBuild-XML wie in Visual Studio, und dotnet build baut eine .acproj wie jedes andere Projekt. Die Build-Konfigurationen Debug und Release, die Trennung von Konfiguration und Veröffentlichungsprofil und die Eigenschaftenseiten eines Projekts kennt man aus Visual Studio. Wer mit Delphi gearbeitet hat, kennt dasselbe Muster aus dem Projektmanager: eine Projektdatei, Konfigurationen, ein Build ohne Klicken.

Was sich nicht übertragen ließ: Formulare und Berichte entwirft man in Access. Kein Texteditor ersetzt den Formularentwurf, und das SDK versucht es auch nicht. In Visual Studio Code bearbeiteter Code gelangt mit wkl-office sync in die geöffnete Datenbank. Damit gibt es zwei Seiten, die sich ändern können, und eine Regel, die nie gebrochen wird: Ein Objekt, das in Access und in den Quellen geändert wurde, wird nicht überschrieben. Der Lauf hält an, bis Sie entscheiden, welche Seite gilt.

Hier lag der nächste Fehler im Verfahren. Ein Access-Entwickler verbringt den Tag im Formularentwurf und im VBA-Editor. Muss er für jeden Export in ein anderes Programm wechseln, vergisst er ihn irgendwann. Dann steckt die Änderung wieder nur in der ACCDB, und die Quellen sind nicht mehr die Wahrheit. Ein Verfahren, das sich auf das Gedächtnis verlässt, ist kein Verfahren.

Also kamen die häufigen Schritte dorthin, wo gearbeitet wird. Das Add-In des SDK legt im Menüband die Registerkarte Office SDK an, mit den Gruppen Projekt, Quellen, Build, Herausgabe und Tools. Darunter liegt der Arbeitsbereich, ein Aufgabenbereich von Access, unten angedockt wie das Panel in Visual Studio Code. Seine Registerkarten heißen Projekt, Ausgabe, Probleme, Änderungen und Terminal.

Echte Aufnahme aus Access: Was in Visual Studio Code ein Task war, ist hier ein Befehl im Menüband – die Registerkarte Office SDK mit geöffnetem Menü Build. Darunter der Arbeitsbereich mit Ausgabe, Problemen und Änderungen.

• Änderungen zeigt jedes Objekt mit seinem Stand zwischen Access und Quelle, seinem Zustand in Git und dem nächsten Schritt. Von dort aus committen Sie; gepusht wird erst mit einem eigenen Befehl.
• Terminal startet eine Shell im Ordner des Projekts, PowerShell 7 oder, wo es fehlt, Windows PowerShell. Wer lieber tippt, muss Access dafür nicht verlassen.
• Im VBA-Editor erscheint derselbe Arbeitsbereich als Fenster. Strg+S exportiert die geänderten Objekte in die Quellen und prüft danach den Code.
• Erstellen und neu öffnen prüft zuerst und lehnt ab, solange Access eine Änderung enthält, die nicht in den Quellen ist. Gebaut wird in einem eigenen, verborgenen Access; Ihr Access bleibt bedienbar.

Die Registerkarte Änderungen: Das Modul basOne wurde in Access geändert, aber noch nicht exportiert. Die letzte Spalte sagt, was als Nächstes zu tun ist. Solange diese Zeile dasteht, baut „Erstellen und neu öffnen“ nicht.

Einen Projektmappen-Explorer im Sinne von Visual Studio gibt es nicht. Den Überblick über das Projekt geben das Projektmenü mit den zuletzt verwendeten Projekten, die Registerkarte Projekt des Arbeitsbereichs und der Dialog Projekteigenschaften, der wie die Eigenschaftenseiten in Visual Studio aufgebaut ist. Die Einzelheiten stehen in Access-Add-In verwenden.

Auch „Build“ hat zwei Bedeutungen. In vielen Access-Teams heißt es: die neueste Datei kopieren und zur ACCDE kompilieren. Im SDK heißt es: die Anwendung aus einem definierten Stand der Quellen zusammensetzen, Schritt für Schritt und jedes Mal gleich. Maßgeblich ist das Repository; ACCDB und ACCDE sind Build-Ergebnisse und werden nie committet.

Eine Build-Konfiguration legt fest, wie gebaut wird: ob eine ACCDE entsteht, in welchem Modus das Anwendungsmodell läuft und mit welchem Verbindungsprofil Tabellen verknüpft werden. Ein Auslieferungsprofil legt fest, was an wen geht. Visual Studio trennt genauso. Die Begriffsseite zeigt das am Beispiel zweier Kunden mit eigener Datenbankverbindung.

Projekteigenschaften eines echten Projekts: Die Build-Konfiguration Administration erzeugt eine ACCDE im Modus Administration. Das steht in der Projektdatei und ist damit versioniert wie der Code.

Was „reproduzierbar“ hier bedeutet, sagen wir lieber genau: Dieselben Quellen, gebaut mit derselben SDK-Version, demselben Access, denselben Verweisen und derselben Codepage, ergeben dieselben Objekte, Tabellen, Daten und Einstellungen. Bytegleich ist die Datei nicht, denn Access vergibt jedem geladenen Objekt eine neue GUID und speichert Zeitstempel.

Für ein Wartungsteam ist das die eigentliche Frage hinter jeder Fehlermeldung vom Montagmorgen: Welcher Stand läuft beim Auftraggeber, und lässt er sich wiederherstellen? Ein Wartungsvertrag sollte festlegen, auf welche Version er sich bezieht – auf die neueste oder auf die beim Kunden installierte. Beides setzt voraus, dass man die Version benennen kann.

Ist jede ausgelieferte Version einem Commit zugeordnet, etwa über ein Tag, lässt sie sich jederzeit mit denselben Objekten, Tabellen und Einstellungen neu bauen. Ein Fehler in der Version des Kunden wird dann auf dieser Version behoben, nicht auf dem Entwicklungsstand, der schon halb fertige Funktionen enthält. Haben zwei Auftraggeber unterschiedliche Stände, sind das zwei Tags, keine zwei Ordner mit Kopien. Ob beim Kunden genau die ausgelieferte Datei liegt, zeigt das Manifest der Auslieferung mit seinen SHA-256-Werten – ein neu gebauter Stand hat andere.

Drei Schritte werden oft in einen Topf geworfen:

• Bauen: wkl-office build -c Release erzeugt die ACCDE aus einem Commit.
• Auslieferung vorbereiten: wkl-office deliver stellt je Profil zusammen, was die Benutzer brauchen: Datenbank, ein Manifest mit Größe und SHA-256 jeder Datei, die Bibliotheken und den Starter. wkl-office msi baut daraus ein Installationspaket für die IT.
• Verteilen: Auf die Rechner der Benutzer bringt die Anwendung nicht das SDK, sondern der Bootstrapper. Darum geht es in einem eigenen Beitrag.

Dass sich festhalten lässt, welcher Commit zu welcher Auslieferung wurde, ist mehr als Ordnungsliebe. Hersteller von Software, die in den Anwendungsbereich der Cyberresilienz-Verordnung (EU) 2024/2847 fällt, müssen bestimmte Schwachstellen und Sicherheitsvorfälle behandeln und melden; diese Meldepflichten gelten ab dem 11. September 2026. Ob eine Access-Anwendung darunter fällt und wer dann ihr Hersteller ist, hängt vom Einzelfall ab: davon, ob sie im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird, und von der Rolle des Lieferanten. Was die Verordnung in diesem Fall verlangt, steht auf der Seite Pflichten als Herausgeber.

„Getestet“ hieß lange: Anwendung öffnen, durchklicken, nichts ist abgestürzt. Das ist besser als nichts. Aber ein Test, den niemand wiederholen kann, ist eine Beobachtung, kein Nachweis. Und niemand klickt um zwei Uhr nachts vor einem Release noch einmal alles durch.

Ein Beispiel, gebaut aus dem Testbeispiel der SDK-Dokumentation. Angenommen, jemand vereinfacht vor einem Release die Löschroutine für Bestellungen. Die Rückfrage „Bestellung löschen?“ erscheint weiterhin, aber die Antwort wird nicht mehr ausgewertet. Beim Durchklicken fällt das nicht auf: Wer klickt, antwortet mit Ja, und gelöscht wird, was gelöscht werden soll. Den Fall „Nein“ prüft beim Klicken niemand.

Ein Test, der diesen Fall festhält, antwortet auf die Rückfrage mit Nein und prüft danach, ob Bestellung 42 noch da ist. Der Lauf endet so:

OK   Orders_Total: total of two lines
FAIL Orders_DeleteAsks: order 42 kept after No :: order 42 was deleted
1 OK, 1 FAIL (2 Testprozeduren)

Exitcode 15: Eine Prüfung ist fehlgeschlagen. In einer Pipeline, die vor wkl-office deliver testet, ist der Lauf hier zu Ende, und eine Auslieferung entsteht gar nicht. Ohne diesen Test hätte es der Auftraggeber gemerkt: an einer Bestellung, die fehlt, obwohl jemand ausdrücklich Nein gesagt hat – Tage später, in der Buchhaltung. Der CI-Lauf hält außerdem fest, welcher Commit mit welchem Ergebnis getestet wurde. Für eine Abnahme ist das ein anderer Nachweis als „wir haben es durchgeklickt“.

Dahinter steht eine Umkehr der Rollen: PowerShell startet und wertet aus, VBA steuert. Die Projektdatei nennt eine Testfunktion, die die Namen der Testprozeduren zurückgibt. Eine Testprozedur ist ein öffentliches Sub in einem Standardmodul: Sie öffnet Formulare mit DoCmd.OpenForm, ruft die Befehle der Anwendung auf und prüft Ergebnisse mit WklTest.Check. Vor jedem MsgBox fragt die Anwendung WklTest.Answer. Außerhalb eines Testlaufs ist die Antwort leer, und der Dialog erscheint wie immer.

wkl-office test baut das Projekt und führt jede Testprozedur einzeln in einem verborgenen Access aus, in einer Kopie der Datenbank:

wkl-office test Orders.acproj
wkl-office test Orders.acproj -c Release -t accde --json

Exitcode 0 heißt: Alles bestanden. Neben der 15 gibt es die 13, wenn eine Prozedur das Zeitlimit überschreitet, und die 16, wenn Access während des Laufs beendet wurde. Daneben liegt ein JUnit-Bericht, den jeder gängige CI-Server liest.

Manches prüft test ausdrücklich nicht: echte Tastatur- und Mausbedienung wie Tabulatorfolge, Fokus oder Ziehen und Ablegen, und Läufe unter der Access Runtime. Und Access braucht eine angemeldete Windows-Sitzung. Ein Build-Agent, der als Dienst ohne Desktop läuft, baut nicht; wie Sie einen Build-Rechner mit Anmeldung betreiben, bleibt Aufgabe Ihres Build-Systems.

Ein Teil der Prüfung kommt sogar ohne Access aus. wkl-office check liest die Quellen, bevor Access startet. So sah das auf dem Rechner aus, auf dem dieser Beitrag entstanden ist, mit einem Versuchsprojekt Kunden und einem Modul, das ein Kennwort im Verbindungstext enthält:

> wkl-office check Kunden.acproj
error [Sources] source/modules/basDaten.bas:5: A password (PWD=) is written into the source; it is readable for everybody who reads the repository. Let the application get it at run time.
Kunden: cannot be built (1 errors).

Der Exitcode ist 2: Die Quellen sind ungültig. Ohne das Modul endet derselbe Befehl dort mit 3, weil auf diesem Rechner kein Access installiert ist. Beides sind Antworten, mit denen ein Skript etwas anfangen kann. Dass die Ausgabe englisch ist, liegt am Rechner: Eigenständig gestartet folgt die Befehlszeile der Sprache von Windows, und dieser Server läuft auf Englisch. Wie Sie Tests einrichten, beschreibt Eine Anwendung testen.

Bei „KI-Unterstützung“ denken viele an ein Werkzeug, das VBA-Code schreibt. Interessanter ist eine andere Frage: Kann ein Werkzeug in einem kontrollierten Entwicklungszyklus mitarbeiten, ohne dass jemand die Kontrolle abgibt?

• Umgesetzt: Jeder Befehl des SDK läuft auf der Befehlszeile, endet mit einem definierten Exitcode und liefert mit --json ein JSON-Objekt. Mit --format msbuild liefert er Problemzeilen mit Datei und Zeile. wkl-office commit committet, pusht aber nicht.
• Technisch machbar: Agenten wie OpenAI Codex oder Claude Code führen in einem Projektordner Befehle aus und lesen deren Ausgabe. Damit können sie check, build und test aufrufen und Exitcodes auswerten wie ein CI-Server. Eine eigene Anbindung braucht es dafür nicht; als Produktfunktion beschreibt die Dokumentation des SDK das aber nicht. Und weil Access eine Desktop-Sitzung braucht, muss ein solcher Agent dort laufen, wo Access läuft.
• Offen: Ein Agent könnte auch die Textquellen eines Formulars ändern. Ob das Ergebnis in Access richtig aussieht und sich richtig verhält, prüft weder check noch ein konfliktfreier Merge. Ein zusammengeführtes Formular muss in Access getestet werden – von einem Menschen.
• Nicht versprochen: autonome Entwicklung. Wir kündigen hier keine Agentenfunktion an.

Der sinnvolle Zyklus sieht so aus, und der letzte Schritt bleibt beim Menschen. Das Vier-Augen-Prinzip gilt auch dann, wenn eines der beiden Augenpaare ein Werkzeug ist:

Final2.accdb gibt es in einem Projekt mit dem SDK nicht mehr. Die Anwendung ist das Repository; die ACCDB ist ein Build-Ergebnis, das jeder aus einem Commit wieder erzeugen kann. Access bleibt, was es immer war: Designer, Laufzeitumgebung und Heimat des VBA-Codes.

Nicht jede Grenze ist gefallen. Builds und Tests brauchen ein installiertes Access in einer angemeldeten Sitzung. Formulare entstehen weiterhin im Designer. Ein Merge ohne Konflikte ersetzt keinen Test in Access. Unterstützt ist derzeit Windows 11 mit Access aus Microsoft 365 in 32 oder 64 Bit; Access 2016 bis 2021 nicht. Was im aktuellen Release freigegeben ist, steht offen auf der Produktseite. Den Einstieg mit einer eigenen Datenbank zeigt das Tutorial.

Access kann die Grundlage geschäftskritischer Anwendungen sein. Die Aufgabe ist nicht, es zu ersetzen, sondern einen Entwicklungsprozess darum zu bauen, der sich prüfen und wiederholen lässt.

Bleibt eine Frage, die wir lieber offen stellen als selbst beantworten: Ist es heute noch vertretbar, dass die Auslieferung einer geschäftskritischen Access-Anwendung davon abhängt, welche Datei ein Entwickler zuletzt geöffnet hatte? Und wer steht dafür ein, wenn der Auftraggeber fragt, was genau bei ihm läuft?

Es gibt gute Gründe, mit Ja zu antworten: eine Anwendung, die seit fünfzehn Jahren zuverlässig läuft, ein Entwickler, der jedes Modul kennt, kein Budget für einen Umbau. Wir sehen es anders. Schreiben Sie uns, wenn Sie widersprechen – dann erst recht.

Wird Ihre Access-Anwendung heute als Datei weitergegeben, und lässt sich die Frage „Welcher Stand läuft beim Kunden?“ nicht mit einem Commit beantworten? Dann ist der erste Schritt ein Gespräch über eine Ihrer Anwendungen: wie sie heute entsteht, geprüft und ausgeliefert wird, und ob der Weg über Quellen und Build zu ihr passt. Zum Einsatz des Office SDK verpflichtet das nicht.

Office SDK: Stand, Voraussetzungen und Gesprächstermin