Generelle Überlegungen bei der Neuentwicklung

Bei einer Neuentwicklung einer Access-Datenbank sollten Sie berücksichtigen, dass viele Tools die „schnell“  bzw. als Übergangslösung programmiert werden, im Laufe der Zeit zu Standard-Anwendungen erhoben werden und nicht mehr aus dem Unternehmen wegzudenken sind. Wenn man das berücksichtigt, wird man zu dem Schluss kommen, dass sogenannte „Stand-Alone“ -Anwendungen bzw. Dateninseln keine dauerhafte Lösung sein können.

 
1.Vorteile einer Access-Anwendung mit Backend Access:

1.1. Wenig Programmieraufwand, dadurch schnell einsatzfähig.

1.2. Nur Kenntnisse in VBA und grundlegende Kenntnisse über relationale Datenbanken nötig.

2. Nachteile einer Access-Anwendung mit Backend Access:

2.1. Datensicherheit: Die Jet Engine ist leider nicht besonders stabil. Jedem der schon eine Access-Anwendung programmiert hat, ist ab und an die Datenbank abgestürzt.

2.2. Performance: Mit wachsender Datenmenge wird die Anwendung langsamer.Möglichkeiten des Performance-Tunings sind begrenzt.

2.3. Datenvolumen: Access ist begrenzt (2 GB). Wobei man davon ausgehen kann, dass vor Erreichen dieses Wertes  schon massive Performance-Probleme auftreten.2.4.    DatenverfügbarkeitUneingeschränkt stehen die Daten nur der Access-Anwendung zur Verfügung. Werden die gleichen Daten auch in anderen Anwendungen benötigt, so behilft man sich in der Regel mit einem Export, welcher nicht aktuell gehalten wird (Snapshot). Somit gibt es meist Überschneidungen von Katalogdaten und Stammdaten, die in verschiedenen Anwendungen (Access-Datenbanken) benötigt und deshalb doppelt eingegeben werden müssen. Das könnte man dadurch umgehen, dass man die Daten und das Programm trennt. So eine separate Daten.mdb kann man anderen Access-Anwendungen durch Verlinkung (ODBC) zur Verfügung stellen. In der Praxis treten hier bereits nach kurzem Einsatz Probleme im Bereich Performance oder Datenvolumen auf. Nicht zu vergessen, dass bei exzessiver Nutzung der Daten durch mehrere Programme aufgrund der Sperrlogik von Access(Jet) Zugriffsprobleme auftreten.

 

3. Vorteile einer Access-Anwendung mit Backend SQL Server

3.1. Datensicherheit: Die Datenbankmaschine des SQL Servers ist sehr stabil.

3.2. Performance: Möglichkeiten des Performance-Tunings sind reichlich vorhanden, wie z. B. die Verwendung von Indizies, Datenzugriff über Stored Procedures. Außerdem gibt es diverse Tools für die Analyse der Performance.

3.3. Datenvolumen: Je nach eingesetzter Version ist  das Datenvolumen begrenzt (SQL Server Express = 4 GB) oder unbegrenzt (SQL Server Enterprise).

3.4. Datenverfügbarkeit: Daten stehen uneingeschränkt für Frontends zur Verfügung. Mehrere Access-Frontends können den gleichen Datenpool nutzen. (Keine Überschneidungen von Katalogdaten und Stammdaten, keine Doppelterfassung auf der Datenbank) Als Schnittstelle für Frontends stehen ODBC für *.mdb/*accdb (=Access 2007), sowie OLEDB für *.adp (Access Database Projects) zur Verfügung. Bei ADP-Projekten ist die Jet-Engine abgeschaltet, es greift die Sperrlogik des SQL Servers, die man durch Programmierung entsprechend steuern kann. Daten können ohne großen Aufwand als Basis für ein Datawarehouse genutzt werden.

3.5. Administration: Selbst wenn man nur die Express Edition des SQL Servers zu Verfügung hat, ist es möglich diesen über Access zu administrieren (nur bei ADP).

4.  Nachteile einer Access-Anwendung mit Backend SQL Server

4.1. Erhöhter Programmieraufwand

4.2. Erweiterte Kenntnisse in VBA hinsichtlich des Umgangs mit Recordsets , SQL Server Administration, grundlegenden Kenntnissen im Bereich relationaler Datenbanken, sowie Kenntnissen in T-SQL (SQL-Syntax des MS SQL Servers).

5. Empfehlung

Aufgrund der oben genannten Vor-/Nachteile kommt man zu dem Schluss, dass es sinnvoll ist eine neue Anwendung mit Frontend Access und Backend SQL Server vorzuziehen. Wenn man ein ADP-Projekt aufsetzt hat man für die Zukunft vorgesorgt. Spätere Erweiterungen sind problemlos zu integrieren, Performance-Probleme können schnell analysiert und behoben werden. Die Migration auf eine neue SQL Server Version ist ebenfalls ohne großen Aufwand zu realisieren. Da die Daten zentral auf dem SQL Server zur Verfügung stehen, kann man den vollen Funktionsumfang des SQL Servers nutzen. Beispielsweise können Sie auf dieser Basis über Analysis-Services ein Datawarehouse aufbauen und/oder die Reporting-Services nutzen. Diese haben gegenüber den Access-Reports viele Vorteile, wie zum Beilspiel:  den standardmäßig vorhandenen Export nach Excel oder das Speichern der Reports als PDF-Dokument.  Außerdem hat man die Möglichkeit Filter-Controls im Report zu hinterlegen, was den Anwendern erlaubt die Daten des Reports selbst zusammen zustellen. Eine Arbeitsgruppendatei (mdw) ist nicht notwendig, wenn Sie SQL Server als Backend verwenden. Es empfiehlt sich die Berechtigungssteuerung auf SQL Server anzulegen, eventuell mit einer Usertabelle über die Zugriffe bis auf Datensatzebene eingestellt werden können. Grundsätzlich sollte man den Anwendern nur eine kompilierte Version zur Verfügung stellen (mde/ade). Der Entwickler behält das änderbare Programm (mdb/adp).