Mehrbenutzeranwendungen mit Access

Aus eins mach zwei oder drei oder …

Der Einsatz von Access in Mehrbenutzerumgebungen erfolgt üblicherweise in Form eines Backends, das die Tabellen mit den Daten enthält, und je einem Frontend für jeden Arbeitsplatz, von dem aus auf die Daten zugegriffen werden soll. Die Frontends enthalten dabei jeweils die Abfragen, Formulare, Berichte und VBA-Module – also alle Elemente, die mit der Benutzerumgebung und den Funktionen der Datenbankanwendung zusammenhängen.

Da Webserver mit Microsoft-Betriebssystem immer günstiger zu mieten sind, kommt in letzter Zeit mehr und mehr eine Variante zum Einsatz, bei der Benutzer per Web auf einen Terminalserver zugreifen und direkt auf dem Rechner arbeiten. Dieser enthält neben den Daten auch die Anwendungen. Für Unternehmen, deren Mitarbeiter räumlich getrennt arbeiten müssen, ist dies durchaus eine Alternative. Die dort verwendete Technik unterscheidet sich allerdings grob von dem, was dieser Artikel besprechen soll – daher wird diese Variante hier nur erwähnt, aber nicht weiter vertieft.

Datenbank aufteilen

Das Aufteilen einer Datenbank erledigt man entweder mit dem dazu vorgesehen Assistenten (unter Access 2003 etwa im Menü Extras/Datenbank-Dienstprogramme/Assistent zur Datenbankaufteilung). Die Einfachheit dieses Assistenten erfordert keine weitere Beschreibung.

Oder man entscheidet sich für das manuelle Aufteilen einer Datenbank, was auch nicht besonders kompliziert ist. Trotzdem sollten Sie eine Sicherungskopie anlegen, bevor Sie die folgenden Schritte durchführen:

1. Legen Sie eine neue Datenbank an, und importieren Sie alle Tabellen der aufzuteilenden Datenbank (Datei/Externe Daten/Importieren).

2. Löschen Sie alle Tabellen aus der aufzuteilenden Datenbank.

3. Verknüpfen Sie die Daten des neuen Backends mit dem nun tabellenlosen Frontend.

Verwenden Sie dazu den Menübefehl Datei/Externe Daten/Tabellen verknüpfen.

Performance-Tipps

Es gibt eine ganze Reihe Tipps, mit denen sich die Performance einer Access-Anwendung und speziell einer solchen Anwendung im Netzwerkeinsatz optimieren lässt. Diese sind allerdings erstens sehr umfangreich, und zweitens hat inside Access bereits an anderer Stelle davon berichtet. Die passende Artikelreihe reicht von Ausgabe 8/2004 bis Ausgabe 12/2004, die letztgenannte befasst sich speziell mit den Möglichkeiten zum Optimieren von verknüpften Datenbanken. Um einige Ansätze zu nennen: Die Objektnamenautokorrektur und Unterdatenblätter sind ungeliebte Ressourcenfresser, die sich per Mausklick abschalten lassen. Regelmäßiges Komprimieren sorgt für das Aufräumen von Datensätzen und Indizes. Der Einsatz gezielter Abfragen sorgt dafür, dass möglichst wenig Daten über das Netzwerk transportiert werden müssen. Auch die Datenherkunft von Formularen und den enthaltenen Steuerelementen muss nicht immer alle, sondern vielleicht nur die aktuell benötigten Daten enthalten.

Zugriff für alle

Voraussetzung für den Zugriff auf ein Datenbankbackend über das Netzwerk ist die passende Berechtigung. Jeder Benutzer, der auf die Datenbank zugreift, muss vollständige Rechte zum Lesen, Schreiben, Erzeugen und Löschen von Dateien in dem Verzeichnis haben, in dem sich die Backend-Datenbank befindet.

Lesen und Schreiben – das leuchtet ein. Warum der Benutzer aber auch die Rechte zum Erzeugen und Löschen von Dateien haben muss, zeigt sich erst nach einem Blick auf den Mechanismus, wie Access Informationen über die Benutzer verwaltet, die aktuell auf die Datenbank zugreifen.

Die LDB-Datei

Diese Informationen speichert Access in einer Datei, die den gleichen Dateinamen wie die Datenbankdatei hat – mit Ausnahme der Dateiendung, die in diesem Fall .ldb lautet. Der einzige Fall, in dem Access keine LDB-Datei anlegt, ist der exklusive Zugriff eines einzigen Benutzers. Da beim exklusiven Zugriff kein weiterer Benutzer dazwischenfunken kann, braucht man auch keine LDB-Datei.

Die LDB-Datei enthält den Computernamen und den Benutzernamen zu jedem Benutzer, der seit dem Erzeugen der LDB-Datei auf die Datenbank zugegriffen hat. Das bedeutet nicht, dass man aus dieser Datei die aktuell auf die Datenbank zugreifenden Benutzer ermitteln kann: Die Datei registriert nämlich nicht, wenn ein Benutzer den Zugriff beendet hat. Sie wird lediglich gelöscht, wenn der letzte Benutzer den Zugriff auf die Datenbank beendet hat.

Alle auf einen

Die Anzahl der gleichzeitig auf eine Datenbank zugreifenden Benutzer ist keinesfalls nur durch Leistungshürden beschränkt: Auch wenn die Performance mehr zuließe, ist 255 die Obergrenze für gleichzeitig zugreifende Benutzer. In der Praxis liegt diese Zahl freilich wesentlich unter diesem Wert – ab wie viel Benutzern die Performance einknickt, hängt dabei etwa davon ab, wie oft die Benutzer auf die Daten zugreifen beziehungsweise welche Datenmengen die Benutzer sich auf den Rechner schaufeln.

In Verbindung bleiben

Der erste Zugriff eines Anwenders auf eine bereits in Benutzung befindliche Datenbank findet manchmal verzögert statt, weil Access mehrmals versucht, die LDB-Datei zu löschen. Damit dies nicht bei jedem Zugriff passiert, stellen Sie eine Verbindung zum Backend her, die erst beim Beenden der Anwendung wieder gelöscht wird.

Dies erledigen Sie mit einem Formular, das an eine der Tabellen des Backends gebunden ist und nicht geschlossen wird, solange die Anwendung geöffnet ist. Am besten verwenden Sie dieses Formular für keine andere Aufgabe und stellen die Sichtbarkeit dieses Formulars auf Nein ein.

Alternativ zu einem an eine Tabelle gebundenen Formular können Sie natürlich auch im Beim Öffnen-Ereignis des Formulars ein Recordset mit einer der im Backend enthaltenen Tabellen erzeugen und dieses im Ereignis Beim Schließen wieder schließen und zerstören. Andererseits sollten Sie versuchen, möglichst wenige Verbindungen zur Datenbank zu erzeugen.

Zusammenfassung

Der Mehrbenutzerzugriff ist kein Hexenwerk. Wenn man die vielen Tipps zur Verbesserung der Performance von Anwendungen auf dem lokalen Rechner berücksichtigt, über die Expert´s inside Access in einer Artikelreihe in den Heften 8/2004 bis 12/2004 berichtet hat, ist schon eine Menge geschafft. Der kritische Punkt ist oft die Benutzeranzahl beziehungsweise die Anzahl der Zugriffe auf die Backend-Datenbank. Hier gilt es, möglichst im Vorfeld genau abzuschätzen, ob nicht der Einsatz eines alternativen Backends wie dem SQL Server 2005 beziehungsweise dessen Express Edition in Frage kommt. Konkrete Zahlen, ab welcher Belastung Access im Mehrbenutzerbetrieb einknickt, findet man nicht.