Textversion
Lebenslauf Referenzen Consulting Nützliches KnowHow.MDB PASS Deutschland e.V.
Startseite KnowHow.MDB

KnowHow.MDB


KnowHow.MDB Freeware Kalender Tool Weitere nützliche VBA Funktionen für Access

Downloads Kontakt Impressum Haftungsausschluss Von A-Z Sitemap Blog

Hintergründe zur Arbeitsweise von Access

Hintergründe zur Arbeitsweise von Access

Tabellen und Front- und Backend

Begriffsdefinition:

Backend (oder Backend-Datenbank) ist eine MSAccess-Datenbank, die von mehreren Benutzern gemeinschaftlich genutzt wird und die ausschließlich folgendes beinhaltet:

Tabellen (und deren Relationen)

Frontend (oder Frontend-Datenbank) ist eine MSAccess-Datenbank, die von einem Benutzer exklusiv und alleine genutzt wird und die folgendes beinhaltet:

Abfragen
Formulare
Berichte
VBA-Code (Module und Klassen)
Makros
Tabellen User- / oder Session-abhängige lokale Tabellen

Aufteilung zwischen Front- und Backend

Hintergründe und Arbeitsweise:

Intern ist die Tabellenverwaltung von Access ein eigenes Programmodul, das eher dem Betriebssystem zugehörig ist. Bis einschliesslich Access 2007 war die sog. "Jet-Engine" kein Access-Bestandteil, sondern ein reiner Bestandteil des Betriebsystems, das von Access nur benutzt wird. Das hat sich zwar bei Access 2010 in soweit geändert, dass die JET-Engine jetzt der Abteilung "Access" bei Microsoft gehört, und nicht mehr der Abteilung "Betriebssystem", aber es ist weiterhin technisch ein separater Teil.

Alle(!!) Daten und Programmteile (auch und besonders VBA-Programme und Formulare) von Access werden intern in System-Tabellen der jeweiligen Datenbank gespeichert. Access lädt diese Teile, sowie Teile des Backends je nach Bedarf in den Speicher.

Um eine höhere "gefühlte Geschwindigkeit", (d.h. eine höhere "Responsibilität") zu erreichen, werden intern von Access im Hintergrund jedoch nicht immer alle Daten sofort geladen, sondern manche asynchron - oder gar nicht (wenn das Access-interne Optimizer-Programmmodul meint, es sei nicht notwendig). Leider ist exakt diese Asynchron-Funktionalität, wenn sie intern mehrere Benutzer verwalten muss, derart stark fehleranfällig, dass es nicht ratsam ist, pro Frontend mehr als einen Benutzer zuzulassen. Um von vorneherein diese Art von Fehler auszuschließen, setze ich (wie übrigens von MS selbst dringend empfohlen) ZWINGEND voraus, dass pro User ein eigenes Frontend verwendet wird.

Dieses "Asynchron-Problem" kann in einer Access-Datenbank, die keinerlei Programmierung enthält, nicht auftreten. Dies ist einer Gründe, weshalb (innerhalb der "professionellen Access-Welt") das Front- und das Backend IMMER in zwei unterschiedlichen Datenbanken gehalten wird. Die Möglichkeit, dann die Daten leichter auf eine andere Grundlage (z.B. den MS SQL Server) zu portieren, ist ein weiterer Grund.

Da Access intern im Wortsinne „alles mögliche“ ins Memory lädt und sehr sehr häufig große Datenmengen (Programm-, Formular- und die eigentlichen Daten-Daten) zwischen Memory und der Datenbank hin und her befördert, wird zwischen der Datenbank und dem Memory SEHR viel Traffic erzeugt. Dieser Traffic sollte - vor allem aus Netzwerkentlastungs- und Geschwindigkeitsgründen - möglichst immer "lokal" gehalten werden, daher die dringende Empfehlung, das Frontend immer auf dem gleichen lokalen Laufwerk zu speichern, auf dem das Access-Programm installiert ist.

