MSAccess-VCS-Integration

Letzte Änderung am 19. Februar 2023 by Christoph Jüngling

Manche Dinge brauchen etwas Zeit, Projekte ebenso wie Antworten auf gestellte Fragen. Aber manchmal lohnt sich das Warten. Hier ist eine Antwort zu einer (für mich) längst nicht mehr relevanten Frage, da das ursprüngliche Problem aufgrund des von mir verwendeten Tools inzwischen nicht mehr auftritt. Ich will euch die hilfreiche Antwort dennoch nicht vorenthalten.

Wie einige von euch sicher bemerkt haben, arbeite ich seit längerem mit Quellcodeverwaltung. Eigentlich führe ich kein einziges Projekt mehr ohne diese durch, selbst wenn es auch nur ein kleines ist. Ein Argument wie das eines Kollegen, “Wir machen keine Quellcodeverwaltung. Das ist nur was für große Projekte.” kann ich daher leider nur belächeln.

Es war im Sommer 2011, dass ich meine Anfrage auf Stack Overflow eingereicht habe. Es ging damals um die Frage, wie ich Mercurial (Hg) beibringen kann, die von Access per SaveAsText exportierten Dateien trotz UTF-16-Codierung nicht als Binärdateien zu betrachten. Soweit ich mich erinnere, war das nicht immer so. Offenbar hatte Microsoft in Access 2007 die interne Funktion zum Exportieren der Access-Objekte dahingehend verändert, dass seitdem eine andere Codierung benutzt wurde.

Da Mercurial Dateien, die ein Null-Byte (ASCII 0x00) enthalten, als Binärdateien betrachtet, verhält sich auch TortoiseHg unterschiedlich. Dazu gehört die direkte Anzeige der Änderungen von einem Changeset zu einem anderen:

Mercurial: Zeige Unterschiede in der Workbench

Mercurial: Zeige Unterschiede in der Workbench

Ich habe es gerade eben in Access 2016 getestet. Dort werden Module nach wie vor in ANSI-Codierung exportiert, und zwar sowohl bei direkter Ausführung von SaveAsText, als auch bei dem Export via OASIS, dem von mir favorisierten Tool für diesen Zweck. Leider ist das bei Formularen nicht so. Hier zeigt Notepad++ die Codierung “UCS-2 LE BOM” an, wenn die Datei mittels SaveAsText erzeugt wurde. Mercurial und Git betrachten dieses Format als “binary”:

Bei OASIS ist das übrigens etwas anders gelöst. Dieses Tool verwendet teilweise ein eigenes Format für den Export der Access-Objekte, wodurch einige hausgemachte Probleme von Microsoft gar nicht erst auftreten. In Version 3.4.16.724 exportiert OASIS ein Formular im Format UTF-8, womit Hg und Git keine Probleme haben. Die sehr hilfreiche Option, Formular- und Berichtsdateien zu splitten, führt zu zwei Dateien (Code und Layout), die beide UTF-8-codiert sind. Das ursprünglich beobachtete Problem tritt hier also gar nicht auf.

Nun aber zu dem hilfreichen Tipp: Die gestrige Antwort von Christian Specht auf Stack Overflow weist auf ein Projekt namens msaccess-vcs-integration auf Github (Microsoft) hin, das ebenfalls die Codierung in einen Zustand versetzt, so dass Mercurial und andere Quellcodeverwaltungen diese sinnvoll verwalten können. Wenn ich die Projektbeschreibung richtig deute, erfordert die Verwendung dieses Tools noch einiges an Handarbeit, was die Integration in Access betrifft. Das könnte durch die dort verlinkte Add-In-Version um einiges einfacher sein. Ich habe beide Produkte nicht getestet, aber vielleicht tue ich das eines Tages mal.

Update Februar 2023: Leider muss ich feststellen, dass der letzte Commit in diesem Projekt im Oktober 2020 erfolgt ist. Ein Fork wird jedoch vom User joyfullservice (oben als “Addin-Version” bezeichnet) weitergeführt und ist recht aktuell.

Ähnliche Artikel:

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

achtzehn − 1 =