Dies ist die Site zur Access-Analyse-Datenbank “Accplorer”

Erkennbare Abhängigkeiten

Die Abfrage "qryTest" bzw. das Formular "frmTest" wird in folgenden Zusammenhängen in Modulen, Eigenschaften oder SQL-Strings korrekt erkannt:

CurrentDB.Execute "SELECT * FROM [qryTest]"
CurrentDB.Execute "SELECT * FROM qryTest WHERE ([TID] > 99)"
CurrentDB.Execute "SELECT qryTest.* FROM [qryTest] WHERE ([TID] > 99)"
strName = "qryTest"

DoCmd.OpenForm "frmTest",  acDesign, , , acFormReadOnly, acHidden
Set objVar = Form_frmTest

Nicht erkennbare Abhängigkeiten

Die Erkennung ist selbstverständlich aussichtslos, wenn die Abhängigkeiten in zusammengesetzten Texten oder im Inhalt von Tabellenfeldern enthalten ist:

Dim str1 As String, str2 As String
str1 = "qry"
str2 = "Test"
CurrentDB.Execute "SELECT * FROM [" & str1 & str2 & "]"

DoCmd.OpenForm RS.Fields("FormularName").Value, acPreview

Wechselseitige Abhängigkeiten

Lücken in den Ebenen (z.B. "1,2,3,10,11,12") entstehen durch wechselseitigen Aufruf von Prozeduren und Funktionen in Modulen, so daß sich die Ebenen "hochschaukeln":

'Modul A: ________________________________________________
Sub prozA1()
    ModulB.prozB1
End Sub

Sub prozA2()
   '...irgendein Code
End Sub

'Modul B: ________________________________________________
Sub prozB1()
    ModulA.prozA2
End Sub

Ignorierte Abhängigkeiten

Die Aufrufe eigener Funktionen (z.B. in Abfragen) werden nicht analysiert, da dies die Auswertungszeit um ein Vielfaches erhöhen würde. Zudem könnte (wie im vorangegangenen Beispiel schon) ebenfalls eine rekursive Abhängigkeit entstehen, wenn das Modul "modTest" eine Abfrage "qryTest" öffnet, in der wiederum eine Funktion benutzt wird, die in "modTest" definiert wurde.

Unsichere Abhängigkeiten

Es wird in jedem Objekt nur die erste Fundstelle ausgewertet, gleichnamige Berichte und Formulare können nicht zweifelsfrei auseinandergehalten werden! Eine Analyse der voranstehenden VBA-Befehle findet nicht statt, so daß also im folgenden Beispiel mit gleichnamigem Formular und Bericht nur zufällig eines davon gefunden wird.

Sub prozA()
    DoCmd.OpenForm “test”
    DoCmd.OpenReport “test”
End Sub

Kommentare in VBA-Modulen oder Makros werden nicht als solche erkannt, sondern als Fundstelle mitberücksichtigt!

Verdachtsobjekte

Wenn die Suche anhand der Ungarischen Notation (auch nach den Mitentwicklern Lesczinsky/Reddick benannt) erfolgt, werden die im Dialog gewählten 3 Zeichen langen Wortanfänge gesucht. Dies geschieht unabhängig von den im Umfeld gefundenen Schlüsselworten (z.B. “DoCmd.OpenForm”). Nur das Präfix entscheidet über die Zuordnung zu einem Objekt-Typ.

Unabhängig davon kann die Suche “irgendwo (nach Schlüsselworten)” durchgeführt werden. Dann wird nach bestimmten Schlüsselworten (z.B. “SELECT”, “FROM”, “DoCmd.OpenReport”, o.ä.) ein Objekt vermutet. Hier ist die Fehlerquelle relativ hoch, weil etwa in “SELECT “abc” AS Name...” keine Tabelle/Abfrage folgt, sondern ein berechnetes Feld. Daher werden im Zweifelsfall viel mehr verdächtige Objekte gefunden als es tatsächlich sind. Dies gibt Ihnen jedoch die Chance, diese dann im Zusammenhang des Aufrufs manuell zu prüfen.

Dies ist bereits in Schritt 7 möglich, wenn Sie die komprimierte Anzeige deaktivieren:

Trotz aller Anstrengungen gibt es also immer noch Möglichkeiten, Abhängigkeiten oder Verdachtsobjekte zu verstecken, daher kann auch der Accplorer nicht garantieren, wirklich alles zu finden.

(Alle verkleinerten Hardcopies führen als Link zu einer vergrößerten Version des jeweiligen Bildes.)