Access-Applikation mit Runtime installieren

Christoph Jüngling, https://www.juengling-edv.de

Office-Dokumente wie Word- oder Excel-Dateien lassen sich mittlerweile auf fast allen Geräten lesen. Wenn das nicht möglich ist, kann man diese oft in die jeweils vorhandene Textverarbeitung oder Tabellenkalkulation importieren. Bei Datenbankanwendungen ist das anders: Dass der Entwickler eine Vollversion von Microsoft Access auf dem Rechner hat, ist Voraussetzung. Aber was ist, wenn wir eine Datenbankanwendung in einem Unternehmen an viele Arbeitsplätze verteilen oder diese online an Kunden verkaufen wollen? Muss in dem Fall für alle User ebenfalls eine Vollversion von Access beschafft werden? Glücklicherweise lautet die Antwort nein. Es gibt eine kostenlose Runtime-Version von Access, die das Nötigste für den Betrieb von Access-Anwendungen mit sich bringt. Der vorliegende Artikel zeigt, welche Vorbereitungen dafür in unserer Applikation erforderlich sind und wie man die Runtime in ein eigenes Setup integriert.

Microsoft Access ist ein tolles Produkt, aber es hat – global gesehen – leider einen entscheidenden Nachteil: Es kostet Geld. Na gut, das kann man verstehen, wir alle müssen ja Miete zahlen, und das geht nicht vom guten Willen (will heißen “Spenden”) allein. Doch glücklicherweise gibt es für einige von uns eine Möglichkeit, wenigstens diese Kosten zu vermeiden – und dabei rede ich natürlich nicht von “Hacks”, nein, das geht ganz legal!

Historisches

Wegen der anfallenden Lizenzkosten kann man nicht grundsätzlich davon ausgehen, dass Access beim User schon installiert ist. Je nach aktueller Lizenzpolitik seitens Microsoft gibt es vielleicht eine Sparversion von Office, die Access außen vor lässt und dafür günstiger ist. Oder die IT-Administration hat entschieden, dass ohnehin niemand Access braucht, weil Excel ja genauso gut ist und auch “Datenbank kann”.

Was auch immer nun der Grund dafür ist, Access nicht zu installieren, für uns Entwickler stellt sich die Frage, wie wir damit umgehen. Immerhin stellt Microsoft schon seit längerem eine “Access-Runtime-Version” bereit. In der Vergangenheit musste der Entwickler diese gelegentlich bezahlen, damit er sie dann kostenfrei an seine Anwender weitergeben konnte. Seit längerem jedoch ist die Runtime kostenlos herunterladbar. Dies verursacht dem Entwickler also keine Zusatzkosten mehr, und vor allem dürfen wir diese Runtime auch überall kostenfrei installieren.

Auch in Hinsicht dessen, was man als Entwickler darf, scheinen sich die Ansichten bei Microsoft etwas gelockert zu haben. Ich erinnere mich noch an meine früheren Recherchen darüber, nach denen ich die Runtime meinen Kunden nicht hätte bereitstellen dürfen; sie mussten sie sich damals selbst herunterladen (einschließlich der Registrierung). Dazu habe ich aktuell nichts mehr auf der Microsoft-Website gefunden. Selbstverständlich soll dies keine Rechtsberatung darstellen.

Das Problem: Die Kosten

