Letzte Änderung am 20. August 2021 by Christoph Jüngling
Access ist eigentlich genügsam, was den Speicherort angeht. Lokal oder im Netz, in C:\Programme oder im Benutzer-Space, auf den ersten Blick scheint das alles egal zu sein. Doch es gibt gute Orte und schlechte Orte. Hier ein paar Gedanken dazu (aufgrund des Umfangs in mehreren Teilen).
Gehe zu Teil 1 – Teil 2 – Teil 3
In diesem Artikel
Übersicht
Eine Access-Applikation besteht mindestens aus einer .accdb-Datei oder deren Derivat .accde (früher .mdb, .mde und vielleicht noch .mdw). Während der Entwicklungsphase weiß ich natürlich immer, wo die Datei liegt. Aber wohin lege ich sie beim Anwender?
Einige Leute sagen “einfach in’s Netz, da kommt jeder ran”. Klar, klingt logisch, schließlich kann Access ja auch damit umgehen, wenn mehrere Anwender die Datenbankanwendung benutzen. Ein paar Bedenken habe ich aber dabei:
- Was geschieht mit temporären Tabellen?
- Was passiert, wenn bei einem Benutzer ein Crash erfolgt?
- Wie sieht es aus, wenn jemand in einem Formular Veränderungen vornimmt, weil ihm dies so besser gefällt? Was sagen die anderen dazu?
Gehen wir die Punkte der Reihe nach durch.
Temporäre Tabellen
Nicht nur Access selbst verwendet diese (z.B. bei Abfragen), auch unser Projekt könnte während eines Datenimports diese zunächst in eine Hilfstabelle schreiben, um sie von dort aus an die jeweils richtigen Stellen im Datenmodell zu verteilen. Der Einfachheit halber wäre dies immer dieselbe Hilfstabelle, die vor dem Import z.B. mit einer Löschabfrage geleert wird. Aber was passiert, wenn das zwei oder mehr User zeitgleich machen?
Dann kommen die Daten vielleicht ordentlich durcheinander. Fatal, sowas.
Crash
Ein Crash sollte nicht passieren, aber – na ja – shit happens. Nehmen wir an, die .accdb ist danach so korrupt, dass sie repariert werden muss. Zunächst ist eines klar: Kein User kann aktuell dann noch damit arbeiten, der Crash bei einem User wirkt sich also quer durch die ganze Firma aus. Fatal, sowas.
Vielleicht ist mit “Reparieren und Komprimieren” alles wieder zu beheben, aber wer macht das? Entwickler oder User? Und welcher User weiß davon, dass das jetzt eine gute Idee wäre?
Veränderungen
Das ist vielleicht noch der schlimmste Fall: Ein User verändert etwas, weil es ihm so besser gefällt, weil er einen Fehler beheben möchte oder weil er in der Computer-Bild einen guten Trick gelesen hat. Vielleicht landen wir dann bei Punkt 2, dem Crash. Vielleicht ist die neue Situation aber so subtil anders, dass das Programm teilweise nicht mehr das macht, was es soll, was aber keiner merkt. Stellen wir uns das bei einer kaufmännischen Anwendung vor! Fatal, sowas.
Fazit
Es hat den Anschein, als ob “einfach in’s Netz, da kommt jeder ran” doch keine so gute Idee wäre. Mal überlegen, was gab’s da sonst noch?
Bleiben Sie dran, im nächsten Teil geht es weiter :-)
Neueste Kommentare