<\/p>\n
Eine einfache Suchfunktion ist schnell gebaut. Ein Suchfeld einrichten, eine Schaltfläche mit dem notwendigen VBA-Code anlegen und schließlich ein Steuerelement zum Anzeigen des Suchergebnisses. Was aber, wenn es nicht nur eines, sondern viele Kriterien gibt, und diese sich auch noch über mehrere Tabellen erstrecken Dieser Beitrag diskutiert die Möglichkeiten und zeigt einen Ansatz, mit dem Sie auf jeden Fall den Überblick behalten – egal, wie viele Kriterien und Tabellen die Suche umfasst.<\/b><\/p>\n
Wer Daten in einer Datenbank speichert, will diese meist auch nach verschiedenen Kriterien durchsuchen. Oftmals reichen wenige Suchmerkmale: Wer beispielsweise einen Shop betreibt, braucht in der Regel nur die Kundennummer, um dann zu einer angefragten Bestellung zu gelangen. Dies erledigt ein kleines Suchfeld zur Eingabe eben dieser Nummer. Die Abfrage, die aus den Kundendatensätzen den passenden heraussucht, ist ebenso einfach und die größte Herausforderung dürfte schon sein, sich für ein Listenfeld oder ein Unterformular zur Anzeige der gefundenen Kundendaten zu entscheiden.<\/p>\n
Viele Felder<\/b><\/p>\n
Etwas umfangreicher wird es, wenn sich der Suchbegriff nicht nur auf eines, sondern auf mehrere Tabellenfelder bezieht. Dies ändert im Vergleich zum ersten Beispiel nicht viel; Sie müssen lediglich die Abfrage um einige Kriterien erweitern.<\/p>\n
Tabelle mit Lookup-Feldern<\/p>\n
Lookup-Felder zeigen in Lookup-Tabellen ausgelagerte Informationen an. Einfachstes Beispiel ist die Anrede, die oft in der eigentlichen Tabelle als Fremdschlüsselfeld angelegt ist und auf eine weitere Tabelle namens tblAnreden <\/b>verweist, in der die eigentlichen Begriffe wie Herr <\/b>oder Frau <\/b>stehen.<\/p>\n
Das Durchsuchen von Tabellen mit Lookup-Feldern ist ebenfalls kein Hexenwerk: Man verwendet dann einfach eine Abfrage, welche die benötigten Felder der Lookup-Tabellen einbindet, und legt die Kriterien für diese Felder genau wie für die übrigen Felder dieser Tabelle fest.<\/p>\n
Viele Tabellen<\/b><\/p>\n
Richtig interessant wird es, wenn eine Tabelle viele verknüpfte Tabellen besitzt, die je nach Art der Information per 1:n- oder auch per m:n-Beziehung angebunden sind. Ein passendes Beispiel ist eine Dokumentenverwaltung.<\/p>\n
Diese besteht nicht nur aus der Tabelle mit den Dokumenten selbst, sondern aus vielen weiteren Informationen, die sich teils in per 1:n-Beziehung verknüpften Tabellen (zum Beispiel Dokumentart oder Versionen) oder auch in Tabellen befinden, die durch eine m:n-Beziehung angebunden sind (Autoren, Kategorien, Stichwörter). Mitunter befinden sich die interessanten Felder dort sogar in den Verknüpfungstabellen zur Realisierung der m:n-Beziehung. Das Datenmodell des Beispiels können Sie Bild 1 entnehmen.<\/p>\n
![\"pic001.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic001_opt.jpeg\")
<\/p>\n
Bild 1: Datenmodell der Beispieldatenbank<\/span><\/b><\/p>\n Eine große Abfrage<\/p>\n Prinzipiell könnte man eine große Abfrage erstellen, die alle potenziell für die Suche relevanten Tabellen enthält und dabei die im Datenmodell festgelegten INNER JOIN<\/b>s, also die Verknüpfungen zwischen den Tabellen, beibehält. Diese würde man dann in Abhängigkeit von den im Suchfenster gewählten Kriterien mit einer entsprechenden WHERE<\/b>-Klausel ausstatten. Grundsätzlich ist das die einfachste Methode. Allerdings muss man mehrere Faktoren berücksichtigen:<\/p>\n Dies können Sie am Beispiel der Abfrage aus Bild 2 prüfen. Wenn die Tabelle tblDokumente <\/b>zwei Datensätze enthält, von denen lediglich einer mit Einträgen der Tabelle tblDokumenteAttribute <\/b>verknüpft ist, dann liefert die Abfrage auch nur den oder die verknüpften Datensätze zurück.<\/p>\n Bild 2: Beispielabfrage mit per m:n-Beziehung verknüpften Tabellen<\/span><\/b><\/p>\n Prinzipiell ist ein INNER JOIN <\/b>also auch ein Kriterium, auch wenn man es nicht an der Stelle festlegt, an der man üblicherweise die Kriterien einträgt, also in der Zeile Kriterien <\/b>des Abfrageentwurfs.<\/p>\n Wenn man dies auf eine große Abfrage überträgt, die alle verknüpften Tabellen enthält, müsste ein Dokument zunächst einmal Einträge in allen verknüpften Tabellen aufweisen, um überhaupt im Ergebnis einer solchen Abfrage aufzutauchen. Sobald es entweder keine Stichwörter (tblDokumenteStichwoerter<\/b>), Kategorien (tblDokumenteKategorien<\/b>), Autoren (tblDokumenteAutoren<\/b>) oder sonstige Attribute aufweist (tblDokumenteAttribute<\/b>), zeigt die Abfrage ein Dokument auch nicht an – unabhängig von weiteren hinzugefügten Kriterien.<\/p>\n LEFT JOIN statt INNER JOIN<\/b><\/p>\n Wie nun kann man eine Abfrage mit verknüpften Tabellen verwenden, ohne dass nicht vorhandene Daten in einer der verknüpften Tabellen direkt das K.O.-Kriterium für einen Dokumentdatensatz bedeuten Probieren wir es aus und stellen schnell eine passende Abfrage zusammen, indem wir die fünf Tabellen tblDokumente<\/b>, tblAutoren<\/b>, tblKategorien<\/b>, tblDokumenteAutoren <\/b>sowie tblDokumenteKategorien <\/b>in den Abfrageentwurf ziehen und die Felder ID<\/b>, Pfad <\/b>und Dateiname <\/b>der Tabelle tblDokumente <\/b>sowie Kategorie <\/b>aus tblKategorien <\/b>und NameAutor <\/b>aus tblAutoren <\/b>im Raster der anzuzeigenden Felder unterbringen (siehe Bild 3).<\/p>\n Bild 3: Entwurfsansicht einer Abfrage mit einer Tabelle, die mit zwei anderen Tabellen per m:n-Beziehung verknüpft ist<\/span><\/b><\/p>\n Ein schneller Wechsel in die Datenblattansicht sollte zumindest einen Datensatz anzeigen, denn die Datenbank enthält bereits einige Datensätze, von denen zumindest einer mit allen per m:n-Beziehung verknüpften Tabellen verbunden ist. Aber weit gefehlt: Dort erscheint kein einziger Datensatz. Das liegt daran, dass Access beim Anlegen der Beziehungen im Abfrageentwurf ein wenig zu eifrig war: Es hat nämlich Beziehungen zwischen den Feldern ID <\/b>der Tabellen tblDokumente <\/b>und tblAutoren<\/b>, tblDokumente <\/b>und tblKategorien <\/b>sowie tblDokumenteAutoren <\/b>und tblDokumenteKategorien <\/b>angelegt. Schuld war die Option Autoverknüpfung aktivieren<\/b>, die Sie aber ausschalten können. Ohne diese ist der Abfrageentwurf gleich ein wenig überschaubarer, wie Bild 4 zeigt, und außerdem blendet das Ergebnis auch einige Datensätze ein (siehe Bild 5).<\/p>\n Bild 4: Ohne zusätzliche Beziehungen klappt es auch mit den Verknüpfungen.<\/span><\/b><\/p>\n Bild 5: Ohne zusätzliche Beziehungen klappt es besser mit den Verknüpfungen.<\/span><\/b><\/p>\n Betrachten wie diese Abfrage nun stellvertretend für eine viel umfangreichere Abfrage, die alle Tabellen des Beispieldatenmodells enthält. Das Ziel wäre nun, die Daten mit dieser Abfrage nach nur einem Kriterium wie etwa dem Autor zu durchsuchen und alle passenden Dokumente zu ermitteln, auch wenn diese nicht mit einem Datensatz der Tabelle tblKategorien <\/b>verknüpft sind.<\/p>\n Ein Ansatz wäre, statt eines INNER JOIN<\/b> ein OUTER JOIN <\/b>zu verwenden, das dafür sorgt, dass die Abfrage nicht nur die Datensätze ermittelt, die über alle enthaltenen Tabellen verteilt sind, sondern für alle Datensätze der Tabelle tblDokumente <\/b>mindestens einen Eintrag ausgibt, auch wenn diese nicht mit der Autoren- und der Kategorientabelle verknüpft sind.<\/p>\n Fangen wir einfach an und versuchen die INNER JOIN<\/b>-Methode zunächst nur mit den Tabellen tblDokumente<\/b>, tblDokumenteAutoren <\/b>und tblDokumenteKategorien <\/b>(siehe Bild 6). Dies funktioniert ohne Probleme: Die Abfrage zeigt etwas mehr als die in der Tabelle tblDokumente <\/b>enthaltenen Datensätze an, was daraus resultiert, dass einige Dokumente mit mehreren Einträgen der Tabellen tblDokumenteAutoren <\/b>und tblDokumenteKategorien <\/b>verknüpft sind.<\/p>\n Bild 6: Die Tabelle tblDokumente ist über zwei OUTER JOINs mit den Tabellen tblDokumenteKategorien und tblAutoren verknüpft.<\/span><\/b><\/p>\n Jetzt wird es interessant: Wir fügen die Tabellen tblAutoren <\/b>und tblKategorien <\/b>hinzu, denn immerhin sollen die Felder NameAutor <\/b>und Kategorie <\/b>gegebenenfalls als Suchkriterien zum Einsatz kommen. Doch der Versuch scheitert: Die Abfrage enthält mehrdeutige Inklusionsverknüpfungen, wie Bild 7 verrät.<\/p>\n Bild 7: OUTER JOINs mit anhängenden Tabellen vertragen sich nicht.<\/span><\/b><\/p>\n Die Meldung weist außerdem darauf hin, dass man einige der Verknüpfungen auf einzelne Abfragen verteilt und diese dann zusammenführt. Das funktioniert schließlich: Sie erstellen dazu zwei Abfragen mit dem folgenden SQL-Ausdruck, die jeweils das benötigte Feld NameAutor <\/b>(tblAutoren<\/b>) beziehungsweise Kategorie <\/b>(tblKategorien<\/b>) und das Feld DokumentID <\/b>der jeweiligen Verknüpfungstabelle tblDokumenteAutoren <\/b>und tblDokumenteKategorien <\/b>enthalten und unter den Namen qryDokumentAutoren <\/b>und qryDokumenteKategorien <\/b>gespeichert wurden:<\/p>\n Diese beiden ergeben dann in einer weiteren Abfrage zusammen mit der Tabelle tblDokumente <\/b>ein Konstrukt, das die Ausgabe von OUTER JOIN<\/b>s mit anhängenden Tabellen erlaubt (siehe Bild 8).<\/p>\n Bild 8: Wenn man Beziehungen mit weiteren Tabellen in Abfragen versteckt, funktionieren OUTER JOINs.<\/span><\/b><\/p>\n Minimale Abfragen<\/b><\/p>\n Es wäre also insgesamt möglich, eine große Abfrage zu erstellen, die alle benötigten Elemente enthält und für die man in Abhängigkeit von den gewünschten Kriterien eine passende WHERE<\/b>-Klausel zusammensetzt.<\/p>\n Wenn man davon ausgeht, dass die Abfrage im einfachsten Fall nur die IDs der gefundenen Dokumente zurückliefern soll, hängt an dieser Abfrage jedoch ein ziemlicher Overhead. Immerhin schleppt die Abfrage alle damit verknüpften Tabellen mit, auch wenn der Benutzer möglicherweise nur Dokumente mit einem bestimmten Namen aufgelistet bekommen möchte. Der notwendige SQL-Ausdruck der Abfrage sieht so wie in Bild 9 aus, und dieser spart schon die wegen der mehrdeutigen Inklusionsverknüpfung in weiteren Abfragen enthaltenen Tabellen ein. Wenn jemand nur nach einem bestimmten Dokumenttitel sucht, würde theoretisch ja auch die folgende Abfrage ausreichen:<\/p>\n Bild 9: Dieser SQL-Ausdruck liefert alle möglichen Suchfelder der Tabellen des Beispieldatenmodells.<\/span><\/b><\/p>\n <\/p>\n Wenn die gefundenen Datensätze beispielsweise in einem Listenfeld angezeigt werden sollen, welches die wichtigsten Informationen der Tabelle tblDokumente <\/b>anzeigt, müssten Sie die Tabelle tblDokumente <\/b>lediglich noch mit der obigen Abfrage zusammenführen, statt das Gebilde aus Bild 9 zu verwenden.<\/p>\n Dynamik ist Trumpf<\/b><\/p>\n Aber ist es möglich, immer nur die Tabellen in eine Abfrage zu integrieren, für die der Benutzer in einer Suche auch Kriterien angegeben hat Die Antwort lautet: Ja. Allerdings sind dafür einige Zeilen VBA-Programmierung nötig. Es gibt zwei Möglichkeiten:<\/p>\n Letzteres schauen wir uns in den folgenden Abschnitten im Detail an.<\/p>\n Schritt-für-Schritt-Abfragen<\/b><\/p>\n Bei der Schritt-für-Schritt-Abfrage beginnen Sie zunächst mit der Basistabelle, hier tblDokumente<\/b>, und werten die Kriterien aus, die sich auf Felder dieser Tabelle beziehen. Daraus resultiert eine Abfrage und ein entsprechendes Ergebnis, das Sie in einer temporären Tabelle namens tblTempSuche <\/b>mit den beiden Feldern ID <\/b>(Autowert) und DokumentID <\/b>(Zahl) zwischenspeichern. Als Nächstes untersuchen Sie die Kriterien, die sich auf Lookup-Tabellen beziehen wie die Dokumentart <\/b>(tblDokumentarten<\/b>) oder Status <\/b>(tblStatus<\/b>). Für jede Tabelle erzeugen Sie per VBA-Code wiederum ein SQL-Statement, das die Datensätze des gespeicherten Zwischenergebnisses mit dem neuen Kriterium abgleicht.<\/p>\n Anschließend geht es an die Tabellen, die per m:n-Beziehung mit der Tabelle tblDokumente <\/b>verknüpft sind. Diese werden nach dem gleichen Schema abgearbeitet: Das aktuelle Suchzwischenergebnis wird mit dem gegebenenfalls vorhandenen Kriterium in diesen Tabellen abgeglichen und wiederum gespeichert.<\/p>\n Suchformular<\/b><\/p>\n Bevor wir uns den Details dieser Vorgehensweise zuwenden, bauen wir ein kleines Suchformular, das in den nächsten Abschnitten noch wachsen wird. Zu Beginn enthält es lediglich ein Textfeld zur Eingabe eines Dateinamens, eine Schaltfläche zum Durchführen der Suche und ein Unterformular, das die gefundenen Suchergebnisse anzeigt.<\/p>\n Das Unterformular sfmSuche <\/b>soll einige Felder der Tabelle tblDokumente <\/b>in der Datenblattansicht anzeigen (siehe Bild 10). Allerdings nur die, die auch mit den in der Tabelle tblTempSuche <\/b>gespeicherten Daten übereinstimmen, und diese liefert die Abfrage qrySuchergebnis<\/b> (siehe Bild 11). <\/p>\n Bild 10: Das Unterformular zeigt die Suchergebnisse in der Datenblattansicht an.<\/span><\/b><\/p>\n Bild 12: Das Hauptformular der Suchfunktion in der Minimalausführung<\/span><\/b><\/p>\n Zu Beginn soll das Unterformular jedoch einfach an die Tabelle tblDokumente <\/b>gebunden sein. Das Hauptformular sieht zunächst wie in Bild 12 aus und besitzt keine eigene Datenherkunft. Die Eigenschaften Bildlaufleisten<\/b>, Datensatzmarkierer<\/b>, Navigationsschaltflächen <\/b>und Trennlinien <\/b>erhalten jeweils den Wert Nein<\/b>.<\/p>\n Bild 11: <\/span><\/b><\/p>\n Fehlt noch die Routine, die dafür sorgt, dass der vom Benutzer eingegebene Suchbegriff auch für die Suche genutzt und das Ergebnis im Unterformular angezeigt wird. Diese finden Sie in Listing 1. Die Routine löscht zunächst alle Einträge der temporären Tabelle mit den Suchergebnissen. Dann schreibt sie die Basisabfrage in die Variable strSQL<\/b>. Die WHERE<\/b>-Klausel wird in der Variablen strSQLWhere <\/b>zusammengesetzt.<\/p>\n Listing 1: Basisroutine zum Durchsuchen der Dokumente-Tabelle<\/p>\n Diese ist in der aktuellen Fassung ganz einfach und vergleicht lediglich den Dateinamen mit dem im Textfeld txtDateiname <\/b>angegebenen Ausdruck. Warum aber reicht da kein Einzeiler aus, der einfach nur ein SQL-Statement wie das folgende enthält (in einer Zeile)<\/p>\n Im Falle eines einzigen Parameters hätte dies völlig gereicht. Stattdessen prüft die Routine zunächst, ob das Feld txtDateiname <\/b>überhaupt einen Vergleichsausdruck enthält, schreibt dann das Kriterium mit führendem AND <\/b>in die Variable strSQLWhere<\/b>. Die folgende If…Then<\/b>-Anweisung dient schon als Vorbereitung darauf, dass mehr als nur ein Kriterium zum Einsatz kommt:<\/p>\n Sie schneidet schlicht das AND<\/b> des ersten Kriteriums ab, sodass bei Verwendung zweier Kriterien ein Ausdruck wie der folgende herauskommt:<\/p>\n Diesen prüft dann die dritte If…Then<\/b>-Bedingung auf seine Länge. Ist diese größer 0, liegt also ein passender Ausdruck vor, stellen die folgenden Anweisungen ein WHERE <\/b>voran und hängen das komplette Kriterium an die Basisabfrage an.<\/p>\n Diese wird dann an eine INSERT INTO<\/b>-Abfrage angehängt, welche die IDs der gefundenen Dokumente in die temporäre Tabelle tblTempSuche <\/b>schreibt und die Datenherkunft des Unterformulars mit dem Suchergebnis auf die Abfrage qrySuchergebnis <\/b>einstellt.<\/p>\n Wenn Sie das Kriterium wie in dieser Routine zusammensetzen, können Sie weitere Vergleichsausdrücke ohne Probleme hinzufügen. Im folgenden Beispiel soll der Pfad der enthaltenen Dokumente als zweiter Vergleichswert hinzukommen.<\/p>\n Dazu brauchen Sie im Hauptformular nur ein zweites Textfeld namens txtPfad <\/b>anzulegen und in die Routine, die durch den Klick auf die Schaltfläche cmdSuchen <\/b>ausgelöst wird, die folgenden Zeilen einzubauen – und zwar hinter der ersten If…Then<\/b>-Bedingung:<\/p>\n Auf die gleiche Weise verfahren Sie mit weiteren Feldern, die direkt in der Tabelle tblDokumente <\/b>enthalten sind.<\/p>\n Suche in Lookup-Tabellen<\/p>\n In Lookup-Tabellen wie etwa tblDokumentarten <\/b>oder tblStatus<\/b> kann man auf mindestens zwei Arten suchen, wenn man anschließend die IDs der Dokumente mit den gesuchten Eigenschaften erhalten möchte.<\/p>\n Die erste lässt dem Suchenden völlig freie Hand und erlaubt die Eingabe beliebiger Texte, nach denen dann zunächst die Datensätze der Lookup-Tabelle durchsucht und anschließend die korrespondierenden Dokumente ermittelt werden. Die Eingabe des Suchbegriffs erfolgt hier mit einem Textfeld.<\/p>\n Die zweite Methode ist komfortabler, aber auch weniger flexibel. Sie basiert auf der Anzeige aller in der Lookup-Tabelle enthaltenen Einträge in einem Kombinationsfeld. <\/p>\n Auf diese Weise braucht der Anwender nur noch den passenden Eintrag auszuwählen, wobei er unterstützend die ersten paar Zeichen eingibt und somit schneller zum gesuchten Eintrag springt.<\/p>\n Vorgehensweise bei Daten aus verknüpften Tabellen<\/p>\n Die Routine aus Listing 1 müssen Sie aufbrechen, um die aus anderen Tabellen stammenden Informationen zu durchsuchen. Wie bereits oben angekündigt, verwenden wir hier keine einzelne große Abfrage, um die gesuchten Datensätze zu finden, sondern mehrere aufeinanderfolgende, einfache Abfragen, die ihr Ergebnis jeweils in einer temporären Tabelle zwischenspeichern.<\/p>\n Nachdem diese nach der ersten Abfrage mit Informationen gefüllt ist, soll die zweite Abfrage nur noch die in der temporären Tabelle gespeicherten Datensätze durchsuchen und diejenigen, die auch den Kriterien der zweiten Abfrage entsprechen, wiederum dort eintragen. Eigentlich greifen Sie während dieses Vorgangs also lesend und schreibend auf die Tabelle tblTempSuche <\/b>zu, was gewisse Probleme mit sich bringt: Irgendwie müssen Sie ja nach dem Speichern des aktuellen Suchergebnisses das vorherige Ergebnis löschen. Daher speichert man die ID des zuletzt hinzugefügten Datensatzes jeweils zwischen, um nach dem Schreiben der Datensätze des neuen Suchergebnisses die alten Ergebnisse zu löschen.<\/p>\n Ein weiteres Problem besteht darin, dass das Unterformular beim Öffnen oder nach dem Löschen der Suchkriterien zunächst alle Datensätze anzeigen soll, die in diesem Fall direkt aus der Tabelle tblDokumente <\/b>stammen. Liegt mindestens ein Kriterium vor, kommt das Ergebnis jedoch aus einer Abfrage, die alle Datensätze der Tabelle tblDokumente <\/b>liefert, deren ID in der temporären Tabelle tblSucheTemp <\/b>aufgeführt sind. Damit die Routine nach dem Ermitteln der den Suchkriterien entsprechenden Datensätze die richtige Datenherkunft anzeigt, gibt es eine Boolean-Variable namens bolRecordsFound<\/b>, die auf True <\/b>eingestellt wird, sobald die Routine erstmals einen Datensatz in die Tabelle tblSucheTemp <\/b>geschrieben hat. Gleiches gilt für die Basisabfrage. Diese heißt zu Beginn der Routine so:<\/p>\n Sobald aber ein Kriterium ausgewertet wurde und die passenden Datensätze in die Tabelle tblSucheTemp <\/b>gelangt sind, dürfen Sie die folgenden Kriterien nicht mehr auf diese Basisabfrage anwenden, denn somit würden ja die zuvor ermittelten und in der Tabelle tblSucheTemp <\/b>gespeicherten Datensätze nicht berücksichtigt.<\/p>\n Deshalb schreiben Sie, sobald eines der Kriterien zu einer Ergebnismenge geführt hat, eine neue Basisabfrage in die Stringvariable strSQL<\/b>:<\/p>\n Lookup-Felder per Texteingabe durchsuchen<\/b><\/p>\n Mit diesen Hinweisen können Sie die Routine aus Listing 1 in die aus Listing 2 überführen. Sie enthält die angesprochenen Punkte sowie eine weitere Suche, die sich um die im Feld Dokumentarten <\/b>der Lookup-Tabelle tblDokumentarten <\/b>enthaltenen Texte kümmert. Die Eingabe des Suchkriteriums erfolgt über das Textfeld txtDokumentart<\/b>, die Suche nach den richtigen Datensätzen prinzipiell über eine Abfrage wie die folgende:<\/p>\n Listing 2: Diese Routine durchsucht sowohl in der Haupttabelle enthaltene Felder als auch solche, die sich in einer Lookup-Tabelle befinden.<\/p>\n Der kleine Unterschied ist, dass sich diese Abfrage hier unter Umständen auf die Tabelle mit den durch die vorherigen Kriterien ermittelten Datensätzen stützen muss, die in der Tabelle tblSucheTemp<\/b> gespeichert sind. Und genau dies erledigt der fett hervorgehobene Teil aus Listing 2: Er setzt die SQL-Abfrage zusammen, welche die IDs aller passenden Dokumente liefert, schreibt diese IDs in die Tabelle tblSucheTemp <\/b>und löscht die bisher gefundenen Datensätze aus dieser Tabelle.<\/p>\n Weitere Suchfelder, die sich auf Felder in Lookup-Tabellen beziehen, können Sie durch Hinzufügen eines passenden Textfelds sowie Kopieren und Anpassen des in Listing 2 fett gedruckten Teils erstellen.<\/p>\n Lookup-Felder per Auswahl durchsuchen<\/p>\n Komfortabler ist es, wenn der Benutzer einen Suchbegriff auf allen bereits vorhandenen Einträgen des Lookup-Felds auswählen kann. Dazu fügen Sie kein Textfeld, sondern ein Kombinationsfeld hinzu, das als Datensatzherkunft eine Abfrage auf Basis der Lookup-Tabelle enthält, welche die ID und den anzuzeigenden Text liefert. In unserem Beispiel lautet der SQL-Ausdruck für die Datensatzherkunft etwa wie folgt:<\/p>\n Die Eigenschaften Spaltenanzahl <\/b>und Spaltenbreiten <\/b>stellen Sie auf 2 <\/b>und 0cm <\/b>ein, damit das Kombinationsfeld nur das zweite Feld der Datensatzherkunft anzeigt und das erste lediglich als gebundenes Feld dient.<\/p>\n Der Codeausschnitt aus Listing 3 zeigt, welche Zeilen Sie der Prozedur cmdSuchen_Click <\/b>hinzufügen müssen, damit auch der Inhalt des Kombinationsfelds in die Suche mit einbezogen wird. Der Ausschnitt sieht fast genau so aus wie der aus dem Beispiel zur Suche nach einem im Feld Dokumentart <\/b>enthaltenen Text, unterscheidet sich jedoch in der verwendeten WHERE<\/b>-Bedingung.<\/p>\n Listing 3: Dieser Abschnitt der Routine cmdSuchen_Click filtert das Suchergebnis nach der im Kombinationsfeld cboDokumentarten angegebenen Dokumentart.<\/p>\n m:n-Beziehungen nach einzelnen Einträgen durchsuchen<\/b><\/p>\n Ob eine Tabelle per 1:n-Beziehung wie im obigen Fall der Lookup-Tabelle oder per m:n-Beziehung mit der Haupttabelle verknüpft ist, deren Datensätze als Suchergebnis zurückgeliefert werden sollen, spielt nur eine untergeordnete Rolle.<\/p>\n Als Beispiel dient hier die Tabelle tblAutoren<\/b>, die über die Tabelle tblDokumenteAutoren <\/b>mit der Tabelle tblDokumente <\/b>verknüpft ist.<\/p>\n Über ein Kombinationsfeld, das alle in der Tabelle tblAutoren <\/b>gespeicherten Autoren zur Auswahl anbietet, soll der Benutzer den Autor festlegen, dessen Dokumente er aufgelistet bekommen möchte.<\/p>\n Das Kombinationsfeld enthält als Datenherkunft die Tabelle tblAutoren <\/b>mit den Feldern ID <\/b>und NameAutor<\/b>. Der Code, der das mit diesem Kombinationsfeld festgelegte Kriterium auswertet, unterscheidet sich lediglich in einer Zeile von dem aus Listing 3. Diese Zeile legt die WHERE<\/b>-Bedingung fest:<\/p>\n m:n-Beziehungen per AND und OR nach <\/b><\/p>\n Viel spannender ist es, die Dokumente zu suchen, die mindestens einen oder alle von mehreren angegebenen Autoren aufweisen, also beispielsweise alle Dokumente, die von einem der beiden Autoren André Minhorst <\/b>oder Sascha Trowitzsch <\/b>geschrieben wurden, oder alle Dokumente, die beide gleichzeitig als Autoren aufweisen.<\/p>\n Erstmal brauchen Sie dafür eine geeignete Eingabemöglichkeit. Da gibt es verschiedene Varianten: Sie könnten gleich mehrere Kombinationsfelder anlegen, mit denen Sie die per OR<\/b> oder AND <\/b>verknüpften Suchbegriffe auf Basis der gleichen m:n-Beziehung festlegen. Nachteil ist, dass Sie eine feste Anzahl an Möglichkeiten festlegen müssen und dass diese auch immer den gleichen Platz einnehmen – auch, wenn der Benutzer gerade nur einen einzigen Eintrag der verknüpften Tabelle als Vergleichskriterium verwenden möchte. Der Vorteil ist die relativ einfache Programmierung.<\/p>\n Die zweite Variante ist ein Kombinationsfeld, gepaart mit einer Schaltfläche, mit der Sie den aktuell im Kombinationsfeld ausgewählten Eintrag in ein Textfeld eintragen (siehe Bild 13). Der Vorteil ist der mit einer einzigen Zeile geringe Platzbedarf, der Nachteil eine relativ aufwendige Programmierung: Die in dem Textfeld gespeicherten Ausdrücke helfen nicht viel weiter, wenn es um das Suchen selbst geht, denn diese Suche muss über die ID des jeweiligen Eintrags der verknüpften Tabelle, hier tblAutoren<\/b>, geschehen.<\/p>\n Bild 13: Auswählen von Kriterien via Kombinationsfeld<\/span><\/b><\/p>\n Daher speichert man sie in dieser Variante zwischen – und zwar in der Eigenschaft Tag <\/b>eines Steuerelements, hier dem Textfeld. Beim Durchführen der Suche muss man diese Eigenschaft dann noch parsen, um die durch ein Trennzeichen nach Wahl separierten Werte auszulesen und die entsprechende SQL-Abfrage zusammenzustellen.<\/p>\n Die dritte Variante wieder weniger platzsparend, dafür aber recht flexibel: Sie verwenden hier zwei Listenfelder, von denen das erste alle Einträge anzeigt, nach denen gefahndet werden soll, und das zweite alle übrigen. Die Suchbegriffe sollen dabei per Doppelklick oder durch entsprechende Schaltflächen (siehe Bild 14) von einem ins andere Listenfeld geschoben werden. Die Auswertung der Suchbegriffe ist hier wesentlich einfacher als im vorigen Beispiel.<\/p>\n\n
![\"pic002.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic002_opt.jpeg\")
<\/p>\n![\"pic003.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic003_opt.jpeg\")
<\/p>\n![\"pic004.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic004_opt.jpeg\")
<\/p>\n![\"pic005.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic005_opt.jpeg\")
<\/p>\n![\"pic006.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic006_opt.jpeg\")
<\/p>\n![\"pic007.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic007_opt.jpeg\")
<\/p>\nSELECT tblAutoren.NameAutor, tblDokumenteAutoren.DokumentID FROM tblAutoren INNER JOIN tblDokumenteAutoren ON tblAutoren.ID = tblDokumenteAutoren.AutorID;\r\nSELECT tblKategorien.Kategorie, tblDokumenteKategorien.DokumentID FROM tblKategorien INNER JOIN tblDokumenteKategorien ON tblKategorien.ID = tblDokumenteKategorien.KategorieID;<\/pre>\n
![\"pic008.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic008_opt.jpeg\")
<\/p>\n![\"pic009.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic009_opt.jpeg\")
<\/p>\nSELECT ID FROM tblDokumente\r\nWHERE Dateiname Like 'Access*';<\/pre>\n
\n
![\"pic010.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic010_opt.jpeg\")
<\/p>\n![\"pic012.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic012_opt.jpeg\")
<\/p>\n![\"pic011.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic011_opt.jpeg\")
<\/p>\nPrivate Sub cmdSuchen_Click()\r\n Dim strSQL As String\r\n Dim strSQLWhere As String\r\n Dim db As DAO.Database\r\n Set db = CurrentDb\r\n db.Execute "DELETE FROM tblTempSuche"\r\n strSQL = "SELECT ID FROM tblDokumente "\r\n If Not IsNull(Me!txtDateiname) Then\r\n strSQLWhere = "AND Dateiname LIKE '*" & Me!txtDateiname & "*'"\r\n End If\r\n If Left(strSQLWhere, 4) = "AND " Then\r\n strSQLWhere = Mid(strSQLWhere, 5)\r\n End If\r\n If Len(strSQLWhere) > 0 Then\r\n strSQLWhere = "WHERE " & strSQLWhere\r\n strSQL = strSQL & strSQLWhere\r\n db.Execute "INSERT INTO tblTempSuche(DokumentID) " & strSQL\r\n Me!sfmSuche.Form.RecordSource = "qrySuchergebnis"\r\n Else\r\n Me!sfmSuche.Form.RecordSource = "tblDokumente"\r\n End If\r\nEnd Sub<\/pre>\n
strSQL = "SELECT ID FROM tblDokumente WHERE Dateiname LIKE '*" & Me!txtDateiname & "*'"<\/pre>\n
Kriterium1 LIKE '*Wert1*' AND Kriterium2 LIKE '*Wert2*'<\/pre>\n
If Not IsNull(Me!txtPfad) Then\r\n strSQLWhere = "AND Pfad LIKE '*" _\r\n & Me!txtPfad & "*'"\r\nEnd If<\/pre>\n
SELECT ID FROM tblDokumente<\/pre>\n
strSQL = "SELECT ID FROM tblTempSuche"<\/pre>\n
Private Sub cmdSuchen_Click()\r\n Dim strSQL As String\r\n Dim strSQLWhere As String\r\n Dim db As DAO.Database\r\n Dim bolResultsFound As Boolean\r\n Dim lngLastID As Long\r\n Dim lngLastIDTemp As Long\r\n Set db = CurrentDb\r\n db.Execute "DELETE FROM tblTempSuche"\r\n strSQL = "SELECT ID FROM tblDokumente "\r\n 'Dateinamen\r\n If Not IsNull(Me!txtDateiname) Then\r\n strSQLWhere = "AND Dateiname LIKE '*" & Me!txtDateiname & "*'"\r\n End If\r\n 'Verzeichnisse\r\n If Not IsNull(Me!txtPfad) Then\r\n strSQLWhere = "AND Pfad LIKE '*" & Me!txtPfad & "*'"\r\n End If\r\n 'Einfache Kriterien, die sich in der Haupttabelle befinden, auswerten und\r\n 'das Ergebnis in die Tabelle tblSucheTemp schreiben.\r\n If Left(strSQLWhere, 4) = "AND " Then\r\n strSQLWhere = Mid(strSQLWhere, 5)\r\n End If\r\n If Len(strSQLWhere) > 0 Then\r\n strSQLWhere = "WHERE " & strSQLWhere\r\n strSQL = strSQL & strSQLWhere\r\n db.Execute "INSERT INTO tblTempSuche(ID) " & strSQL\r\n lngLastID = db.OpenRecordset("SELECT @@IDENTITY").Fields(0)\r\n strSQL = "SELECT ID FROM tblTempSuche"\r\n bolRecordsfound = True\r\n End If\r\n 'Dokumentarten\r\n If Not IsNull(Me!txtDokumentart) Then\r\n strSQLWhere = "WHERE ID IN (SELECT ID FROM qrySucheDokumentarten WHERE Dokumentart " _\r\n & "LIKE '*" & Me!txtDokumentart & "*')"\r\n strSQL = strSQL & " " & strSQLWhere\r\n db.Execute "INSERT INTO tblTempSuche(ID) " & strSQL\r\n lngLastIDTemp = db.OpenRecordset("SELECT @@IDENTITY").Fields(0)\r\n db.Execute "DELETE FROM tblTempSuche WHERE TempSucheID <= " & lngLastID, _\r\n dbFailOnError\r\n lngLastID = lngLastIDTemp\r\n strSQL = "SELECT ID FROM tblTempSuche"\r\n bolRecordsfound = True\r\n End If\r\n If bolRecordsfound Then\r\n Me!sfmSuche.Form.RecordSource = "qrySuchergebnis"\r\n Else\r\n Me!sfmSuche.Form.RecordSource = "tblDokumente"\r\n End If\r\nEnd Sub\r\nSELECT tblDokumente.ID,\r\ntblDokumentarten.Dokumentart\r\nFROM tblDokumentarten\r\nINNER JOIN tblDokumente\r\nON tblDokumentarten.ID =\r\ntblDokumente.DokumentartID\r\nWHERE tblDokumentarten.Dokumentart\r\nLIKE '*Suchbegriff*';<\/pre>\nSELECT ID, Dokumentart FROM tblDokumentarten;<\/pre>\n
If Not Me!cboDokumentart = 0 Then\r\n strSQLWhere = "WHERE ID IN (SELECT ID FROM tblDokumente WHERE DokumentartID = " _\r\n & Me.cboDokumentart & ")"\r\n strSQL = strSQL & " " & strSQLWhere\r\n db.Execute "INSERT INTO tblTempSuche(ID) " & strSQL\r\n lngLastIDTemp = db.OpenRecordset("SELECT @@IDENTITY").Fields(0)\r\n db.Execute "DELETE FROM tblTempSuche WHERE TempSucheID <= " & lngLastID, dbFailOnError\r\n lngLastID = lngLastIDTemp\r\n strSQL = "SELECT ID FROM tblTempSuche"\r\n bolRecordsfound = True\r\nEnd If<\/pre>\nstrSQLWhere = "WHERE ID IN (SELECT DokumentID FROM tblDokumenteAutoren WHERE AutorID = " & Me!cboAutoren & ")"<\/pre>\n
mehreren Kriterien gleichzeitig durchsuchen<\/pre>\n
![\"pic013.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic013_opt.jpeg\")
<\/p>\n![\"pic014.tif\"](\"..\/fileadmin\/_temp_\/2008_04\/Suche-web-images\/pic014_opt.jpeg\")
<\/p>\n