Vorschlag

Die Anwendungserstellung nicht sofort mit Access beginnen, sondern im Kopf.

Zur Vermeidung von

• Konzept-Fehler
• Problem mit Tabellenstruktur

Beschreibung

Zuerst muss festgehalten werden, wie die DB aufgebaut werden soll.
Dafür eignet sich ein großes Blatt Papier.

Es gibt zwar auch einige Software-Werkzeuge, die einem bei dieser Arbeit unterstützten. Dabei besteht aber die Gefahr, dass man sich zuviel auf die Software als auf die Anwendungserstellung konzentriert.

Vorschlag

Die Anforderungen der DB-Benutzer sollten vor der Anwendungserstellung festgehalten werden.

Zur Vermeidung von

• Konzept-Fehler
• Problem mit Tabellenstruktur

Beschreibung

Das Anwendungs-Design hängt primär von den Anforderungen der zukünftigen Benutzer ab. Das beginnt mit der Datengliederung und geht bis zur Bedienung in den Formularen.
Der spätere Benutzer muss mit der Anwendung umgehen und nicht der Entwickler.
 
Eine gute Methode die Anforderungen an eine Access-Anwendung zu ermitteln, ist z.B. eine Analyse der derzeitigen Arbeitsschritte (ohne die DB).
Aufbauend auf diese Prozessanalyse läßt sich relativ gut ein "Roter Faden" durch die Anwendung erstellen.
Anm.: Natürlich schließt eine (IST-)Prozessanalyse vorhergehende Überlegungen für eine Prozessverbesserung nicht aus.

Vorschlag

Vor dem Erstellen der Tabellen müssen die benötigten Daten ermittelt und gruppiert werden.

Zur Vermeidung von

• Problem mit Tabellenstruktur

Beschreibung

Die Qualität einer DB-Anwendung hängt hauptsächlich von der verwendeten Datenstruktur ab.
 
Wie kann man aber die Daten sinnvoll gliedern? Stichwort Normalisierung.
Aber auch Normalisierung kann übertrieben werden. Hier muss man einen, auf die Anforderungen der Benutzer optimierten, Mittelweg zwischen Normalisierungsgrad und Geschwindigkeit gehen.
 
Tipp:
Ein möglicher Strukturierungsansatz wäre, zu ermitteln, welche "Datengruppen" selbstständig behandelt werden können. Diese eignen sich sicherlich, in eine eigene Tabelle aufgenommen zu werden.
Wenn man die Datenstruktur einmal auf Papier festgehalten hat, kann man diese anhand der Datenflüsse von Beispieldaten prüfen.

Vorschlag

Bei der Namensvergaben von  Objekten in Access (Tabellen, Datenfelder, Abfragen, Formulare,…) eine Namenskonvention verwenden.

Zur Vermeidung von

• Programmierfehler

Beschreibung

Eine einheitliche Benennung von Access-Objekten erleichert nicht nur die Arbeit mit Access, sondern es entstehen auch später weniger Probleme, da man schon anhand des Namens erkennt, zu welcher Gruppe ein Objekt gehört.

Beispiele für Namenskonventionen finden sich in den meisten Access-Büchern.
Man muss sich aber nicht unbedingt an bestehende Regeln halten, man kann sich auch selbst solche Regeln zusammenstellen. Wichtig ist aber, dass man die einmal festgelegten Regeln konsequent einhält.
 
Grundstruktur einer Namenskonvention:
[Präfix] TypKürzel Basisname [Suffix]

Beispiel:
Tabelle Rechnungen: tblRechnungen

Externe Referenzen

• Accesss-FAQ 1.5 Benamsungen

Vorschlag

Keine von Access reservierten Wörter bei der Namensvergabe verwenden.

Zur Vermeidung von

• fehlerhafte Datenanzeige/-interpretation
• Programmierfehler

Beschreibung

Wenn reservierte Felder für Namen verwendet werden, führt dies immer wieder zu Fehlern - besonders bei Feldnamen in Tabellen.
 
Beispiel:
Gerne wird für ein Datumsfeld in einer Tabelle "Datum" verwendet. Datum (Date) ist aber eine Access-Funktion. Wird nun dieses Feld in einer Abfrage verwendet, kann dies zu Problemen führen.
Analog verhält es sich mit der Bezeichnung "Name".

