Die Funktion allColumns liest die Namen aller Spalten aller Tabellen (inklusive der Systemtabellem) der aktuellen Datenbank aus und schreibt sie in das Direktfenster.

Sub allColumns()

    Dim x As Integer
    Dim y As Integer
    Dim db As DAO.Database

    Set db = CurrentDb

    For x = 0 To db.TableDefs.Count - 1
        Debug.Print db.TableDefs(x).name
        For y = 0 To CurrentDb.TableDefs(x).Fields.Count - 1
            Debug.Print CurrentDb.TableDefs(x).Fields(y).name
        Next
    Next

    db.Close
    Set db = Nothing

End Sub

Gelegentlich ist es erforderlich eine Tabelle per VBA zu erstellen. Das kniffligste Problem dabei ist eigentlich immer die Erstellung eines Autowert-Feldes. Das folgende Beispiel zeigt, wie man mit DAO ein Autowert-Feld an eine bestehende Tabelle anfügen kann.

Sub createAutoIncrField()

    Dim Fld As DAO.Field

    Set Fld = CurrentDb.TableDefs("deineTabelle"). _
                   CreateField("deinFeldname", dbLong)
    Fld.Attributes = dbAutoIncrField
    CurrentDb.TableDefs("deineTabelle").Fields.Append Fld

End Sub

Zur Wartung oder zur Datensicherung ist es erforderlich alle geöffneten Frontends einer Datenbank zu schließen. Oft machen einem die User zusätzliche Arbeit indem sie nach Feierabend die Datenbank geöffnet lassen.

Dafür habe ich folgende Lösung entworfen. In der Datenbank (Backend) muss eine zusätzliche Tablle (tblShutdown) angelegt werden, die nur das Ja/Nein-Feld shutdown enthält. Diese Tabelle kann man dann in ein Administrationsfrontend einbinden und von dort über das Setzen des Ja/Nein Wertes in dem einzigen Datensatz das globale Schließen der Frontends einleiten.

Im Frontend muss ein Timer laufen z.B. in einem unsichtbaren Formular, der in gewissen Abständen die Sub closeDB ausführt.

Probleme kann es geben, wenn in einem der Frontends der aktuelle Datensatz eine unvollständige Eingabe ist, die nicht gespeichert werden kann. Diese Situation sollte man unbedingt vor Einsatz der Funktion bedenken.

Sub closeDB()

    Dim rs As DAO.Recordset
    Set rs = CurrentDb.OpenRecordset _
                   ("SELECT shutdown FROM tblShutdown")

    If rs!shutdown = True Then
       rs.Close
       Application.CloseCurrentDatabase
    End If

    rs.Close

End Sub

Wenn man Informationen, wie Erstellungsdatum, Datum der letzten Änderung oder die Herkunft verknüpfter Tabellen, über Objekte in einer Datenbank benötigt, kann man die Systemtabelle MSysObjects auslesen.

Dazu muss man den User, der diese Operation durchführen soll, die Leseberechtigung auf die Tabelle Msysobject erteilen. Selbst der Access-Benutzer 'Administrator' hat per Default keine ausreichenden Rechte um diese Tabelle zu lesen.

Diese Methode um Informationen über die Tabellen in einer Access-Datenbank zu erhalten, ist besonders dann Nützlich, wenn man Access nur als Backend für eine Applikation verwendet, die ausschließlich über SQL auf die Access-DB zugreifen soll.

Das folgende SQL-Beispiel ermittelt die Namen und die Zeitpunkte der letzten Änderung aller direkt in der Datenbank gespeicherten Tabellen.

    SELECT Name, DateUpdate
      FROM MSysObjects
     WHERE Type = 1 and Flags = 0;

Gelegentlich möchte man überprüfen, ob ein bestimmtes Feld in einer Tabelle existiert. Die folgende Funktion versucht einfach, das gesuchte Feld einer DAO.Field-Variablen zuzuweisen. Wenn das nicht funktioniert, weil das Feld nicht existiert, wird ein Fehler ausgelöst und die Funktion verlassen. Ansonsten wird nur noch der Rückgabewert der Funkion auf True gesetzt bevor die Funktion verlassen wird. - Quick'n'Dirty, aber es erfüllt den Zweck.

Function fieldExists(tableName As String, fieldName As String) As Boolean
On Error GoTo fieldExists_Exit

    Dim fld As DAO.Field

    fieldExists = False
    Set fld = CurrentDb.TableDefs(tableName).Fields(fieldName)
    fieldExists = True

