Navigation

Access-Projekte

Was ist ein Access Projekt?
Ein Access Projekt (ADP) ist eigentlich ein wirkliches Frontend.
Diese Frontend besteht nur noch aus der grafischen Benutzeroberfäche (GUI), sprich den Formularen und Berichten. Und dem dazugehörigen VBA-Code.
Das bedeutet, dass alle Tabellen, Sichten und gespeicherte Prozeduren (Abfragen) nur auf dem Server liegen.
Die Verbindung läuft nicht über ODBC, sondern über OLE-DDE.
Der VBA-Code muss von DAO auf ADO übertragen werden, da die DAO-Methoden in einer ADP nicht mehr zur Verfügung stehen.
Es ist also sehr genau getrennt, wenn man in einer ADP mit temporären Tabellen arbeiten möchte, dann muss man entweder in eine Tabelle auf dem Server schreiben oder
diese Tabelle in einer gespeicherten Prozedur verwenden. Denn nur dort gibt es temporäre Tabellen.
Mit den formularbezogenen Abfragen ist es ebenfalls aus. Denn eine Sicht kennt die Werte im Formular nicht.
Auch der Zugriff auf andere Datenbanken gestaltet sich schwieriger.
Hinzu kommt auch, dass man keine Exportspezifikationen mehr verwenden kann,
sondern diese Daten müssen "von Hand", mittels VBA oder mittels T-SQL (BCP, DTS) exportiert werden.
Denn die Systemtabellen dafür sind auch nicht mehr vorhanden.
Tja und schlussendlich will ein SQL-Server auch gepflegt werden. (Datensicherung, Indizepflege, etc).
Warum sollte man also nun eine ADP erstellen und nicht die Tabellen über ODBC verknüpfen?
Klare Antwort: Die Performance und die Möglichkeiten. OLE-DDE stellt einen ganz anderen Zugriff dar, als ODBC.
Es geht um einiges schneller und man bekommt nur die Daten, die man braucht.
Die meiste Arbeit wird vom Server ausgeführt und nicht vom Klienten.
Und T-SQL heißt zwar SQL, kann aber wesentlich mehr als Jet-SQL, auch wenn die VBA-Funktionen nicht in T-SQL verwendet werden können.
Aber T-SQL ist schon eher eine Programmiersprache, als eine Abfragesprache.
Und man kann sich auch hier mit benutzerdefinierten Funktionen behelfen, die ungefähr mit Public Functions in Access zu vergleichen sind.
In Formularen / Berichten gibt es Eingabeparameter, die sehr hilfreich sind, wenn man mit gespeicherten Prozeduren als Datenherkunft arbeitet.
Zudem verfügt der SQL-Server über einen Job-Agenten, der bestimmte Aufgaben zu bestimmten Zeiten von ganz alleine ausführen kann.
Auch die Trigger sind nicht zu verachten, welche so etwas wie Ereignisaktionen auf Tabellenebene darstellen.
Und das Sicherheitssystem des Servers ist erste Sahne. Man kann einzelne Spalten für jeden Benutzer freigeben oder sperren.
Ebenfalls kann man einstellen, ob ein User nur lesen oder auch schreiben, bzw. etwas ausführen darf.
Der Aufwand für die Umstellung ist im Einzelfall recht unterschiedlich, da man die Abfragen und den SQL-Code ggf. anpassen muss.
Und vom Kentnissstand des Programmierers und der Komplexizität der Anwendung abhängt.
Aber eins steht fest der Microsoft SQL-Server stellt deutlich mehr an Möglichkeiten zur verfügung und kann diese auch noch schneller ableisten!