Erkenntnis daraus:

Ganz gleich, welche Datenbank und welche Programmierung man letztendlich verwendet, ein Frontend pro User im userlokalen Verzeichnis muss aus meiner Sicht zwingend als Startpunkt vorhanden sein und verwendet werden.

Vergleich zwischen MSSQL Server und MSAccess als Backend

Anzahl der User

Zum Backend: Sofern die Daten in der Jet-Engine (also Access) gehalten werden, werden diese Tabellendaten einfach in Teilen ins Memory geladen und von dort aus selektiert und verarbeitet. Dies funktioniert je nach Programmierung und Datenaufbau bis mindestens 20 - 30 gleichzeitig darauf (schreibend) zugreifenden Benutzern problemlos. Danach wird es ggf. problematisch, da Access diese Kontrolle verwalten muss, und Access als reines Desktop-Programm eher weniger dafür optimiert ist.

Beim SQL Server als Backend ist die interne Vorgehensweise die, dass die Daten von Access intern mittels normaler SQL-Befehle aus dem MS SQL Server angefordert werden, dann ins Memory gespeichert und dort verarbeitet werden und die Ergebnis-Daten wieder mittels normaler SQL-Befehle an den SQL Server zurückgesendet werden.

Die Aufbewahrung der eigentlichen Daten und deren Zugriff ist beim SQL-Server ist physikalisch ein von Access vollkommen getrennter Vorgang. Allerdings ist in wesentlich stärkerem Masse als bei einem Access-Backend die Anzahl der zu lesenden/schreibenden Datensätze dabei von entscheidender Bedeutung. Der konkurrierende Zugriff von mehreren Usern auf die gleichen Daten wird also vom SQL Server gehandelt, dieser ist speziell für dafür optimiert. Die maximal mögliche Anzahl der gleichzeitig auf den Server zugreifenden Personen ist also hauptsächlich von der SQL-Serverkonfiguration und nicht von Access abhängig.

Unterschiede bei der Programmierung

Dies bedeutet andererseits, dass man bei der Programmierung mit dem SQL-Server wesentlich stärker als bei MSAccess als Backend als darauf achten muss, die zu lesende/schreibende Datenmenge pro Lese/Schreibvorgang möglichst gering zu halten. Jedoch sind manche Arbeitsweisen, die mit Access sinnvoll sind, mit dem SQL-Server so nicht sinnvoll machbar und umgekehrt. So ist es beim Einsatz des SQL-Servers u.U. sinnvoll, manche Arbeiten direkt den SQL-Server (Serverseitig) erledigen zu lassen (Diese Möglichkeit ist bei Access als Backend logischerweise nicht gegeben).
Das direkte Anbinden ganzer Tabellen - wie bei Access als Backend üblich - an ein Formular ist, wenn der MSSQL-Server (oder eine andere Datenbank) als Backend verwendet wird, aus Performancegesichtspunkten "tötlich" und muss zwingend geändert werden.

Enttäuschend ist für viele die Erkenntnis, dass eine eins-zu-eins Umstellung von MS-Access auf den SQL-Server als Backend ohne Optimierung durchaus erst einmal einen Geschwindigkeitsverlust von meist ca. 20% (im Einzelfall mehr) mit sich bringt. Erst durch eine Optimierung (bedingt durch die generell andere Arbeitsweise) erreicht man eine Geschwindigkeitssteigerung, die dann allerdings erheblich sein kann.

Fazit

Da mit der MS SQL Server Express Edition ein ausgereifter MSSQL Server generell kostenfrei (auch zur geschäftlichen Nutzung) zur Verfügung steht, sollte man immer von vorneherein diesen als Basis verwenden. Wenn man dann noch die Datensicherung beachtet, und das Frontend pro User immer lokal hält etc. steht einer stabilen, langfristigen, performanten und dennoch stark skalierbaren Lösung nichts im Wege.

Druckbare Version

KnowHow.MDB