Es gibt in der OH eine Liste für die reservierten Namen in Jet-SQL: "Für SQL reservierte Wörter"
Anm.: Da ich diese Liste nicht mittels der in die OH eingebauten Suchfunktion finden konnte, hier der vollständige Pfad:
Access-Hilfe: Microsoft ActiveX Data Objects (ADO) - SQL-Reference zu Microsoft Jet - Microsoft Jet-Referenz - Übersicht - Für SQL reservierte Wörter

Externe Referenzen

• Microsoft Knowledge Base: (286335) Reservierte Wörter in Microsoft Access
• Microsoft Knowledge Base: (321266) List of Microsoft Jet 4.0 reserved words

Vorschlag

Sonderzeichen, Leerzeichen und Umlaute nicht in Objekt-Namen verwenden.

Zur Vermeidung von

• Programmierfehler

Beschreibung

In Access ist es zwar möglich Objektnamen mit Leerzeichen zu erstellen, dies sollte aber unbedingt vermieden werden.
Denn falls z.B. Leerzeichen in Tabellennamen verwendet werden, müssen diese Namen immer in eckige Klammer geschrieben werden. Dies übersieht man aber gerne bei der Anwendungserstellung.
 
Ein Möglichkeit lange Feldnamen trotzdem lesbar zu machen ist, den Anfangsbuchstaben jedes Wortes groß zu schreiben.
 
z.B.:
Tabelle: Firmen_Personal statt "Firmen Personal"
Feldname: PersonalNummer statt "Personal-Nummer"

Vorschlag

Die Tabellenstruktur zum Erfassen der Daten an die Art der Daten und nicht an deren Wert festlegen.

Zur Vermeidung von

• Konzept-Fehler
• Problem mit DB-Struktur

Beschreibung

Es kommt immer wieder vor, dass Daten in Feldern eines Datensatzes erfasst werden, obwohl dafür die Erfassung in mehreren Datensätzen geeigneter ist.
 
Genauso oft werden für jedes Jahr neue Tabellen erstellt  Es ist aber geeigneter nur eine Tabelle zu verwenden und ein zusätzliches Feld zur Kennzeichnung anfügen.
Analog werden auch Daten die sich nur durch ihre Verwendung unterscheiden in eigenen Tabellen erfasst. Hier kann man auch zusätzliche Datenfelder zur Kennzeichnung verwenden. Über Abfragen lassen sich dann die gewünschten Varianten herausfiltern.
 
Beispiel 1: Erfassung des jährlichen Mitgliedsbeitrages.
 
Tabelle Beitragszahlung:
 
Falsche Variante:
Feld MitgliedsNummer (Zahl)
Feld Beitrag_2000 (Ja/Nein)
Feld Beitrag_2001 (Ja/Nein)
…
 
Bessere Variante:
Feld MitgliedsNummer (Zahl)
Feld BeitragsJahr (Zahl oder Datum)
…

Wenn Beitrag bezahlt wird, wird für das entsprechende Jahr ein neuer Datensatz erstellt.

Externe Referenzen

• Access-FAQ 1.31 Normalisierung und Datenbanktheorie

Vorschlag

Der verwendete Feldtyp hängt von der Verwendung der Daten ab.

Zur Vermeidung von

• fehlerhafte Datenanzeige/-interpretation
• Konzept-Fehler

Beschreibung

Es ist aber nicht nur der Wert des Feldes zu beachten, sondern auch die spätere Verwendung in Abfragen.
 
Beispiel: Sortieren
(Annahme: im Feld stehen nur Zahlen)
 
Sortier-Reihenfolge eines Textfeld:
1 - 10 - 11 - 2 - 3 - 30 - 4
 
Sortier-Reihenfolge eines Zahlenfeldes:
1 - 2 - 3 - 4 - 10 - 11 -30

Vorschlag

Autowert nicht für fortlaufende Nummern verwenden.

Zur Vermeidung von

• fehlerhafte Datenanzeige/-interpretation

Beschreibung

Ein Autowert-Feld dient ausschließlich zur eindeutigen Kennzeichnung von Datensätzen.
 
Für fortlaufende Nummer ist es besser diese manuell zu vergeben.
(z.B. mittels einer VBA-Funktion)
 
 
Beispiel-Tabelle tblKunden
Feld KundenID (Autowert)
Feld KundenNummer (Zahl auch Text ist möglich)
…
 
