Idee für ein „Access-Make“

Flattr this!

Zahnräder (Symbolbild)

Vielleicht kennt der eine oder andere von euch das Tool make. Damit lässt sich recht einfach ein Build-Prozess für eine Software aufsetzen, ohne Server und mit mäßigem Aufwand. Man muss natürlich die Syntax kennenlernen. Make bekommt über ein sog. „Makefile“ Informationen über die Abhängigkeiten der einzelnen Dateien voneinander, und mit welchen Befehlen sie bei Bedarf erzeugt werden. So lassen sich z.B. aus allen *.c- mittels des Compilers die jeweiligen *.o-Dateien erzeugen. Gut, ich gebe zu, das Beispiel ist etwas älter und vor allem für Access-Entwickler nicht relevant. Aber das Grundprinzip kann auch für uns nützlich sein.

Einige von uns beschäftigen sich ja mit automatisierten Testverfahren, sogar in Access! Falls es sich nicht nur um Unit-Tests, sondern sogar um GUI- oder Integrations-Tests handelt, ist es notwendig, dass die Applikation in einer „ausführbaren“ Form vorliegt. Damit meine ich nicht das alte Problem, wie man aus einer Access-Datenbank eine EXE-Datei macht 🙂

Es geht einfach darum, die verschiedenen Aktionen, die ich vor dem Deployment machen muss, zu automatisieren. Und wenigstens für die Bereitstellung der Testversion für interessierte Anwender hilft mir das, mich auf das Wesentliche zu konzentrieren: Die Entwicklung. Wenn ich dann noch ein Continuous-Integration-System wie z.B. Jenkins oder Bitbuckets „Pipelines“ (leider nicht für Windows) zur Verfügung habe, spare ich eine Menge Zeit.

Was ich mit make alles machen kann ist zwar schon sehr schön, aber die Grenze des Erreichbaren ist dabei die Kommandozeile. Gerade bei Access ist dabei die Frage wichtig, ob ich wirklich alles mit von der Kommandozeile erreichbaren Tools machen kann.

Abläufe

Was für Access-Entwickler also interessant sein könnte, wären zum Beispiel folgende immer wiederkehrende Aktionen:

  1. Lösche aus der Backend-Datei alle Datensätze, die dort nur testweise eingegeben wurden
  2. Mache aus .accdb-Dateien jeweils eine .accde
  3. Ziehe aus der Quellcodeverwaltung die Änderungen seit dem letzten Build heraus und schreibe sie in eine Datei
  4. Packe alle für das Projekt notwendigen Dateien mittels eines Setup-Scripts zusammen und verwende die vorgenannte Datei als „Recent Changes“-Eintrag
  5. Übertrage die fertige setup.exe an eine Stelle, wo die User sie abholen können

Vielleicht brauche ich nicht in jedem Projekt alles davon, vielleicht auch mal ein bisschen mehr, daher muss eine gewisse Flexibilität gegeben sein. Make kann zwar einiges davon, aber ein paar Sachen müssen wir wahrscheinlich doch von Access erledigen lassen.

Die Löschbefehle unter Punkt 1 könnten z.B. einfach eine Reihe von SQL-Anweisungen sein. Diese ließen sich aus einer Textdatei auslesen, pro Zeile ein Befehl. Nummer 2 ist schon schwieriger, denn SysCmd 603, source, target muss schon unter VBA und in Access ausgeführt werden. Dagegen sind die weiteren Punkte leicht über die Kommandozeile ausführbar.

Also wird Access vermutlich die Nummern 1 und 2 erledigen. Die Frage stellt sich, ob es nicht auch das andere tun kann?

Was nun?

Nun stelle ich mir die Frage, was ich tue. Soll ich eine Kombination aus Make und Access nehmen? Oder reicht ein simples .cmd-File und eine Access-ACCDB nur für den SysCmd-Befehl? Oder gibt es vielleicht schon etwas fertiges dafür und ich kann mir die Mühe sparen?

Was meint ihr?

Update

Nach dem Tipp von Marcus mit Gradle habe ich nochmal ein wenig recherchiert. Meine obige Aussage, dass der SysCmd-Befehl unbedingt innerhalb von Access ablaufen muss, muss ich revidieren. Korrekt ist, dass er nur innerhalb des Access-Objektes zur Verfügung steht. Darauf kann ich jedoch auch mittels CreateObject("Access.Application") in einem VBScript-File zugreifen, so dass Access als ausführender Container nicht unbedingt notwendig ist. Das eröffnet natürlich weitere Möglichkeiten, wie z.B. auch die Nutzung einer Dotnet-Applikation, oder auch Python.

Ich habe das mal in meinem Bitbucket-Repository begonnen, falls jemand mitspielen möchte 🙂

Ähnliche Artikel:

AuthorChristoph Jüngling

Selbständiger Softwareentwickler und Seminarleiter

7 thoughts on “Idee für ein „Access-Make“

  1. Pingback:

  2. Kurzfassung:
    Wenn wir ein fertiges Build haben, arbeitet jeder Entwickler damit. Gibt es Änderung, ruft er ein(!) spezielles Formular auf, welches das betroffene Accessobjekt als Textdatei in einem „Repository“ speichert. Gleichzeitig wird ein Änderungsprotokoll fortgeschrieben. Steht ein neues Build an, nimmt ein so genanntes Deploytool eine vorgefertigte Vorlagendatenbank (Verweise, vbWatchdog, lokale Tabellen usw.) und packt dort alle benötigten Accessobjekte wieder hinein. Alles funktioniert mit SaveAsText / LoadFromText.
    Das Erstellen der ACCDE ist simpler Vorgang.
    Die Bereitstellung für die Clients ist absichtlich nicht automatisiert, das erfolgt erst nach dem üblichen Testen des neuen Builds 😉

    Das Verfahren hat aus unserer Sicht den Vorteil, dass alles Nötige bei Access dabei ist. Zusätze, wie WinMerge oder Git, sind trotzdem jederzeit möglich.

    • Danke für die Einsichten, Hannes! Soweit ich das sehe, arbeiten wir gar nicht so verschieden. Der erste Teil besteht bei mir aus OASIS, das „SaveAsText“ u.a. automatisiert, und Git („Änderungsprotokoll“). Das „Deploytool“ versuche ich gerade zu erstellen, und über die Auslieferung an den Kunden kann man durchaus nochmal nachdenken.

  3. Da ich meist mit Bitbucket arbeite, werde ich mal schauen, ob es dort eine Möglichkeit gibt. Ich kenne es von Jenkins, da gibt es einen Client, der die Arbeit vor Ort erledigt (bzw. veranlasst). Dann bliebe für Access-Make nur noch das übrig, was sich nicht außerhalb machen lässt.

  4. Schau dir mal Gradle an, dort könntest du die nicht unterstützten Sachen als Plugin einzuprogrammieren. Gradle wird von allen mir bekannten CI-Servern unterstützt und hat noch einen riesigen Vorteil: Liegt der Gradle Wrapper im Projekt, muss der Entwickler kein Gradle installiert haben und kann trotzdem Gradle nutzen…

Kommentar verfassen