AccEPT Die Access-Entwicklungsumgebung im Einsatz

Start AccEPT - Fehlervermeidung

AccEPT - Inhalt

  alle umschalten Alle reduzieren
Konzept, Entwurf top
# Titel erstellt geändert
1 Papier und Bleistift

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.

20 Sep 2003 04 Apr 2009
2 Anforderungen

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.

20 Sep 2003 31 Mär 2009
3 Notwendige Daten

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.

20 Sep 2003 31 Mär 2009
4 Namen vergeben

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

20 Sep 2003 31 Mär 2009
5 Reservierte Wörter

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

20 Sep 2003 05 Apr 2009
6 Sonderzeichen

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"

20 Sep 2003 06 Apr 2009
Tabellen, Abfragen top
# Titel erstellt geändert
1 Tabellenstruktur

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.

20 Sep 2003 31 Mär 2009
2 Datentypen

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

20 Sep 2003 31 Mär 2009
3 Autowert

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.

20 Sep 2003 31 Mär 2009
4 Dateneingabe

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.

20 Sep 2003 31 Mär 2009
5 Formatierung

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.

20 Sep 2003 31 Mär 2009
6 Null-Felder

Vorschlag

Bei Abfragen beachten, dass Felder keine Daten enthalten können.

Zur Vermeidung von

  • fehlerhafte Datenanzeige/-interpretation

Beschreibung

Vergleichen mit Datenfelder, welche keine Werte enthalten, geben immer False zurück.

Beispiel:
Tabellendaten
1: A
2: B
3: Null (kein Dateneintrag)
4: D

Select * From Tabelle Where TextFeld <> 'A' 

Rückgabe:
2: B
4: D

20 Sep 2003 31 Mai 2009
7 Bilder

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

 

20 Sep 2003 31 Mär 2009
8 Funktionen in Abfragen

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.

20 Sep 2003 31 Mär 2009
Formulare, Berichte top
# Titel erstellt geändert
1 Steuerelementnamen

Vorschlag

Steuerelemente eine aussagekräftige Bezeichnung geben.

Zur Vermeidung von

  • Programmierfehler

Beschreibung

Beim Hinzufügen von Steuerelementen vergibt Access Bezeichnungen wie Kombinationsfeld1, Befehl1, u.ä.
Wenn man später Ereignisprozeduren für diese Steuerelemente erstellt, wird der Code sehr schwer lesbar.
 
Beispiel:

Private Sub Befehl1_Click()
   DoCmd.Close acForm, Me.Name
End Sub

Abhilfe schafft hier die Anwendung einer Namenskonventionen mit Typkürzel für die verwendete Art des Steuerelementes
Übliche Typkürzel:
Textfeld: txt
Kombinationsfeld: cbx
Befehlsschaltfläche: cmd

20 Sep 2003 05 Apr 2009
2 Punkt oder Rufzeichen

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.)

 

20 Sep 2003 05 Apr 2009
3 Leeres Klassenmodul

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.

20 Sep 2003 31 Mär 2009
VBA, Makros top
# Titel erstellt geändert
1 VBA-Code statt Makro

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

20 Sep 2003 31 Mär 2009
2 Code dokumentieren

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.

20 Sep 2003 31 Mär 2009
3 Fehlerbehandlung

Vorschlag

In jeder Prozedur muss auf mögliche Fehler geachtet werden.

Zur Vermeidung von

Programmierfehler

Beschreibung

Besonders wichtig ist dies, wenn man plant die Anwendung später mittels einer Runtime-Version laufen zu lassen.
Die Access-Runtime unterstützt nicht die in der Access-Vollversion eingebaute Fehlerbehandlung. Sie kann nur auf eine Fehlerbehandlung reagieren, welche direkt im Code enthalten ist.

Grundstruktur einer Funktion mit Fehlerbehandlung:

Function BeispielFunktionD03() As Typ  
  '
  ' Variablen-Deklaration
  '
  On Error GoTo HandleErr
  '
  ' eigentlicher Programm-Code 
  '
  BeispielFunktionD03 = Wert + "asdsa"
  ExitHere:
  ' Ausstieg
  Exit Function

  HandleErr:
  ' Fehlerbehandlung
  BeispielFunktionD03 = Fehlerwert
  Resume ExitHere

End Function
20 Sep 2003 05 Apr 2009
4 Modul-/Funktionsname

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

20 Sep 2003 31 Mär 2009
5 Variablen-Deklaration

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.

20 Sep 2003 31 Mär 2009
6 Globale Variablen

Vorschlag

Globale Variablen so wenig wie möglich einsetzen.

Zur Vermeidung von

  • fehlerhafte Datenanzeige/-interpretation
  • Programmierfehler

Beschreibung

In den meisten Fällen kann man statt globalen Variablen mit Funktionsparametern arbeiten.

Falls man auf globale Variablen nicht verzichten kann, ist zu beachten, dass diese bei einem auftretenden Progammfehler zurückgesetzt werden.
Um dies etwas einzuschränken, kann man eine Property-Prozedur verwenden, in welcher Prüfungen durchgeführt werden.

Beispiel:

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
20 Sep 2003 31 Mär 2009
7 Objekte schließen

Vorschlag

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

Zur Vermeidung von

  • Anwendungsfehler
  • Beschädigte Anwendung

Beschreibung

Besonders bei nicht geschlossenen Recordset-Objekten kann es zu Problemen kommen.
Daher aus Sicherheitsgründen das Schließen selbst auslösen.

Beispiel:

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
20 Sep 2003 31 Mär 2009
8 Verweise

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

20 Sep 2003 31 Mär 2009
9 Late Binding

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

Verwandte Hinweise

20 Sep 2003 05 Apr 2009
10 API oder OCX

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.

20 Sep 2003 31 Mär 2009
11 DAO oder ADO

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.

20 Sep 2003 31 Mär 2009
12 DAO-Versionen

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

20 Sep 2003 31 Mär 2009
13 CurrentDb

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.

20 Sep 2003 31 Mär 2009
14 Transaktionen

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.

20 Sep 2003 31 Mär 2009
15 Aggregatfunktionen

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.)

20 Sep 2003 06 Apr 2009
Anwendung top
# Titel erstellt geändert
1 Hardware / Netzwerk

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.

20 Sep 2003 04 Apr 2009
2 Software

Vorschlag

Auf aktuelle Software-Updates achten.

Zur Vermeidung von

  • Anwendungsfehler
  • Beschädigte Anwendung
20 Sep 2003 31 Mär 2009
3 Anwendung testen

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.

20 Sep 2003 31 Mär 2009
4 MDE statt MDB

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.

20 Sep 2003 31 Mär 2009
5 DB komprimieren

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.

20 Sep 2003 31 Mär 2009
6 Frontend + Backend

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.

20 Sep 2003 31 Mär 2009
7 Mehrbenutzerbetrieb

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.

20 Sep 2003 31 Mär 2009
8 Geschwindigkeit

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.

20 Sep 2003 31 Mär 2009
9 Access-Sicherheit

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.

20 Sep 2003 01 Apr 2009
10 Backup

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!

20 Sep 2003 31 Mär 2009