Das Feld KundenID dient zur Kennzeichnung des Datensatzes und zum Verknüpfen mit anderen Tabellen.

Vorschlag

Tabellen dienen für den Endbenutzer ausschließlich zur Datenablage nicht für die Dateneingabe/-ausgabe. Für diesen Zweck gibt es Formulare und Berichte.

Zur Vermeidung von

• fehlerhafte Datenanzeige/-interpretation

Beschreibung

Der Endanwender soll die Daten nicht direkt in den Tabellen ändern.
Erfolge die Datenänderung über Formulare, so kann man im Formular eine Plausibilätsprüfung durchführen. Dies erhöht die Datenqualität.

Vorschlag

Formatierungen erst bei den Ein-/Ausgabe-Objekten und nicht in der Tabelle.

Zur Vermeidung von

• fehlerhafte Datenanzeige/-interpretation

Beschreibung

Es besteht in Access-Tabellen die Möglichkeit Formatierungen von Tabellenfeldern in der Tabelle anzugeben.
Dies bewirkt aber unter Umständen, eine falsche Dateninterpetation bei der Weiterverwendung (z.B. in Abfagen)
 
Beispiel:
Feldinhalt: ABCDEF
Formatierung @@@-@@@
Anzeige: ABC-DEF
 
Wird nun in einer Abfrage nach "ABC-DEF" gefiltert, dann wird dieser Eintrag nicht angezeigt, da statt "ABC-DEF" immer noch "ABCDEF" als Feldwert gespeichert ist.

Vorschlag

Bilder nicht direkt in der Datenbank abspeichern.

Zur Vermeidung von

• Beschädigte Anwendung
• Geschwindigkeitsproblem

Beschreibung

Die Datenbank wächst sehr dadurch sehr stark an. Je größer die Datenbank ist, desto mehr Probleme kann sie verursachen.
Anm.: Vor allem die Speicherung als OLE-Objekt benötigt sehr viel Platz. Wenn Dateien im einer Tabelle gespeichert wrden müssen, sollte man diese binär abspeichern.

Alternative: Nur Verweis auf Bilddatei in DB speichern.

Externe Referenzen

• Access-FAQ 2.2 Bilder speichern

 

Vorschlag

Möglichst keine Funktionen in Abfragen verwenden.

Zur Vermeidung von

• Geschwindigkeitsproblem

Beschreibung

Man kann in Access-Abfragen VBA-Funktionen (Access-Funktionen bzw. selbst erstellte Funktionen) verwenden.
Wenn jedoch solche Funktionen als Abfrage-Kriterien verwendet werden, so kann Access diese Abfrage nicht optimieren. Dies führt meist zu einer längeren Ausführungszeit der Abfrage.
 
Ein weiteres Problem entsteht bei der Umwandlung einer MDB-Datei in ein Access-Projekt, da der SQL-Server keine Access-Funktionen nutzen kann.
Daher ist es empfehlenswert, eine SQL-Lösung statt einer VBA-Funktion zu nutzen.

Vorschlag

Datenfelder in Formularen und Berichten mittels "!" ansprechen.

Zur Vermeidung von

• Programmierfehler

Beschreibung

Beispiel:
Me!Datenfeld statt Me.Datenfeld
 
Aber:
Me.Name um den Formular-/Berichtnamen zu erhalten.
 
Eine Alternatives ist die vollständige Syntax zum Ansprechen des Datenfeldes:

Me.Recordset.Fields("Feldname")

Auch bei Steuerelementen ist Me.Steuerelement bzw. Me!Steuerelement möglich.
Bei der Variante Me.Steuerelement konnte ich bisher noch kein problematisches Verhalten feststellen. Andererseits  ist es auch nicht schädlich, wenn man bei Steuerelementen ebenfalls Me!Steuerelement verwendet. (Der Mini-Vorteil durch Early Binding bei Me.Steuerelement ist zu vernachlässigen.)

 

Externe Referenzen

• Access-FAQ 6.3 Punkt und Rufzeichen

Vorschlag

Bei Formularen und Berichten die keine Ereignisprozeduren enthalten die Eigenschaft "Enthält Modul" auf Nein setzen.

Zur Vermeidung von

• Geschwindigkeitsproblem

Beschreibung