fieldExists_Exit:
    Set fld = Nothing

End Function

In den Newsgroups wird gelegentlich danach gefragt, für welche Datenzugriffsstechnologie man sich zu Beginn der Entwicklung einer neuen Access-Anwendung entscheiden sollte. Dazu möchte ich hier mal meine Gedanken zusammenfassen, wobei ich hier nicht so sehr die harten "beweisbaren" Fakten auflisten möchte, sondern mich eher auf etwas schwammige, aber doch auf praktischen Erfahrungen basierende, persönlichen Einschätzungen konzentriere.

Die Argumente, die gegen DAO häufiger vorgebracht werden, sind etwa folgende: "DAO ist veraltet!", "DAO wird nicht mehr weiterentwickelt.", "ADO bietet einen größeren Funktionsumfang.". Diese Argumente sind entweder falsch oder aus meiner Sicht nicht wirklich relevant.

Richtig ist, DAO wird nicht mehr weiterentwickelt, aber das ist kein Argument, dass bei der Entwicklung einer reinen Access-Lösung in's Gewicht fällt. DAO ist für Access "Feature Complete" d.h. fast alle Funktionen, die die JET-Engine zur Zeit bietet (mit Ausnahme einiger SQL92 Erweiterungen in JET 4.0) sind mit DAO nutzbar, wichtige neue Funktionen, bei denen das dann anders wäre, sind für due JET-Engine in absehbarer Zeit nicht zu erwarten. Also kann das kaum als Nachteil gewertet werden. Ganz im Gegenteil, DAO hat schon seit geraumer Zeit einen sehr stabilen Zustand erreicht, ist meines Ermessens frei von gravierenden Fehlern und da keine elementaren Änderungen und Erweiterungen an DAO zu erwarten sind, kann man guten Gewissens hoffen, dass dies auch zukünftig so bleiben wird.

DAO ist schwerpunktmäßig für den Zugriff auf Jet-Datenbanken ausgerichtet und optimiert. Beim Einsatz in einer reinen Access-Umgebung ist DAO daher performanter und für viele Einsatzbereiche auch deutlich komfortabler zu handhaben. Was die Performance im Vergleich zu ADO angeht, wollen manche Teilnehmer der Newsgroups einen Unterschied um einen Faktor größer als 10 zugunsten von DAO gemessen haben. Solche Aussagen sind meiner Meinung zwar nicht grundsätzlich falsch, jedoch ist ein so deutlicher Unterschied nur in speziellen, meist für diesen Zweck konstruierten, Szenarien messbar. Fakt bleibt jedoch; DAO ist beim Zugriff auf Access-Datenbanken schneller als ADO.

Noch eine weitere Tatsache, die eher für die Verwendung von DAO bei der Entwicklung von reinen Access-Anwendungen spricht. Mit der Einführung von Access 2000 hat Microsoft als Datenzugriffsbibliothek ADO anstelle von DAO voreingestellt. Bei Access 2002 (XP) war dies noch genauso, aber mit Access 2003 konnte sich auch Microsoft nicht mehr der Tatsache verschließen, dass sich ADO, mit gutem Grund, bei den Access-Entwicklern nicht durchgesetzt hat, und hat wieder DAO als Standard-Datenzugriffsbibliothek voreingestellt.

Und zu guter Letzt sollte man bei dem Thema auch nicht vergessen, dass ADO im Prinzip inzwischen genauso "überholt" ist, wie DAO. Mit ADO.NET gib es inzwischen eine weitere alternative Datenzugriffstechnologie, die zur Zeit zwar noch nicht in Access-Anwendungen verwendet werden kann, aber dennoch verdeutlicht, dass die zuküftigen Konzepte, die Microsoft für den Datenzugriff verfolgt, von dem abweichen, was ADO und DAO bisher geboten haben.

Fazit: Für reine Access Anwendungen ist nach wie vor DAO das Mittel der Wahl, wenn es um den Datenzugriff geht. Es gibt viele Argumente, die für DAO sprechen, aber nur sehr wenige dagegen. Anders sieht das erst dann aus, wenn man flexibel sein möchte, was das Backend der Anwendung angeht und einen Umstieg auf ein Datenbakserversystem in Erwägung zieht oder zumindest darauf vorbereitet sein möchte.