Wie wir alle wissen, ist Microsoft Access eine lizenzpflichtige Software. Das bedeutet, dass jeder, der sie nutzen will, dafür einen gewissen Betrag investieren muss. Das schließt auch alle Anwender mit ein, und das kann für ein kleines Unternehmen ganz schön ins Geld gehen! Natürlich gibt es verschiedene Möglichkeiten, diese Kosten in Grenzen zu halten, zum Beispiel das Action Pack (https://partner.microsoft.com/de-de/membership/action-pack) oder Volumenlizenzen, aber darum soll es hier nicht gehen.

Das mit den Kosten ist übrigens auch dann der Fall, wenn die Anwender eine individuell entwickelte Access-Applikation benutzen, die ja bereits mit einer lizenzierten Access-Version erstellt wurde! Klingt vielleicht unfair, ist aber so, daran können wir nichts ändern. Oder doch?

Die Lösung: Runtime-Version verwenden

Die Erklärung ist einfach: Diese als .accdb, .accde oder .accdr bei den Anwendern installierte (oder einfach aufgespielte) Applikation ist ohne weitere Hilfe leider nicht lauffähig. Wir können mit Access keine eigenständigen Programme schreiben, denn es gibt keinen Compiler/Linker wie beispielsweise bei den Programmiersprachen C++ oder VB.Net.

Es entsteht also keine .exe-Datei. Stattdessen muss Access immer mit im Boot sein, es interpretiert die Datenbankdatei und führt die darin beschriebenen Aktionen aus.

Wenn wir allerdings die Runtime-Version von Access nutzen, wird kein Access mehr benötigt, um die Applikation laufen zu lassen. Allerdings gibt es dabei noch ein paar Einschränkungen, die wir uns genauer anschauen müssen.

Unterschiede zur Vollversion

Natürlich gibt es Unterschiede zwischen Runtime und Vollversion, sonst würde ja niemand mehr die Lizenz von Access kaufen, sondern immer gleich zur kostenlosen Runtime-Version greifen. Der wichtigste Unterschied ist der, dass man mit der Runtime eine Datenbank zwar benutzen, aber nicht entwickeln kann. Entwickeln soll hier stellvertretend für alles stehen, was ein Entwickler so macht, unter anderem also Formulare, Berichte und andere Datenbankobjekte bearbeiten und den Navigationsbereich anzeigen und nutzen. Das alles geht in der Runtime nicht mehr, dafür braucht man die Vollversion von Access.

Ein echtes Problem ist das sicher nicht, denn genau dies alles wird der reine Anwender in aller Regel sowieso nicht machen. Und mal ehrlich: Als Entwickler würden wir es sogar begrüßen, wenn der Anwender das alles auch gar nicht kann.

Nur der Vollständigkeit halber sei noch gesagt, dass die Bearbeitung der Daten auch mit der Runtime natürlich ohne Probleme funktioniert!

Vorüberlegungen

Bevor man eine Access-Applikation für die Runtime-Version freigibt, sollten also einige Überlegungen angestellt werden. Wir benötigen sinnvollerweise:

• Frontend-/Backend-Trennung,
• ein eigenes Ribbon,
• einen Mechanismus zum automatischen Start aller benötigten Formulare etc.,
• 32-Bit oder 64-Bit,
• ein Setup
• und wir sollten unser Setup testen.

Frontend-/Backend-Trennung

Die Frontend-/Backend-Trennung und alle damit verbundenen Aktionen (zum Beispiel automatische Tabelleneinbindung) ist generell sinnvoll. Der wichtigste Grund ist, dass damit die Applikation einfach durch einen Austausch der Datei aktualisiert werden kann (mit oder ohne Setup), ohne die bereits eingegebenen Daten zu verlieren.

Eine mögliche Vorgehensweise dazu ist denkbar einfach:

• Im ersten Schritt duplizieren wir mit Hilfe des Windows-Explorers die Datenbankdatei (Copy/Paste).
• In einer der beiden Dateien löschen wir nun alle Tabellen. Diese Datei nennen wir Frontend.
• In der anderen Datei löschen wir alles außer den Tabellen. Diese Datei nennen wir Backend.
• Nun verknüpfen wir die Tabellen aus dem Backend in das Frontend (Externe Daten|Neue Datenquelle|Aus Datenbank|Access).

Weitergehende Informationen finden Sie im Beitrag Setup für Access-Anwendungen (www.access-im-unternehmen.de/1316) unter Exkurs: Frontend-/Backend-Trennung.

Ribbon

Da das Access-eigene Ribbon in der Runtime-Umgebung nicht angezeigt wird, müssen wir als Entwickler ein eigenes vorbereiten. Hierzu gibt es bereits zahlreiche Artikel zu Ribbons. Die Alternative besteht darin, dass wir gar nicht mit Ribbons arbeiten, sondern alle Funktionen der Anwendung aus einem beim Anwendungsstart geöffneten Formular (nicht datengebunden) heraus starten.

Dieses Ribbon sollte mindestens die Icons beinhalten, die der Anwender während der üblichen Arbeiten benötigt, zum Beispiel die Gruppen Zwischenablage, Sortieren und Filtern, Datensätze und Suchen. Der Vorteil bei Verwendung der eingebauten Bestandteile ist, dass sie auch ihre Automatik (aktiv/inaktiv je nach Kontext) mitbringen.

In Bild 1 sehen Sie ein Beispiel dafür. Natürlich sind Sie in Ihrer eigenen Applikation frei in der Gestaltung dieses Ribbons. Wenn Sie jedoch keines vorbereiten, wird in der Runtime auch keines enthalten sein.

Bild 1: Wichtige Befehle des Ribbons

Automatischer Start

Der automatische Start aller benötigten Objekte (zum Beispiel Ribbon, Formulare et cetera) muss berücksichtigt werden, da der Navigationsbereich nicht zugänglich ist, wenn die Applikation in der Runtime-Umgebung läuft. Wir brauchen also entweder ein Autoexec-Makro, ein Startformular mit Code für das Form_Open-Ereignis, oder wir nutzen den in dem Artikel Code beim Öffnen der Anwendung: Ribbon (www.access-im-unternehmen.de/1369) beschriebenen Trick.

Der Start des Ribbons erfolgt durch Access automatisch, wenn wir dieses in der Datenbank korrekt eingetragen haben. Dazu muss die Tabelle USysRibbons mit der vorgegebenen Struktur angelegt und mit der Beschreibung der Ribbon-Definition gefüllt sein. Außerdem muss im Menüpunkt Datei|Optionen|Aktuelle Datenbank|Menüband- und Symbolleistenoptionen|Name des Menübands der Name des initial zu ladenden Ribbons eingetragen sein. Wie das genau geht, ist in den im vorigen Abschnitt verlinkten Artikeln bereits beschrieben.

Wenn Sie ein Programm wie zum Beispiel den Ribbon-Admin 2016 (https://shop.minhorst.com/access-tools/309/ribbon-admin-2016?c=78) zur Erstellung eines Ribbons verwenden, wird alles Benötigte bereits von diesem erledigt.

Der Start der weiteren Objekte unterscheidet sich in der Runtime-Version nicht von dem, was Sie wahrscheinlich auch in der .accdb/.accde-Datei längst tun.

Bitbreite

Mit “Bitbreite” ist selbstverständlich nicht im wörtlichen Sinne die Breite eines Bits gemeint. Näheres dazu gibt es in der Wikipedia. Es geht konkret um die Frage 32-Bit oder 64-Bit, und zwar im Hinblick auf Access, nicht Windows. Wir müssen im Code einiges vorbereiten, wenn unsere Access-Applikation in beiden Welten lauffähig sein soll. Dieses Thema ist in dem Artikel VBA unter Access mit 64 Bit (www.access-im-unternehmen.de/961) ausführlich besprochen worden.

Allerdings gibt es im Hinblick auf unsere Installation einen Fallstrick: Die .accdb-Datei mag nach sorgfältigen Vorbereitungen unter beiden Bitbreiten laufen, jedoch stimmt das für die kompilierte .accde-Datei nicht: Diese muss für 32-Bit und 64-Bit in der jeweiligen Access-Variante erzeugt werden, was unseren Buildprozess ein wenig komplizierter macht. Das ist allerdings nicht neu, sondern schon seit einem Vierteljahrhundert so.

Setup

Damit sind wir gedanklich beim Setup angekommen. Es erleichtert dem Anwender, die Applikation zu installieren, andernfalls müsste er sich um das Aufspielen an die richtige Stelle, die Verknüpfung mit Startmenü und Desktop-Icon und vielleicht noch einiges mehr selbst kümmern. Bei der späteren Deinstallation wiederum müsste er ebenfalls an all dies denken. Wenn der Benutzer das nicht aus eigener Kraft schafft, müsste jedes Mal ein Administrator aktiv werden.

Durch ein Setup bekommen auch unerfahrene Anwender schnell einen lauffähigen Zustand. Sinnvollerweise schließen wir die Installation der Runtime-Version von Access gleich mit ein, sofern diese benötigt wird.

Es gibt noch eine Reihe anderer Vorteile und Möglichkeiten, die wir in den Beiträgen Setup für Access-Anwendungen (www.access-im-unternehmen.de/1316), Setup für Access: Umsetzung mit InnoSetup (www.access-im-unternehmen.de/1326), Setup für Access: Vertrauenswürdige Speicherorte (www.access-im-unternehmen.de/1333) und Setup für Access-Applikationen, Restarbeiten (www.access-im-unternehmen.de/1355) ausführlich besprochen haben. Im Rahmen dieses Artikels soll nur darauf eingegangen werden, wie man die Runtime-Version in unser Setup integriert.

Test

Für den Test unseres Setups ist es erforderlich, dass wir einen zweiten Rechner haben, egal ob nun physisch oder als virtuelle Maschine. Denn eine Parallelinstallation von Vollversion und Runtime auf einem einzigen Rechner ist problematisch.

Eine Windows-Installation in einer virtuellen Maschine (zum Beispiel Microsoft Virtual PC, VMWare Workstation oder Oracle VirtualBox) bietet sich hierbei an, da mittels eines Snapshots der Grundzustand sehr einfach gesichert und danach jederzeit wiederhergestellt werden kann.

Wenn wir dann auch noch 32-Bit und 64-Bit unterstützen wollen, brauchen wir mehrere virtuelle Maschinen. Beachten Sie dabei, dass Sie die erforderliche Anzahl Lizenzen besitzen. Ich denke aber, das oben verlinkte Actionpack ist schon eine gute Grundlage dafür.

Zu testen wäre in erster Linie, ob

• die Runtime immer installiert wird, wenn sie gebraucht wird.
• die Runtime nicht installiert wird, wenn diese oder die Vollversion bereits installiert sind.
• die Applikation mit der richtigen Bitbreite installiert wird (falls wir diese Unterscheidung machen).

Das bedeutet, dass die folgenden VMs vorhanden sein sollten:

• Mit Access, 32 Bit
• Mit Access-Runtime, 32 Bit
• Mit Access, 64 Bit
• Mit Access-Runtime, 64 Bit
• Ohne Access oder Runtime

Wie installiere ich die Access-Runtime?

Immer wenn ich die Aufgabe bekomme, einen Prozess zu automatisieren, frage ich mich zunächst, wie ich die Aufgabe von Hand lösen würde. In der Regel ergeben sich daraus bereits die Grundzüge für die Automatisierung, die ich dann berücksichtigen kann. Selbst wenn danach keine weiteren Optimierungen mehr stattfinden, ist durch die Automatisierung schon viel gewonnen.

Im Falle der Access-Runtime ist natürlich der erste Schritt, die Installationsdatei zu finden und herunterzuladen. Wie erwartet finden wir diese bei Microsoft.

Schauen wir aber zunächst auf die dortige Website, um die Installationsvoraussetzungen zu klären. Dort steht:

Mit Microsoft 365 Access Runtime können Sie Access 365-Anwendungen an Benutzer verteilen, die nicht die Vollversion von Microsoft 365 Access auf ihren Computern installiert haben (wie dies bei Office 365 Enterprise E1 und Microsoft 365 Business Basic der Fall ist). Sie können es auch in Office 2019 verwenden.

Wichtig: Die Microsoft 365 Access Runtime ist nicht kompatibel mit Office, die mit Windows Installer installiert wurden.

Das ist übrigens der Grund für die zuvor getroffene Aussage, mehrere Rechner oder virtuelle Maschinen für den Test einzuplanen.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

den kompletten Artikel im PDF-Format mit Beispieldatenbank

diesen und alle anderen Artikel mit dem Jahresabo