Wenn die Eigenschaft "Enthält Modul" auf Nein gesetzt ist, so muss Acces für dieses Formular-/bzw. Berichts-Objekt kein Klassenmodul speichern. Dadurch wird das Objekt kleiner und schneller in der Anwendung.

Vorschlag

VBA-Code statt Makros verwenden.

Zur Vermeidung von

• Geschwindigkeitsproblem

Beschreibung

VBA-Code ist schneller und es kann eine strukturierte Fehlerbehandlung eingebaut werden.
 
Ausnahmen für die  Verwendung von Makros:
Makro Autoexec
Makro AutoKeys

Vorschlag

VBA-Code gehört dokumentiert!

Zur Vermeidung von

• Programmierfehler

Beschreibung

Während des Schreibens von Prozeduren, weiß man meist Was, Wann, Wo und Warum im Code passiert.
Trifft dies noch zu, wenn man den Code nach einem Jahr wieder ansieht?
Damit man später den Ablauf im Code nachvollziehen kann, ist dies zu kommentieren.

Tipp: Es gibt Programme, die eine Dokumentation aus den Code-Kommentaren erstellen können.

Externe Referenzen

• Doxygen - Source code documentation generator tool

Vorschlag

Modul und Funktionsnamen dürfen nicht übereinstimmen.

Zur Vermeidung von

• Programmierfehler

Beschreibung

Wenn eine Funktion "WertErmittlung" und einem gleichnamigen Modul existieren, so kann diese Funktion nicht aufgerufen werden.

Abhilfe schafft hier wieder ein sinnvolle Benennung.
z.B. für ein Modul: modWertErtmittlung

Vorschlag

In jedem Modul die Option "Option Explicit" verwenden.

Zur Vermeidung von

• fehlerhafte Datenanzeige/-interpretation
• Programmierfehler

Beschreibung

Option Explicit bedingt eine Deklaration der Variablen vor Verwendung im Code. Ohne diese Option erzeugt Access die Variable implizit.

Es kann aber beim Schreiben vorkommen, dass man einen Tippfehler macht. Wenn Option Explicit nicht verwendet wird fällt dies unter Umständen nicht einmal auf. Da aber in diesem Fall die "falsche" Variable verwendet wird, wird das gewünschte Ergebnis vermutlich auf sich warten lassen.

Vorschlag

Globale Variablen so wenig wie möglich einsetzen.

Zur Vermeidung von

• fehlerhafte Datenanzeige/-interpretation
• Programmierfehler

Private Const m_conBeispielStandardwert As Long = 1
Private m_Beispiel As Long
 
Public Property Get Beispiel() As Long
  If m_Beispiel = 0 Then
    m_Beispiel = m_conBeispielStandardwert
  End If
  Beispiel = m_Beispiel
End Property
 
Public Property Let Beispiel(NewValue As Long)
  m_Beispiel = NewValue
End Property

Vorschlag

Selbst geöffnete Objekte, wie z.B. Recordset-Objekte nach der Verwendung explizit schließen.

Zur Vermeidung von

• Anwendungsfehler
• Beschädigte Anwendung

Dim db As DAO.Database
Dim rst As DAO.Recordset
 
Set db = CurrentDb
Set rst = db.OpenRecordset("qryBeispiel")
With rst
  ' … Anweisungen mit Recordset-Objekt
  .Close ' rst schließen
End With
Set rst = Nothing ' Referenz entfernen
Set db = Nothing

Vorschlag

So wenig Verweise wie möglich verwenden.

Zur Vermeidung von

• Anwendungsfehler
• Programmierfehler

Beschreibung

Bei der Anwendungsweitergabe kommt es immer wieder zu Problemen mit fehlerhaften Verweisen.

Die einfachste Möglichkeit diese Fehler zu vermeiden ist so wenig Verweise wie möglich zu verwenden.
Dies wird z.B. durch verwenden von API-Funktionen statt von OCX-Objekten möglich.
Eine weitere Möglichkeit ist Late Binding. (siehe D09)

Externe Referenzen

• Access-FAQ 7.1 Verweise

Vorschlag

Statt eingebundenen Verweisen lieber Late Binding verwenden.

Zur Vermeidung von

• Programmierfehler

Beschreibung

