Häufige Probleme mit Access

Speziell in Access 2000 gibt es ein Problem mit den Bibliotheken. Um die Beispiele zu nutzen, sollten einige Einstellungen überprüft werden:

• Ein beliebiges Modulblatt öffnen (Alt+F11).

• In der Menüleiste den Eintrag 'Extras' wählen

• Den Menüpunkt 'Verweise' anklicken.

Dort sind üblicherweise mehrere Objektbibliotheken ausgewählt:

• Visual Basic for Applications

• Microsoft Access 9.0 Object Library

• OLE Automation

• Microsoft ActiveX Data Objects 2.1 Library

Leider fehlt hier regelmäßig die 'Microsoft DAO 3.6 Object Library', die in allen früheren Versionen von Access zu den wichtigsten Bibliotheken überhaupt gehörte. Sie muß nachgewählt werden und so verschoben werden, daß sie über der 'Microsoft ActiveX Data Objects 2.1 Library' steht.
Beginnt eine der angekreuzten Objektbibliotheken mit 'NICHT VORHANDEN…', dann muß das Kreuzchen vor dem Eintrag entfernt werden.
Die Objektbibliothek 'Microsoft ActiveX Data Objects 2.1 Library' ist für meine Anwendungen nicht erforderlich.

Hat man einen Code, wie den folgenden

 Public Sub MachWas()
    Dim A As Object
    Set A = CurrentDb.TableDefs("Hallo")
    ...
  End Sub

Dann sollte nach Ende der Prozedur eigentlich die lokal definierte Objektvariable A gelöscht werden. Dies geschieht auch, aber nicht sofort. Daher sollte man, wenn man das Objekt (hier: CurrentDb.TableDefs("Hallo")) noch braucht, das Programm mit Set A = Nothing abschließen.

Gelegentlich macht man aus einer MDB eine MDE-Datei: Die MDB enthält noch den Quellcode und ist für die Entwicklung gedacht, die MDE ist für die Benutzer gedacht und soll Anwender an Änderungen des Codes und der Formulare hindern.

Wenn allerdings beide Dateien im gleichen Verzeichnis stehen und den gleichen Namen haben, dann benutzen sie die gleiche LDB-Datei. Wenn nun ein Anwender die MDE geöffnet hat und ein Entwickler an der MDB arbeitet, bekommt der Entwickler dauernd Fehlermeldungen, weil Access glaubt, daß die MDB (und auch die MDE) von zwei Benutzern bearbeitet wird.

Will man in VBA mit Namen von Access-Objekten arbeiten, dann können diese Namen Gänsefüßchen (") enthalten - der Absturz des Programme droht, den VBA erwartet die Verdoppelung der Gänsefüßchen, sonst werden sie nicht als " ine einem String, sondern als Ende eines Strings verstanden. ´Zur Abhilfe habe ich eine VBA-Routine  geschrieben.

Wenn man in VBA SQL-Abfragen konstruiert, dann ergibt sich nach WHERE manchmal ein Ausdruck, der vom Typ String ist. Dann muß man diesen Ausdruck wieder in doppelte Gänsefüßchen setzen. SQL erlaubt zwar als Ersatz von " auch ein ' aber wenn dieses auch innerhalb des Textes vorkommen kann, könnte es wieder ein Problem geben, der Code wäre an dieser Stelle nicht sicher.
Fazit: Abfragen in SQL mit doppelten " ausführen und Strings auf " prüfen.

Wenn man SQL-Abfragen in VBA konstruiert, sollte man die Namen von Tabellen, Spalten und Alias-Namen in eckige Klammern setzen, insbesondere, wenn diese Namen vom Anwender zur Laufzeit eingegeben werden können. Das hat den Vorteil, daß Namen auch dann akzeptiert werden, wenn sie Leerzeichen enthalten oder zufällig mit SQL-Bezeichnern identisch sind. So kann gerade im deutschen Sprachraum der Spaltenname [Alter] vorkommen, aber ALTER ist auch ein SQL-Schlüsselwort

Standardmäßig ist Access darauf eingestellt, bei Feldnamen, die auf …ID enden, automatisch auch einen Index zu vergeben. Wenn solche Felder später mit einem Primärschlüssel versehen werden, legt Access diesen einfach an, ohne den vorherigen Index zu löschen. Daher sollte man seine Tabellen prüfen, ob unnötige Indizes angelegt wurden. Auch der Nachschlageassistent erstellt jedes Mal eine neue Beziehung, unabhängig ob schon eine geeignete Beziehung zwischen Tabellen besteht, oder nicht. Um zu prüfen, ob unnötig viele Beziehungen bestehen, habe ich eine Abfrage erstellt, die auf der Systemtabelle 'MSysRelationships' beruht.

Speziell das CurrentDb-Objekt hat eine wechselvolle Geschichte: Mal wurde es in einer Accessversion statt DBEngine empfohlen, dann war es wieder einmal ein Auslaufmodell, dann wurde es wieder empfohlen …
Speziell mit dem Transaktiosnschutz (BeginTrans, CommitTrans, Rollback) gibt es beim Konvertieren von Access 95 VBA-Modulen Probleme, denn diese Methoden laufen nur noch mit DBEngine.
Durch einige Bugs in Access kann es ein, dass bestimmte VBA-Anweisungen (z.B. in Zusammenhang mit der Fields-Auflistung des CurrentDb-Objektes) mit DBEngine(0)(0) laufen, mit CurrentDB aber nicht.