Man kann Objekte auch erst zur Laufzeit in Access einbinden. Dies ist besonders bei Verwendung von ActiveX-Elementen zu bevorzugen.

Mit Verweis auf Excel-Object-Library Early Binding:

Dim xlApp As Excel.Application
Set xlApp = New Excel.Application

Mittels Late Binding:

Dim xlApp As Object
Set xlApp = CreateObject("Excel.Application")

Mittels Konstante für die bedingte Kompilierung kann während der Entwicklungphase Early Binding genutzt werden. Vor der Weitergabe der Anwendung ist nur noch die Compiler-Konstante zu ändern, um auf Late Binding umzustellen.

#Const ExcelEarlyBinding = 1
'  kann auch als Argument für bedingte Kompilierung
'  in den VBA-Projekteigenschaften gespeichert werden

Sub BeispielD09b()

#If ExcelEarlyBinding Then
    Dim xlApp As Excel.Application
#Else
    Dim xlApp As Object
#End If 

    Set xlApp = CreateObject("Excel.Application")
    '…
    Set xlApp = Nothing

End Sub

Vorschlag

Wenn möglich statt ActiveX-Elementen API verwenden.

Zur Vermeidung von

• Anwendungsfehler
• Programmierfehler

Beschreibung

Viele ActiveX-Elemente können durch API-Aufrufe ersetzt werden.
Ein Beispiel für gekapselte API-Aufrufe ist die FileDialog-Klasse von Karsten Pries.

Ein Anwendungsbeispiel befindet sich in der KnowHow.mdb von Klaus Oberdalhoff.

Externe Referenzen

• freeaccess.de: KnowHow.mdb von Klaus Oberdalhoff
• API Referenz
• AllAPI Network

Anweisung

Entweder ADO oder DAO verwenden.

Zur Vermeidung von

• Programmierfehler

Beschreibung

ADO und DAO dienen für den Datenzugriff.
Da beide Bibliotheken eine eigene Recordset-Klasse verwenden, kann es zu Verwechslungen kommen, wenn Verweise auf ADO und DAO vorhanden sind.
Daher sollten beide Datenzugriffsbibliotheken zugleich vermieden werden. Wenn DAO und ADO unbedingt gleichzeitig benötigt werden, dann ist es vorteilhaft die Bibliothek bei der Deklaration der Objektvariablen anzuführen.

Beispiel-Annahme: ADO-Verweis ist vor DAO-Verweis

Falsch:

Dim rst As Recordset
set rst = CurrentDb.OpenRecordset(…)

Das funktioniert nicht, da CurrentDB.OpenRecordest ein DAO-Recordset zurückgibt.

Richtig:

Dim rst As DAO.Recordset
set rst = CurrentDb.OpenRecordset(…)

Tipp:
Für Zugriff auf MDB-Datei DAO verwenden.
Für SQL-Server-Zugriff ADO.

Anweisung

Die richtige DAO-Version zur Anwendung verwenden.

Zur Vermeidung von

• Beschädigte Anwendung
• Programmierfehler

Beschreibung

Access 97 benötigt DAO 3.5x
Access 2000 - 2003: DAO 3.6
Access 2007 - .. : ACEDAO 12.0

Anweisung

CurrentDb nur einmal instanzieren.

Zur Vermeidung von

• Geschwindigkeitsproblem

Beschreibung

CurrentDb erzeugt jedesmal  eine neue Instanz der aktuellen DB. Da man aber meist mit der selben DB arbeitet, würde im Prinzip eine Instanz reichen.

Lösung von Michael Kaplan:

Private m_db As DAO.Database
Public Property Get CurrentDbC() As DAO.Database
    If (m_db Is Nothing) Then
        Set m_db = CurrentDb
    End If
    Set CurrentDbC = m_db
End Property

Anm.: Ein ähnliches Verhalten könnte man auch mittels DBEngine(0)(0) erzeugen.
Dies wird aber in der OH nicht empfohlen.

Anweisung

Bei komplexeren Aneinanderreihungen von Aktionsabfragen Transaktionen verwenden.

Zur Vermeidung von

• fehlerhafte Datenanzeige/-interpretation

Beschreibung

Mittels der Transaktions-Methode kann eine Folge von Änderungen wieder rückgängig gemacht werde, falls Fehler aufgetreten sind.

Mehr dazu siehe OH.

Anweisung

Recordset-Funktionen statt den Domänen-Aggregatfunktionen verwenden.

Zur Vermeidung von

• Geschwindigkeitsproblem

Beschreibung

Aggregatfunktionen sind sehr praktisch in ihrer Anwendung, da man schnell zum gewünschten Ergebnis kommt.
Sie sind aber meist langsamer im Vergleich zur Datenermittlung über SQL und Recordset-Objekten.

Lösung: Ersatzfunktionen für Dcount, Dmax, …

Beispiel RstLookup statt Dlookup:

Public Function RstLookup( _
            ByVal sFieldName As String, _
            ByVal sSource As String, _
   Optional ByVal sCriteria As String = "" _
   ) As Variant

    Dim db As DAO.Database
    Dim rst As DAO.Recordset
    Dim strSQL As String

On Error GoTo HandleErr

    strSQL = "SELECT " & sFieldName & _
             " FROM (" & sSource & ")"
    If len(sCriteria) > 0 Then
        strSQL = strSQL & " WHERE " & sCriteria
    End If

    Set db = CurrentDB
    ' oder Methode aus D13
    ' Set db = CurrentDAODB
    Set rst = db.OpenRecordset(strSQL)
    With rst
        If .EOF Then
            RstLookup = Null
        Else
            'Rückgabe des 1. Feldes
            RstLookup = .Fields(0)
        End If
    End With

ExitHere:
On Error Resume Next
    rst.Close
    Set rst = Nothing
    set db = Nothing
    Exit Function

HandleErr:
    Select Case Err.Number
    Case Else
        ' Fehlerbehandlung
        ' HandleError Err.Number, "RstLookup"
    End Select
    RstLookup = Null
    Resume ExitHere

End Function

RstMax:
Code ist ähnlich RstLookup mit folgender SQL-Syntax:

strSQL = _
    "SELECT Max(" & sFieldName & ") As DSMax" & _
    " FROM  (" & sSource & ")"
If sCriteria > vbNullString Then
    strSQL = strSQL & " WHERE " & sCriteria
End If

Weitere Beispiele sind in der AccEPT-DB im Modul modDAO enthalten. (DB steht im Download-Bereich zur Verfügung.)

Externe Referenzen

• The Access Web: Domain Aggregate Functions Replacements

Vorschlag

Auf ein stabiles Netzwerk achten

Zur Vermeidung von

• Beschädigte Anwendung
• Geschwindigkeitsproblem

Beschreibung

Gerade bei Mehrbenutzerbetrieb muss man auf ein stabiles Netzwerk achten.
Nicht immer ist ein Problem mit einer Access-DB auf die Software zurückzuführen. Es kann auch sein, dass eine defekte Netzwerkkarte u.ä. den Fehler verursacht.

Vorschlag

Auf aktuelle Software-Updates achten.

Zur Vermeidung von

• Anwendungsfehler
• Beschädigte Anwendung

Vorschlag

Vor der Weitergabe einer Access-Anwendung diese auf dem Ziel-System testen.

Zur Vermeidung von

• Anwendungsfehler

Beschreibung

Wenn auf Computern mit unterschiedlichen Betriebssystemen bzw. Office-Komponenten die selbe Anwendung läuft, kann dies zu überraschende Ergebnissen führen.
Daher immer die Anwendung mit einer ähnlichen Konfiguration wie auf dem Zielsystem testen.

Wichtig dabei sind nicht nur die Programm-Versionen sondern auch die installierten Service Packs und Updates.

Anweisung

Den Benutzer immer nur auf einer MDE arbeiten lassen.

Zur Vermeidung von

• Anwendungsfehler

Beschreibung

Eine MDB dienst grundsätzlich zum Entwickeln einer Anwendung. Wenn diese Anwendung benutzt wird, sollte man dies immer in der kompilierten Form (MDE) machen.

In einer MDE kann der Anwender keine Änderungen am Code durchführen.
Weiters benötigt eine MDE weniger Speicherplatz als eine kompilierte MDB, da der Code nur noch in kompilierter Form vorliegt.

Vorschlag

Die Datenbank regelmäßig komprimieren.

Zur Vermeidung von

• Beschädigte Anwendung

Beschreibung

Eine Access-DB wird mit der Zeit immer größer, auch wenn Daten daraus gelöscht werden.
Abhilfe schafft hier das regelmäßige Komprimieren der Datenbank.
Besonders während der Entwicklungsphase einer Anwendung ist regelmäßiges Komprimieren des Frontends wichtig.
Mit einer regelmäßigen Komprimierung sinkt auch das Absturzrisiko von Access.

Externe Referenzen

• Access-FAQ 1.22 Datenbank bläht sich auf

Vorschlag

Die Daten (Tabellen) von der eigentlichen Anwendung (Formulare, Berichte,…) trennen.

Zur Vermeidung von

• Anwendungsfehler
• Beschädigte Anwendung

Beschreibung

Wenn die Daten in einer eigenen Datenbank (Backend) ausgelagert sind, kann man z.B. über verknüpfte Tabellen von der Access-Anwendung darauf zugreifen.
Dies ermöglicht einerseits eine einfachere Datensicherung, andererseits entsteht eine bedeutend höhere Datensicherheit in einer Mehrbenutzer-Umgebung.

Ein weiterer Vorteil, welchen man schon in der Entwicklung nutzen kann, ist die Möglichkeit mehrere Backend-Dateien mit verschiedenen Szenarien zu verwenden.
Zum Umschalten auf ein anderes Szenario muss man nur die Tabellenverknüpfung ändern.

Vorschlag

Nur auf die Daten (Backend) darf gemeinsam zugegriffen werde. Die eigentliche Anwendung (Frontend) immer lokal auf jedem Arbeitsplatz abspeichern.

Zur Vermeidung von

• Anwendungsfehler
• Beschädigte Anwendung

Beschreibung

Im Mehrbenutzerbetrieb entstehen immer wieder defekte Datenbanken, da es zu Konflikten in der Anwendungsbenutzung kommt, wenn gemeinsam auf das Frontend zugegriffen wird.

Daher:
Backend auf den Server
Frontend lokal auf jeden Arbeitsplatz.

Falls die Access-Benutzerverwaltung verwendet wird, ist zu überlegen wo die Arbeitsgruppendatei abgelegt werden soll.
Die Ablage und der gemeinsame Zugriff auf dem Server, kann ebenfalls zu Problemen führen. Es erleichtert aber die Verwaltung der Benutzer.

Vorschlag

Auf die Ausführungsgeschwindigkeit der Access-Anwendung achten.

Zur Vermeidung von

• Geschwindigkeitsproblem

Beschreibung

Besonders im Mehrbenutzerbetrieb kann es zu Problemen mit der Ausführungsgeschwindigkeit kommen.
Wenn man dies jedoch schon in der Entwicklung der Anwendung berücksichtigt, so kann man auch diesem Problem vorbeugen.

Tipps um Access-Anwendung zu beschleunigen gibt es auf vielen Access-Seiten. Daher möchte ich auf dieses Thema hier nicht genauer eingehen.
Einige Artikel zu diesem Thema sind unter "Externe Referenzen" angeführt.

Externe Referenzen

• Dan Haught (FMS): Making Access Faster - 168 Tips to Speed Up Your Apps!
• Granite Consulting: Microsoft Access Performance FAQ
• Josef Pötzl: Performance-Tuning in VBA und Formularen (Vortrag AEK 7)
• Microsoft Knowledge Base: (303528) Optimale Pflege einer Jet 4.0-Datenbank

Vorschlag

Sicherstellen, dass die Anwendung im normalen Betrieb nicht verändert wird.

Zur Vermeidung von

• Anwendungsfehler
• Beschädigte Anwendung

Beschreibung

Damit eine fertige Anwendung von den Benutzern nicht unbewußt verändert wird, sollte man grundsätzlich nur eine mde verwenden.
Da in einer mde aber trotzdem noch die Abfragen verändert werden können, ist zu überlegen ob das Sicherheitskonzept von Access angewendet werden soll.

Externe Referenzen

• Access-FAQ 1.17 Wie sicher ist Access?
• Access-FAQ 1.18 Anwenden des Sicherheitssystems

Vorschlag

Anwendung regelmäßig sichern

Zur Vermeidung von

• Doppelter Arbeit

Beschreibung

Ein regelmäßig Backup vermeidet zu große Verluste, wenn eine mdb beschädigt oder gelöscht wurde.
Nicht vergessen: Die Backup-Datei auf Funktionsfähigkeit testen!