Das Access 2003 Entwicklerbuch

Transkript

1 André Minhorst Das Access 2003 Entwicklerbuch An imprint of Pearson Education München Boston San Francisco Harlow, England Don Mills, Ontario Sydney Mexico City Madrid Amsterdam

2 3 Abfragen Abfragen sind die Schnittstelle zwischen den in den Tabellen enthaltenen Daten und den für die Bearbeitung und Anzeige zuständigen Formularen und Berichten sowie für die Weiterverarbeitung per VBA. Genau wie Tabellen sollten die Benutzer einer professionellen Datenbank auch eine Abfrage nie zu Gesicht bekommen. Sie dient lediglich dazu, die Daten für die eigentliche Bearbeitung aufzubereiten. Dabei gibt es verschiedene Möglichkeiten: Einschränken der Felder einer Tabelle: Mit einer Abfrage können Sie die Felder auswählen, deren Inhalte als Abfrageergebnis angezeigt werden sollen. Einschränken der Daten einer Tabelle: Genau wie die Felder können Sie auch die anzuzeigenden Datensätze einer Tabelle per Abfrage einschränken. Dazu verwenden Sie ein geeignetes Kriterium. Zusammenführen der Daten verschiedener Tabellen: Nach der Normalisierung liegen Daten in vielen Fällen in mehreren, miteinander verknüpften Tabellen vor. In einer Abfrage können Sie die Felder der verknüpften Tabellen wieder zusammenführen und in den meisten Fällen wie eine einzige Tabelle verwenden. Zusammenführen der Daten gleichartiger Tabellen: Auch wenn man gleichartige Daten aus verschiedenen Tabellen benötigt etwa die Namen der Mitarbeiter aus der Mitarbeitertabelle und diejenigen aus der Kunden-Tabelle, hilft eine Abfrage weiter (siehe Abschnitt 3.3,»UNION-Abfragen«). Spezielle Aufbereitung von Daten: Mit Hilfe von Kreuztabellenabfragen lassen sich Daten wie beispielsweise die Verkaufszahlen von Produkten in bestimmten Zeiträumen in einer Art Matrix ausgeben. Berechnungen auf Basis der Felder der zugrunde liegenden Tabellen ausführen: Berechnete Werte in Tabellenfeldern sind bekanntlich tabu, da diese zu redundanten Daten führen. Daher gehören Berechnungen in Abfragen.

3 128 3 Abfragen Abfragen werden Sie überall antreffen: Als Datenherkunft von Formularen und Berichten, als Datensatzherkunft von Kombinations- und Listenfeldern, als Datenquelle von Recordset-Objekten in VBA-Code und vielleicht auch als Bestandteil einer weiteren Abfrage. Weil Abfragen so wichtig sind, stellt Access eine mächtige Entwurfsansicht dafür bereit, die nur wenig Wünsche offen lässt. So lassen sich dort keine UNION-Abfragen oder PassThrough-Abfragen eingeben; dafür ist aber eine zusätzliche SQL-Ansicht vorhanden, in die man nicht nur diese Abfragen eingeben, sondern mit der man auch den SQL-Text der anderen Abfragen ausgeben kann. Wie Sie vielleicht zu Beginn des Buches gelesen haben, setzt dies grundlegende Kenntnisse im Umgang mit Access voraus. Daher finden Sie im Folgenden auch keine detaillierte Beschreibung für die Anwendung der Abfrage-Entwurfsansicht, sondern Informationen zu oft benötigten Vorgehensweisen im Zusammenhang mit Abfragen. Dabei findet gelegentlich ein Vorgriff auf die in Kapitel 8,»Access-SQL«, enthaltene umfassende Beschreibung der Abfragesprache SQL statt. Die Beispiele zu diesem Kapitel finden Sie auf der Buch-CD in der Datenbank Kap_03\Abfragen.mdb. 3.1 Verwendung von Abfragen als Datenherkunft oder Datensatzherkunft Formulare und Berichte beziehen ihre Daten aus der unter der Eigenschaft Datenherkunft angegebenen Tabelle oder Abfrage, bei Kombinations- und Listenfeldern heißt die entsprechende Eigenschaft Datensatzherkunft. Zum Füllen dieser beiden Eigenschaften gibt es verschiedene Techniken, die nachfolgend erläutert werden. Die einfachste ist das Setzen der entsprechenden Eigenschaft auf eine bestehende Tabelle oder Abfrage. Der Einsatz einer Tabelle ist dabei nur sinnvoll, wenn alle Felder und alle Datensätze der Tabelle benötigt werden. Wenn nicht alle Felder der Tabelle Verwendung finden oder nicht alle Datensätze angezeigt werden sollen, verwenden Sie eine Abfrage. Das kommt auch der Performance Ihrer Anwendung zu Gute. Die Herkunft der Daten heißt in Formularen und Berichten Datenherkunft und in Steuerelementen wie dem Kombinationsfeld oder Listenfeld Datensatzherkunft. Wenn es im Folgenden nicht explizit um die Datensatzherkunft solcher Steuerelemente geht, wird verallgemeinernd der Begriff Datenherkunft verwendet.

4 Verwendung von Abfragen als Datenherkunft oder Datensatzherkunft 129 Tabelle als Datenherkunft Die einfachste Art der Datenherkunft ist eine Tabelle. In vielen Fällen haben Tabellen aber mehr Felder oder enthalten mehr Datensätze als tatsächlich angezeigt werden sollen. Lookup-Tabellen, die nur aus einem Primärschlüsselfeld und einem weiteren Feld bestehen, können aber durchaus ohne Verwendung einer Abfrage eingesetzt werden etwa als Datensatzherkunft von Kombinationsfeldern. Erst wenn die enthaltenen Daten auch noch sortiert werden sollen, ist eine Abfrage erforderlich. Beispiel für diese und die folgenden Möglichkeiten zur Bestückung von Formularen und Steuerelementen mit Datenherkünften ist ein Formular, das die Abwesenheit von Mitarbeitern nach Jahren filtert (siehe Abbildung 3.1). Abbildung 3.1: Beispiel für das Zuweisen der Datensatzherkunft Ein gutes Beispiel für die Verwendung einer Tabelle als Datensatzherkunft ist das Kombinationsfeld cbojahr. Voraussetzung für den Einsatz einer Tabelle ist, dass alle Felder benötigt werden und dass die Daten in der richtigen Reihenfolge vorliegen. Das ist hier der Fall: Das Feld JahrID dient als nicht sichtbares, gebundenes Feld und der Inhalt des Feldes Jahr wird im Kombinationsfeld angezeigt (siehe Abbildung 3.2). SQL-Ausdruck als Datenherkunft Die zweite Möglichkeit sind reine SQL-Ausdrücke. Diese können statt des Namens der Tabelle oder der Abfrage für die Datenherkunft- oder Datensatzherkunft-Eigenschaft angegeben werden. In vielen Fällen geht es einfach schneller, wenn man mal eben eine kurze SQL-Anweisung für die entsprechende Eigenschaft einträgt, als wenn man zunächst eine Abfrage erstellt, diese speichert und dann die Abfrage als Wert der jeweiligen Eigenschaft einträgt. Im Beispielformular ist das Kombinationsfeld cbomitarbeiter mit einem solchen SQL- Ausdruck ausgestattet. Dieser lautet folgendermaßen: SELECT tblmitarbeiter.mitarbeiterid, [Nachname] & ", " & [Vorname] AS Mitarbeiter FROM tblmitarbeiter;

5 130 3 Abfragen Abbildung 3.2: Tabelle als Datensatzherkunft Dieser Ausdruck wurde über die Entwurfsansicht für Abfragen erstellt, aber nicht als Abfrage gespeichert. In diesem Fall wird der reine SQL-Ausdruck in die Eigenschaft Datensatzherkunft des Kombinationsfeldes eingetragen. Gespeicherte Abfrage als Datenherkunft Die einfachste, weil ohne VBA- und SQL-Kenntnisse zu bewältigende und daher auch für Einsteiger geeignete Möglichkeit zur Erstellung einer Abfrage bietet die dafür vorgesehene Entwurfsansicht für Abfragen. Damit ist die Einschränkung der Datenherkunft sowohl bezüglich der Felder als auch der Datensätze möglich und auch die Verwendung von Parametern ist relativ einfach. Die Datensatzherkunft des Kombinationsfeldes cbomitarbeiter lässt sich natürlich ebenso mit einer gespeicherten Abfrage wie mit einem SQL-Ausdruck füllen. Um den SQL- Ausdruck in eine gespeicherte Abfrage zu überführen, klicken Sie einfach auf die Schaltfläche mit den drei Punkten ( ) und speichern die nun in der Entwurfsansicht angezeigte Abfrage ab beispielsweise unter dem Namen qryfrmabwesenheitencbo- Mitarbeiter. Auf diese Weise erkennen Sie später schnell, wofür Sie diese Abfrage benötigen.

6 Verwendung von Abfragen als Datenherkunft oder Datensatzherkunft 131 Verwenden Sie nun besser einen SQL-Ausdruck oder eine gespeicherte Abfrage als Datenherkunft? Performancetechnisch betrachtet besteht kein großer Unterschied in beiden Fällen wird die Abfrage beim ersten Aufruf kompiliert und damit optimiert (siehe auch Kapitel 12, Abschnitt ,»Abfragen und die Jet-Engine«). Bleiben zwei Gründe, die für das Speichern der Abfrage sprechen: Entweder benötigen Sie die Abfrage an mehreren Stellen oder Sie möchten die Abfrage testen beziehungsweise optimieren, während das Formular in der Formularansicht angezeigt wird. In allen anderen Fällen scheint die Verwendung eines SQL-Ausdrucks nahe liegender, zumal die Abfragen-Ansicht des Datenbankfensters sonst ziemlich schnell unübersichtlich werden dürfte. Datenherkunft per VBA zuweisen Die Eigenschaften Datenherkunft und Datensatzherkunft stehen auch unter VBA zur Verfügung dort verwendet man die Eigenschaftsnamen RowSource und RecordSource. Sie können diesen Eigenschaften von Formularen sowie Kombinations- und Listenfeldern per VBA den Namen einer Tabelle oder Abfrage oder auch einen SQL-Ausdruck zuweisen. Was macht das für einen Sinn? Manchmal weiß man noch nicht genau, wie die anzuzeigenden Daten gestaltet sind. Das ist meist bei Suchformularen der Fall: Ein Formular bietet mehrere Such- und Sortierkriterien an, die der Benutzer mit den gewünschten Werten füllen kann. Man könnte die Kriterien einfach in Form von Parametern an die der Suche zugrunde liegende Abfrage übergeben, aber je nach Komplexität und Anzahl der enthaltenenzugrunde liegenden Tabellen gerät die Abfrage recht komplex. Eine Abfrage über die drei per m:n-beziehung verknüpften Tabellen tblbestellungen, tblbestelldetails und tblartikel, deren Suchkriterien sich über die äußeren Tabellen erstrecken, benötigt auch alle Tabellen der Abfrage. Soll eine Suche allerdings alle Artikel liefern, deren Suchkriterien sich lediglich auf die Tabellen tblbestelldetails und tblartikel erstrecken, kann man die Tabelle tblbestellungen und die notwendige Verknüpfung und damit Zeit und Ressourcen sparen vorausgesetzt, das Abfrageergebnis gibt keine darin enthaltenen Felder zurück. Hier würde dann eine VBA-Routine zum Einsatz kommen, die einen SQL-Ausdruck mit den benötigten Tabellen zusammensetzt. Parameter statt Zusammensetzen von SQL-Ausdrücken Auch in anderen, einfacheren Fällen, in denen eine Abfrage lediglich aus einer einzigen Tabelle besteht und nur ein Parameter eingesetzt werden muss, verwenden viele Entwickler VBA, um einen SQL-String zusammenzusetzen und diesen als Datenherkunft zu verwenden. Das sieht dann beispielsweise so aus:

7 132 3 Abfragen Private Sub ListenfeldAktualisieren() Dim strsql As String Dim strsqlselect As String Dim strsqlwhere As String 'Basisabfrage (SELECT-Teil) strsqlselect = "SELECT AbwesenheitID, StartDatum, EndDatum, " _ & " Abwesenheitsart FROM tblabwesenheitsarten " _ & "INNER JOIN tblabwesenheiten " _ & "ON tblabwesenheitsarten.abwesenheitsartid = " _ & "tblabwesenheiten.abwesenheitart " 'Erstes Kombinationsfeld auswerten If Not Nz(Me!cboMitarbeiter, 0) = 0 Then strsqlwhere = "MitarbeiterID = " & Me!cboMitarbeiter End If 'Zweites Kombinationsfeld auswerten If Not Nz(Me!cboJahr, 0) = 0 Then If Len(strSQLWhere) > 0 Then strsqlwhere = strsqlwhere & " AND " End If strsqlwhere = strsqlwhere & "Year(tblAbwesenheiten.StartDatum) = " _ & Me!cboJahr.Column(1) End If 'SELECT-Teil zum SQL-Ausdruck hinzufügen strsql = strselect 'Falls WHERE-Bedingung vorhanden, WHERE-Teil zum SQL-Ausdruck hinzufügen If Len(strSQLWhere) > 0 Then strsql = strsql & " WHERE " & strsqlwhere End If Debug.Print strsql 'Neue Datensatzherkunft zuweisen und Listenfeld aktualisieren Me!lstAbwesenheiten.RowSource = strsql Me!lstAbwesenheiten.Requery End Sub Listing 3.1: Datensatzherkunft für ein Listenfeld per zusammengesetztem SQL-Ausdruck ermitteln Die Prozedur wird von den beiden Prozeduren aufgerufen, die durch die Ereigniseigenschaft Nach Aktualisierung der beiden Kombinationsfelder cbomitarbeiter und cbojahr ausgelöst werden. Die hier ermittelte SQL-Anweisung ist bei keiner Ausführung kompiliert.

8 Verwendung von Abfragen als Datenherkunft oder Datensatzherkunft 133 Eine Alternative ist die Verwendung einer gespeicherten Abfrage mit Parametern. Die Parameter, die normalerweise die Anzeige eines Dialogs zum Eingeben des Parameters hervorrufen, füllen Sie ebenfalls per VBA. Beim späteren Aufruf weisen Sie dem Listenfeld ein Recordset zu, das auf der kompilierten Abfrage inklusive Parametern basiert. Dies funktioniert übrigens nur unter Access XP und Access Unter Access 2000 und älteren Versionen von Access haben Kombinations- und Listenfelder noch keine Recordset-Eigenschaft. Die Abfrage sieht wie in Abbildung 3.3 aus. Die ersten vier Felder der Abfrage werden angezeigt, die letzten beiden sind lediglich Kriterienfelder. Als Kriterien dienen die per VBA zu füllenden Parameter [cbomitarbeiter] und [cbojahr]. Ersterer wird direkt mit dem Inhalt des Feldes MitarbeiterID verglichen, Letzterer mit dem Ausdruck, der durch die Anwendung der Jahr-Funktion auf dem Inhalt des Feldes StartDatum erzeugt wird. Dabei handelt es sich um die dem Datum entsprechende Jahreszahl. Abbildung 3.3: Abfrage mit Parametern Nun fehlt noch die Prozedur, mit der die Parameter per Code gefüllt werden und das Ergebnis der Abfrage dem Listenfeld zugewiesen wird. Diese Prozedur erstellt ein QueryDef-Objekt auf Basis der Abfrage qryfrmabwesenheitlstabwesenheitparameter. Dieses Objekt enthält eine Auflistung namens Parameters, mit der Sie die in der Abfrage gespeicherten Parameter referenzieren und die gewünschten Werte zuweisen können. Der Parameter [cbomitarbeiter] soll mit dem gebundenen Feld der Datensatzherkunft des Kombinationsfeldes cbomitarbeiter gefüllt werden, der Parameter [cbojahr] wird mit dem im Kombinationsfeld cbojahr angezeigten Wert bestückt. Beachten Sie, dass der angezeigte Wert nicht mit dem Wert des gebundenen Feldes übereinstimmt, sondern das Jahr und nicht dessen ID enthält!

9 134 3 Abfragen Nach dem Füllen der Parameter wird die Abfrage mit der OpenRecordset-Methode ausgeführt und das Ergebnis in ein Recordset-Objekt geschrieben, das schließlich der entsprechenden Eigenschaft des Listenfeldes zugewiesen wird. Die Prozedur verwendet einige Objekte, Methoden und Eigenschaften der DAO- Bibliothek von Access. Detaillierte Informationen finden Sie in Kapitel 8,»DAO«. Private Sub ListenfeldAktualisierenParameter() Dim db As DAO.Database Dim qdf As DAO.QueryDef Dim rst As DAO.Recordset 'Database- und Querydef-Objekt festlegen Set db = CurrentDb Set qdf = db.querydefs("qryfrmabwesenheitenlstabwesenheitenparameter") 'Parameter [cbomitarbeiter] mit der im Kombinationsfeld 'cbomitarbeiter ausgewählten MitarbeiterID füllen qdf.parameters("cbomitarbeiter").value = Me!cboMitarbeiter 'Parameter [cbojahr] mit dem im Kombinationsfeld angezeigten Jahr füllen qdf.parameters("cbojahr").value = Me!cboJahr.Column(1) 'Abfrage ausführen und Ergebnis in Recordset-Objekt ablegen Set rst = qdf.openrecordset 'Recordset der gleichnamigen Eigenschaft des Listenfelds zuweisen Set Me!lstAbwesenheiten.Recordset = rst Set rst = Nothing Set qdf = Nothing Set db = Nothing End Sub Listing 3.2: Listenfeld mit Parameterabfrage füllen Der erste Test mit dieser Routine läuft nur zufrieden stellend, wenn in beiden Kombinationsfeldern ein Wert ausgewählt ist. Eigentlich soll das Listenfeld beim Öffnen des Formulars alle Abwesenheiten anzeigen, beim Auswählen eines Mitarbeiters ohne Jahr alle Abwesenheiten dieses Mitarbeiters für alle Jahre, um beim Auswählen lediglich eines Jahres alle Abwesenheiten dieses Jahres für alle Mitarbeiter zu berücksichtigen. Das funktioniert deshalb nicht, weil die Abfrage beispielsweise bei fehlender Auswahl des Mitarbeiters den Wert Null als Parameter übergibt. Und da es keine Mitarbeiter mit der MitarbeiterID Null gibt, werden auch keine Abwesenheiten angezeigt. Das Gleiche gilt für die Auswahl des Jahres.

10 Verwendung von Abfragen als Datenherkunft oder Datensatzherkunft 135 Die Verwendung von Null als Standardwert bei fehlender Eingabe eines Parameters ist übrigens nicht zwingend, sondern in diesem Fall durch die Verwendung des Standarddatentyps Variant bedingt. Sie können für einen Parameter in der Abfragedefinition durchaus andere Datentypen angeben; folglich werden dann auch die entsprechenden Standardwerte bei fehlendem Wert verwendet (etwa 0 bei Zahlentypen oder eine leere Zeichenkette bei String-Variablen). Sie müssen also dafür sorgen, dass die Parameter im Falle einer fehlenden Auswahl neutralisiert werden. Folgender Trick hilft dabei weiter: Fügen Sie in die Kriterienspalte der betroffenen Felder die folgenden abgewandelten Ausdrücke ein. Ein Datensatz wird angezeigt, wenn das Kriterium wahr ist und das ist entweder bei passendem Parameterwert oder bei der Übergabe des Wertes Null der Fall: [cbomitarbeiter] Oder [cbomitarbeiter] Ist Null [cbojahr] Oder [cbojahr] Ist Null Interessant ist, was Access nach dem Schließen und erneutem Öffnen aus den Kriterien macht. Abbildung 3.4 zeigt, wie Sie die Kriterien alternativ formulieren können. Abbildung 3.4: Zwei harmlose Kriterienausdrücke nach der Überarbeitung durch Access Abfragen mit Parameter oder zusammengesetzte SQL-Ausdrücke? Welche der beiden Varianten Sie verwenden, hängt von der Menge der Parameter ab. Je mehr Parameter vorkommen, desto langsamer wird die Abfrage und umso komplizierter wird der Abfrageentwurf. Wenn Sie sich den Abfrageentwurf aus Abbildung

11 136 3 Abfragen 3.4 ansehen und sich vorstellen, wie eine Abfrage mit vier oder mehr Parametern aussehen wird, können Sie sich vermutlich ausmalen, wie viel Spaß eine nachträgliche Änderung am Abfrageentwurf machen wird. Für Abfragen mit mehreren Parametern empfiehlt sich daher eher die Verwendung eines per VBA zusammengesetzten SQL- Ausdrucks Probleme mit Kriterienausdrücken bei SQL-Ausdrücken in VBA Viele Fehler bei der Verwendung von SQL-Ausdrücken unter VBA passieren im Zusammenhang mit den Kriterien. Mal meldet Access das Problem, dass zu wenig Parameter übergeben wurden (siehe Abbildung 3.5), ein anderes Mal funktionieren die Vergleiche mit übergebenen Datumsangaben nicht. Abbildung 3.5: Fehlermeldung beim Verwenden einer SQL-Anweisung per VBA Zeichenkette oder Zahlenwert? Der Fehler aus Abbildung 3.5 resultiert fast immer aus dem Fehlen von Anführungszeichen im SQL-Ausdruck beim Verwenden von Zeichenketten als Kriterium. Das folgende Listing zeigt einen solchen Fehler: Public Function MitarbeiterSuchen(strNachname As String) Set rst = CurrentDB.OpenRecordset("SELECT MitarbeiterID, Vorname", "Nachname FROM tblmitarbeiter WHERE Nachname = " & strnachname) End Function Listing 3.3: Falsche Verwendung einer Zeichenkette als Kriterium

12 Verwendung von Abfragen als Datenherkunft oder Datensatzherkunft 137 In dieses Listing wurden keine Anführungszeichen für die Zeichenkette integriert. Der SQL-Ausdruck sieht für den Aufruf MitarbeiterSuchen "Müller" wie folgt aus: SELECT MitarbeiterID, Vorname, Nachname FROM tblmitarbeiter WHERE Nachname = Müller»Müller«wird hierbei nicht als Zeichenkette, sondern als Parameter ausgelegt. Da für diesen kein Wert vorliegt, erscheint obige Fehlermeldung. Die Lösung des Problems ist einfach: Fassen Sie den Parameter einfach in Anführungszeichen oder Hochkommata ein (in einer Zeile): oder Set rst = db.openrecordset("select MitarbeiterID, Vorname, Nachname FROM tblmitarbeiter WHERE Nachname = '" & strnachname & "'") Set rst = db.openrecordset("select MitarbeiterID, Vorname, Nachname FROM tblmitarbeiter WHERE Nachname = """ & strnachname & """") Probleme mit Datumsangaben Auch Datumsangaben führen immer wieder zu Problemen. Die folgende Routine soll beispielsweise Informationen über Abwesenheiten ausgeben, deren Beginn in einem bestimmten Zeitraum liegt, der durch die Parameter datstart und datende angegeben werden kann. Public Function AbwesenheitenZeitraum(datStart As Date, datende As Date) Set rst = db.openrecordset("select * FROM tblabwesenheiten WHERE" "Startdatum BETWEEN " & datstart & " AND " & datende, dbopendynaset) End Function Listing 3.4: Ermitteln von Abwesenheiten in einem bestimmten Zeitraum Wenn Sie die Routine mit folgendem Aufruf starten, erscheint die Fehlermeldung aus Abbildung 3.6. Auf den ersten Blick scheinen hier die Anführungszeichen zu fehlen. AbwesenheitenZeitraum " ", " " Ändern Sie den Aufruf der SQL-Anweisung wie folgt um, gibt es allerdings eine andere Fehlermeldung (siehe Abbildung 3.7): Set rst = db.openrecordset("select * FROM tblabwesenheiten WHERE Startdatum BETWEEN '" & datstart & "' AND '" & datende & "'", dbopendynaset)

13 138 3 Abfragen Abbildung 3.6: Fehlermeldung bei der Verwendung von Datumsangaben in SQL-Ausdrücken Diesmal hat Access Probleme mit dem Datentyp ein String scheint das Bedürfnis nach einem Wert des Typs DATETIME nicht zu befriedigen. Abbildung 3.7: Auch die Zeichenkette taugt nicht als Datumskriterium. Mit dem Wissen, dass Access Datumsangaben intern als Zahlenwerte behandelt, erscheint dies schnell logisch. Dabei gibt es zwei Möglichkeiten: Verwenden Sie den Datentyp Double, um Datumsangaben inklusive Uhrzeit zu verwalten, dann entspricht die Zahl vor dem Komma der Anzahl Tage seit dem und die Zahl nach dem Komma der Anzahl Sekunden, die am angegebenen Tag verstrichen sind. Für Datumsangaben ohne Uhrzeit reicht dementsprechend der Datentyp Long aus. Nun müssen Sie aber nicht alle Datumsangaben explizit in einen Zahlen-Datentyp umwandeln. Es reicht, wenn Sie ein standardisiertes Format verwenden. Dieses hat die Form yyyy-mm-dd. Zusätzlich fassen Sie diesen Ausdruck in der Abfrage in Raute- Zeichen (#) ein. In obigem Code sieht das Ganze dann wie folgt aus (in einer Zeile): Set rst = db.openrecordset("select * FROM tblabwesenheiten WHERE Startdatum BETWEEN #" & Format(strStart, "yyyy-mm-dd") & "# AND #" & Format(strEnde, "yyyy-mm-dd") & "#", dbopendynaset) Das Formatieren des Datums und das Einfassen in Rauten lässt sich auch per Funktion erledigen:

14 Verwendung von Abfragen als Datenherkunft oder Datensatzherkunft 139 Public Function ISODatum(strDatum As String) As String ISODatum = Format(strDatum, "\#yyyy-mm-dd\#") End Function Listing 3.5: Funktion zum Standardisieren von Datumsangaben Die Zeile aus obiger Routine sähe dann so aus (in einer Zeile): Set rst = db.openrecordset("select * FROM tblabwesenheiten WHERE Startdatum BETWEEN " & ISODatum(strStart) & " AND " & ISODatum(strEnde), dbopendynaset) Verweis auf Steuerelemente Access-SQL erlaubt direkte Verweise auf Formulare und Steuerelemente. Das ist hilfreich, wenn Sie etwa den Feldinhalt eines Formulars als Abfragekriterium verwenden möchten. Eine solche Abfrage sieht beispielsweise wie in Abbildung 3.8 aus. Abbildung 3.8: Abfrage mit einem Verweis auf ein Formularsteuerelement Ein Blick in die entsprechende SQL-Anweisung zeigt, dass der Ausdruck tatsächlich im gleichen Format wie in VBA in die Abfrage integriert wurde: SELECT MitarbeiterID, Nachname, Vorname, AbteilungID FROM tblmitarbeiter WHERE AbteilungID=[Forms]![frmMitarbeiter]![cboAbteilungen]; Dies funktioniert sogar, wenn Sie mit anderen Backends wie etwa MySQL arbeiten. Beim Zusammensetzen von SQL-Abfragen via VBA bietet es sich allerdings an, die entsprechenden Ausdrücke direkt auszulesen und als festen Parameterwert in die Abfrage zu integrieren.

15 140 3 Abfragen Die Verwendung einer fest in eine Abfrage eingebauten Referenz bringt den Nachteil mit sich, dass Sie diese Abfrage nicht einsetzen können, wenn Sie einen anderen als diesen Parameter verwenden möchten. Die Variante, eine Abfrage ohne Formularreferenzen zu erstellen und derartige Kriterien erst per VBA oder direkt in einer Datenherkunft- oder Datensatzherkunft-Eigenschaft zuzuweisen, ist flexibler. 3.2 Aktualisierbarkeit von Abfragen Je nachdem, wie die in einer Abfrage enthaltenen Tabellen beschaffen sind und wie Sie diese zusammensetzen, sind Abfragen nicht aktualisierbar, das heißt, dass Sie über die Datenblattansicht und damit auch über die Anzeige in Formularen keine Datensätze bearbeiten oder hinzufügen können. Es ist sicher jedem Access-Entwickler schon einmal passiert, dass er per VBA einen Datensatz einer Abfrage ändern oder hinzufügen wollte und eine entsprechende Fehlermeldung erschien, für die es scheinbar keine Erklärung gab. Wie erkennen Sie, ob das Abfrageergebnis aktualisierbar ist? Wenn Sie eine Abfrage in der Datenblattansicht öffnen, erkennen Sie recht schnell, ob diese aktualisierbar ist die Schaltfläche zum Springen auf einen neuen Datensatz ist ausgeblendet und unter dem letzten Datensatz befindet sich keine leere Zeile zum Anlegen eines neuen Datensatzes (siehe Abbildung 3.9). Abbildung 3.9: Eine nicht aktualisierbare Abfrage erkennt man an der deaktivierten Schaltfläche»Neuer Datensatz«und an der fehlenden Zeile mit einem leeren neuen Datensatz.

16 Aktualisierbarkeit von Abfragen 141 Nicht aktualisierbare Abfragen Nachfolgend finden Sie Beispiele für Abfragen, die niemals aktualisierbar sind: Abfragen mit zwei nicht verknüpften Tabellen. Beispiele sind alle Abfragen, die alle Kombinationen aus den Datensätzen zweier Tabellen anzeigen sollen (siehe Abbildung 3.10). Abfragen mit drei oder mehr Tabellen, deren innere Tabelle die 1-Seite für die beiden äußeren Tabellen stellt. Beispiel: Sie möchten zu einem Mitarbeiter gleichzeitig die Abwesenheiten und den Urlaubsanspruch ausgeben (siehe Abbildung 3.11). Abfragen mit Gruppierungen und Aggregatfunktionen Abfragen, bei denen die Eigenschaft Keine Duplikate auf Ja eingestellt ist Sollte sich einmal eine Abfrage als nicht aktualisierbar erweisen, von der Sie es eigentlich erwarten, prüfen Sie diese zunächst auf die oben genannten Eigenschaften. Abbildung 3.10: Diese Abfrage liefert kein aktualisierbares Ergebnis. Abbildung 3.11: Auch diese Abfrage ist nicht aktualisierbar.

17 142 3 Abfragen 3.3 UNION-Abfragen UNION-Abfragen bieten die Möglichkeit, die Daten mehrerer gleichartig aufgebauter Tabellen mit einer Abfrage zu vereinen. Dazu erstellen Sie zwei oder mehr gleichartig aufgebaute Abfragen und verketten diese mit dem UNION-Schlüsselwort. Entscheidend ist, dass alle beteiligten Abfragen die gleiche Anzahl Felder haben und dass die jeweils an der gleichen Stelle befindlichen Felder den gleichen Datentyp besitzen. Haben die Daten verschiedene Datentypen, konvertiert Jet in den meisten Fällen beide in einen Variant-Wert und gibt anschließend einen String-Wert aus. Probleme gibt es hier, wenn GUIDs und andere Datentypen gemischt werden. Weitere Grundlagen zu UNION-Abfragen finden Sie weiter hinten in Kapitel 7, Abschnitt 7.2.9,»Zusammenfassen von Abfrageergebnissen mit UNION« UNION-Abfragen zur Optimierung von Kombinationsfeldern Sie können eine UNION-Abfrage beispielsweise dazu verwenden, Kombinationsfelder zu optimieren. Wenn Kombinationsfelder keinen Eintrag enthalten, zeigen diese ein leeres Feld an. Praktischer und eine eindeutige Aufforderung an den Benutzer wäre es, wenn Kombinationsfelder ohne Wert etwa die Zeichenkette <Auswählen> anzeigen würden (siehe Abbildung 3.12). Abbildung 3.12: Vorgefülltes Kombinationsfeld Als Datensatzherkunft des Kombinationsfeldes dient dabei die folgende SQL-Abfrage, die Sie direkt in die SQL-Ansicht der Abfrage eingeben müssen: SELECT 0 AS AbteilungID, '<Auswählen>' AS Abteilung FROM tblabteilungen UNION SELECT AbteilungID, Abteilung FROM tblabteilungen; Dies ist ein gutes Beispiel für die Zweckentfremdung einer UNION-Abfrage, denn der aus dem ersten Teil der Abfrage stammende Wert ist eigentlich gar nicht in der Tabelle vorhanden. Deshalb gibt man dort nicht nur die Feldnamen, sondern die konkreten

18 UNION-Abfragen 143 Werte an. Der Übersicht halber versieht man die einzelnen Feldwerte noch mit dem AS-Schlüsselwort und fügt den eigentlichen Feldnamen hinzu. Letzteres ist aber nicht unbedingt notwendig. Wenn Sie einen Dummy-Datensatz wie im ersten Teil der obigen UNION-Abfrage benötigen, brauchen Sie in allein stehenden Tabellen nur den ersten Teil der Abfrage zu verwenden: SELECT 0 AS AbteilungID, '<Auswählen>' AS Abteilung. Die Angabe einer Ursprungstabelle mit FROM tblabteilungen ist nur in Zusammenhang mit UNION-Abfragen erforderlich. Wichtig ist bei diesem Beispiel, dass der im ersten Abfrageteil verwendete Wert für die gebundene Spalte der zukünftigen Datensatzherkunft kleiner ist als alle Werte, die aus der oder den anderen Tabellen noch hinzukommen. Anderenfalls lässt sich nur schwer eine sinnvolle Sortierung festlegen es sei denn, man fügt noch ein individuelles Sortierfeld hinzu. Wenn Sie hingegen nach dem angezeigten Feld sortieren möchten, müssen Sie erstens das Sortierkriterium an den letzten Teil der UNION-Abfrage anhängen und zweitens dafür sorgen, dass der ohne Auswahl angezeigte Datensatz der erste unter der angegebenen Sortierung ist: SELECT 0 AS AbteilungID, '<Auswählen>' AS Abteilung FROM tblabteilungen UNION SELECT AbteilungID, Abteilung FROM tblabteilungen ORDER BY Abteilung; Da das Kleiner-Zeichen (<) im ASCII-Code vor den Buchstaben angeordnet ist, sind hier keine weiteren Maßnahmen erforderlich. Wollten Sie hingegen nur den Eintrag Auswählen ohne spitze Klammern verwenden, müssten Sie ein zusätzliches Sortierfeld anhängen, bei dem Sie für den ersten Teil der Abfrage einen Wert angeben, der auf jeden Fall vor allen anderen liegt. Außerdem legen Sie dieses Sortierfeld als ORDER BY-Kriterium fest: SELECT 0 AS AbteilungID, 'Auswählen' AS Abteilung, 'AAAA' AS Sortierung FROM tblabteilungen UNION SELECT AbteilungID, Abteilung, Abteilung As Sortierung FROM tblabteilungen ORDER BY Sortierung; Eindeutige Schlüssel mit UNION-Abfragen Einen gravierenden Nachteil haben UNION-Abfragen: Wenn die zumeist aus mehreren Tabellen zusammengeführten Daten eindeutig identifiziert werden sollen, um etwa einen ausgewählten Datensatz zu löschen, ist»hängen im Schacht«. Das Problem

19 144 3 Abfragen ist, dass auch die Primärschlüssel aus mehreren Tabellen zusammengeführt werden und diese daher nicht zwangsläufig eindeutig sind, denn es können durchaus mehrere Tabellen etwa den Schlüsselwert 1 besitzen. Die einfachste Lösung ist die Verwendung von GUIDs als Primärschlüssel. Diese Werte sind nicht nur über mehrere Tabellen, sondern sogar weltweit eindeutig sofern sie mit der entsprechenden Systemfunktion erzeugt wurden (weitere Informationen finden Sie in Kapitel 2, Abschnitt 2.5,»Autowerte als Long oder GUID?«). Selbst das Löschen eines Datensatzes, der aus einer UNION-Abfrage ausgewählt wurde, ist bei Vorhandensein einer GUID einfach: Löschen Sie einfach aus allen beteiligten Tabellen den Datensatz mit der betroffenen GUID irgendwo werden Sie schon den richtigen treffen und falsche Datensätze löschen Sie damit auch nicht. Ohne GUID ist die eindeutige Identifikation von Daten aus UNION-Abfragen noch schwieriger. Als Beispiel dient die folgende Abfrage: SELECT KundeID, Vorname, Nachname FROM tblkunden UNION SELECT MitarbeiterID, Vorname, Nachname FROM tblmitarbeiter; Abbildung 3.13 zeigt auf, was passieren kann: Der Wert 3 kommt in je einem Datensatz der beteiligten Tabellen vor. Abbildung 3.13: UNION-Abfragen garantieren keinen eindeutigen Index. Um dies zu verhindern, verwenden Sie einen kombinierten Wert aus KundeID beziehungsweise MitarbeiterID und dem jeweiligen Tabellennamen. Die UNION-Abfrage sieht nun so aus: SELECT 'Kunde' & KundeID AS PersonID, Vorname, Nachname FROM tblkunden UNION SELECT 'Mitarbeiter' & MitarbeiterID AS PersonID, Vorname, Nachname FROM tblmitarbeiter;

20 Suchen in m:n-beziehungen 145 Das Ergebnis überzeugt ebenfalls, die Datensätze verfügen nun über ein eindeutiges Feld (siehe Abbildung 3.14). Abbildung 3.14: Eine UNION-Abfrage mit eindeutigem Feld Gegenüber der Variante mit dem GUID-Wert als Primärschlüssel fällt diese Variante jedoch deutlich ab. Allein das Handling ist wesentlich aufwändiger: Wenn Sie etwa einen mit dieser UNION-Abfrage ausgewählten Datensatz löschen möchten, müssten Sie zunächst über den zusammengesetzten Schlüssel ermitteln, aus welcher Tabelle der Datensatz stammt, und diesen dann dort löschen. Daraus resultiert letzten Endes die Empfehlung, Daten, die gleich aufgebaut sind, auch in einer einzigen Tabelle zu speichern. Wenn die Daten gelegentlich unterschiedliche Eigenschaften aufweisen und daher unterschiedliche Felder benötigen, lässt sich dies über 1:1-Beziehungen vermutlich leichter realisieren INSERT INTO mit UNION-Abfragen Abfragen sind nun einmal nichts Beständiges und deshalb sind auch die mit einer UNION-Abfrage ermittelten Daten grundsätzlich erst einmal nicht zur Weitergabe geeignet. Jeglicher Versuch, die Daten per INSERT INTO-Abfrage einfach in eine temporäre Tabelle zu schreiben, schlägt fehl: SQL mag keine INSERT-Queries mit UNION- Abfragen als Datenherkunft (siehe Abbildung 3.15). Die Lösung ist, wie in Abbildung 3.16 die UNION-Abfrage zu speichern und die Anfügeabfrage auf diese Abfrage zugreifen zu lassen. 3.4 Suchen in m:n-beziehungen Wenn Sie die Anleitungen zur Normalisierung in Kapitel 2 sorgfältig berücksichtigen, dann haben Sie beispielsweise eine Menge triviale Eigenschaften, zu denen jederzeit neue hinzukommen können, in eine m:n-beziehung ausgelagert. Das dortige Beispiel bezog sich auf Fahrzeuge und ihre Ausstattungsmerkmale.

21 146 3 Abfragen Abbildung 3.15: UNION-Abfragen in INSERT INTO-Statements funktionieren nicht. Abbildung 3.16: INSERT INTO mit UNION-Abfrage Nach diesem Schritt haben Sie zwar ein sauberes Datenmodell, aber dummerweise lässt sich nicht mehr so einfach per Abfrage ermitteln, welche Autos beispielsweise mit einer Klimaanlage und Servolenkung ausgestattet sind, aber etwa kein Navigationssystem besitzen. Hätte man in der Version mit allen Eigenschaften in einer einzigen Tabelle nur die entsprechenden Felder mit Kriterien wie True oder False ausstatten müssen, ist nun ein wenig mehr Aufwand notwendig. Suchen von Rezepten mit bestimmten Zutaten Als Beispiel dient nun aber eine neue Variante: Die Zuordnung von Zutaten zu einzelnen Rezepten. Stellen Sie sich vor, was Sie alles anstellen könnten, wenn Sie nur noch in Kühl- und Vorratsschrank schauen, die dort vorhandenen Zutaten in ein Formular eingeben (ok, nicht alle, aber zumindest die, auf die Sie gerade Appetit haben) und dann umgehend alle Rezepte erhalten, die sich mit diesen Zutaten zaubern lassen.

22 Suchen in m:n-beziehungen 147 Betrachtet man das Datenmodell aus Abbildung 3.17, fällt einem nur leider gerade kein Rezept ein, auf dessen Basis man die passende Abfrage basteln könnte. Abbildung 3.17: Aufbau der Beziehung zwischen Rezepten und Zutaten Mit einer Zutat jedenfalls funktioniert der Ansatz aus Abbildung Das Ergebnis liefert alle Rezepte, welche die Zutat»Pfeffer«enthalten das ist einfach. Abbildung 3.18: Abfrage zur Ermittlung aller Rezepte mit einer bestimmten Zutat Jetzt fügen Sie eine Zutat hinzu: Mal sehen, welche Rezepte übrig bleiben, wenn auch noch Salz enthalten sein soll. Nur wohin mit dem neuen Kriterium? Wenn man es ganz naiv als»oder«-kriterium in die Spalte Zutat einfügt, enthält das Abfrageergebnis mehr Datensätze als vorher das war abzusehen und ist falsch. Schließlich sollte eine weitere Zutat die Ergebnismenge einschränken oder maximal gleich viele Ergebnisse zurückliefern. Also verwenden Sie als Kriterium nun ="Pfeffer" Und "Salz". Das Ergeb-

23 148 3 Abfragen nis? Es enthält gar keine Datensätze mehr. Gibt es keine Rezepte, die Pfeffer und Salz enthalten? Doch, natürlich, aber es gibt bei keinem Rezept ein Zutatenfeld, das zwei Zutaten gleichzeitig enthält. Schauen Sie sich noch einmal genauer das Ergebnis der Variante mit»oder«an (siehe Abbildung 3.19). Logischerweise sind dort alle Rezepte, die beide angegebenen Zutaten enthalten, zweimal aufgeführt; alle Rezepte, die nur eine der beiden Zutaten enthalten, findet man nur einmal. Abbildung 3.19: Ergebnis der»oder«-variante der Zutaten-Suche Damit lässt sich doch etwas anfangen. Gleiche Einträge in einer Abfrage lassen sich gruppieren und zu einer Gruppierung lässt sich auch die Anzahl der enthaltenen Datensätze ausgeben. Passen Sie also die Abfrage wie in Abbildung 3.20 an: 1. Blenden Sie mit dem Menüeintrag Ansicht/Funktionen bei aktivierter Entwurfsansicht die Funktionszeile ein. 2. Stellen Sie für das Feld RezeptID die Funktion Anzahl ein. 3. Das Feld Zutat dient nur als Bedingung und darf nicht angezeigt werden. Dazu deaktivieren Sie die Zeile Anzeigen und stellen als Funktion den Wert Bedingung ein. Das Ergebnis aus Abbildung 3.21 überzeugt: Die Rezepte, die beide Zutaten enthalten, werden mit der Anzahl 2 ausgegeben. Damit erhalten Sie nicht nur die Rezepte mit allen gewünschten Zutaten, sondern auch andere und zwar nach der Qualität des Treffers sortiert.

24 Handhabung von 1:1-Beziehungen 149 Abbildung 3.20: Diese Abfrage sortiert die Rezepte nach der Anzahl der enthaltenen Wunschzutaten. Abbildung 3.21: Rezepte und die Anzahl der enthaltenen Wunschzutaten 3.5 Handhabung von 1:1-Beziehungen In Kapitel 2, Abschnitt 2.4.7,»1:1-Beziehungen«haben Sie erfahren, wie Sie Daten von Tabellen in zwei oder mehr per 1:1-Beziehung verknüpfte Tabellen aufteilen. Offen ist noch, wie Sie mit solchen Tabellen arbeiten, wenn es um die Eingabe, das Bearbeiten und Löschen von Daten geht. Mit einer geeigneten Abfrage lassen sich die Daten in per 1:1-Beziehung verknüpften Tabellen genau so bearbeiten wie die Daten einer einzelnen Tabelle.

25 150 3 Abfragen Als Beispiel dient die in Kapitel 2 vorgestellte Beziehung, bei der die erste Tabelle der 1:1-Beziehung Personendaten und die zweite Tabelle Erweiterungsdaten zu den in der ersten Tabelle enthaltenen Daten enthält (siehe Abbildung 3.22). Abbildung 3.22: 1:1-Beziehung zwischen Personen auf der einen und Angestellten und freien Mitarbeitern auf der anderen Seite Für die Bearbeitung ist lediglich interessant, ob Sie Personen mit der Ausprägung»Angestellter«oder mit der Ausprägung»freier Mitarbeiter«behandeln möchten. Wenn Sie die Daten der Angestellten bearbeiten wollen, verwenden Sie die in Abbildung 3.23 abgebildete Abfrage. Die Abfrage enthält alle Felder der beiden Tabellen mit Ausnahme des Primärschlüsselfeldes der Tabelle tblangestellte. Auch das Fremdschlüsselfeld dieser Tabelle muss nicht angezeigt werden, aber zu Beispielzwecken sollten Sie es einbauen. In der Abbildung enthält die Abfrage aus Platzgründen nur die wichtigsten Felder der zugrunde liegenden Tabellen. Wenn Sie die Abfrage in der Datenblattansicht anzeigen, können Sie dort Daten wie in einer ganz normalen Tabelle einfügen. Dabei kann allerdings folgendes Problem entstehen: Geben Sie einmal nur Daten in Felder der Tabelle tblpersonen ein (also etwa Vorname und Nachname), schließen Sie die Abfrage und öffnen Sie diese erneut. Der Datensatz scheint verschwunden, zumindest ist er im Sinne der 1:1-Beziehung nicht vorhanden. Der Grund ist ganz einfach: Mit der getätigten Eingabe wird in der Tabelle tblangestellte kein Datensatz angelegt und die Abfrage zeigt nur jene Kombinationen von Datensätzen der Tabellen tblpersonen und tblangestellte an, bei denen der Inhalt des Feldes PersonID in beiden Tabellen gleich ist. Den Beweis liefert ein kurzer Blick in die Tabelle tblpersonen: Dort findet sich nämlich der frisch angelegte Datensatz, allein das Pendant in der Tabelle tblangestellte fehlt.

26 Handhabung von 1:1-Beziehungen 151 Abbildung 3.23: Zusammenführen der Tabellen einer 1:1-Beziehung per Abfrage Geben Sie nun einen kompletten Datensatz ein und füllen Sie die Felder von links nach rechts, werden Sie feststellen, dass das Feld PersonID der Tabelle tblangestellte automatisch mit dem gleichen Wert wie in der Tabelle tblpersonen gefüllt wird, sobald Sie die Eingabe in eines der Felder der Tabelle tblangestellte abgeschlossen haben (siehe Abbildung 3.24). Abbildung 3.24: Das Eingeben von Daten Wenn Sie zuerst ein Feld der Tabelle tblangestellte füllen, erhält das Feld PersonID dieser Tabelle zunächst den Wert 0. Erst wenn Sie mindestens ein Feld der Tabelle tblpersonen gefüllt haben, erhalten beide PersonID-Felder den über die Tabelle tblpersonen generierten Autowert. Bleibt die letzte Möglichkeit: Sie füllen lediglich die Felder der Tabelle tblangestellte und versuchen, den Datensatz zu speichern. Dies lässt Access nicht zu: Es weist mit einer entsprechenden Meldung darauf hin, dass zunächst ein passender Datensatz in der Tabelle tblpersonen angelegt werden muss (siehe Abbildung 3.25).

27 152 3 Abfragen Abbildung 3.25: Diese Meldung erscheint, wenn Sie unvollständige Daten in eine Abfrage mit zwei per 1:1-Beziehung verknüpften Daten eingeben. Wie sorgen Sie nun dafür, dass vor dem Speichern alle benötigten Daten eingegeben werden, ohne dass Access seine eigenen Meldungen anzeigt? In der Abfrage funktioniert dies gar nicht: Es besteht keine Möglichkeit, die Meldung aus Abbildung 3.25 abzufangen weder durch Setzen der Eingabe erforderlich-eigenschaft noch durch die Verwendung der Gültigkeitsregel. Das ist aber auch nicht schlimm, denn wie bereits erwähnt, sollen Tabellen und Abfragen ohnehin nicht zur direkten Dateneingabe verwendet werden. Und in den dafür vorgesehenen Formularen gibt es sowieso ganz andere Mittel. Mehr dazu erfahren Sie in Kapitel 4, Abschnitt 4.4.5,»1:1-Beziehungen«. Behandlung von 1:1-Beziehungen mit ergänzenden Feldern Die oben vorgestellte 1:1-Beziehung dient dem»vererben«der in der Tabelle tblpersonen gespeicherten Eigenschaften an speziellere Personentypen wie Angestellte oder freie Mitarbeiter. Es gibt auch 1:1-Beziehungen mit wesentlich weniger anspruchsvollem Hintergrund. Die 1:1-Beziehung aus Abbildung 3.26 dient beispielsweise nur dazu, einer Tabelle ein Drucken-Feld hinzuzufügen, ohne dass die Tabelle tatsächlich erweitert wird. Die passende Verknüpfung sieht wie in Abbildung 3.26 aus. Wenn Sie die beiden Tabellen so wie in Abbildung 3.27 in den Abfrageentwurf übernehmen, werden Sie nach dem Wechsel in die Datenblattansicht ein leeres Abfrageergebnis vorfinden (zumindest, wenn Sie noch keine Datensätze in der Tabelle tblmitarbeiterdrucken angelegt haben). Der Grund ist einfach: Die Abfrage zeigt nur Daten, für die in beiden Tabellen ein Datensatz vorliegt. Da die Tabelle tblmitarbeiterdrucken im Urzustand zunächst keine Daten enthält, ist das Abfrageergebnis noch leer. Leider lässt sich über diese Abfrage auch kein Datensatz zur Tabelle tblmitarbeiterdrucken hinzufügen. Um dies zu ermöglichen, ändern Sie in der Abfrage den Beziehungstyp wie in Abbildung 3.28 und erzeugen somit einen LEFT JOIN. Damit werden nun definitiv alle Datensätze der Tabelle tblmitarbeiter angezeigt, auch wenn es nicht für alle einen verknüpften Datensatz in der Tabelle tblmitarbeiterdrucken gibt.

28 Handhabung von 1:1-Beziehungen 153 Abbildung 3.26: 1:1-Beziehung zum Anfügen eines einzelnen Feldes Abbildung 3.27: Abfrage mit Drucken-Feld in der Entwurfsansicht Nun sieht die Datenblattansicht der Abfrage schon wesentlich erfreulicher aus: Zu jedem Mitarbeiter wird das Drucken-Feld angezeigt, obwohl es eigentlich gar keine verknüpften Datensätze gibt. In der Tabelle tblmitarbeiterdrucken wird dann auch tatsächlich erst ein Datensatz angelegt, wenn Sie in der Abfrage einen Haken in das entsprechende Feld setzen (siehe Abbildung 3.29).

29 154 3 Abfragen Abbildung 3.28: Ändern der Verknüpfungseigenschaften Wenn Sie das Feld in der Abfrage wieder deaktivieren, bleibt der Datensatz in der Tabelle tblmitarbeiterdrucken allerdings vorhanden. Um Platz in der Datenbank zu schaffen, empfiehlt es sich daher, regelmäßig alle Datensätze aus der Tabelle tblmitarbeiterdrucken zu entfernen, deren Feld Drucken den Wert False enthält. Abbildung 3.29: Das Drucken-Feld ist für alle Mitarbeiter verfügbar. 3.6 Extremwerte per Abfrage ermitteln Unterabfragen sind oft ein bewährtes Mittel, um Kriterien für Abfragen zu ermitteln sei es zur Ermittlung nur eines oder auch mehrerer Kriterien (IN-Operator). Besonders interessant ist die Möglichkeit, in einer Unterabfrage auf den Inhalt des in der Hauptabfrage enthaltenen Datensatzes zuzugreifen. So lassen sich beispielsweise Informationen ermitteln, die auf eine Gruppe von Datensätzen bezogen sind.

30 Extremwerte per Abfrage ermitteln 155 Extremwert einer Gruppierung ermitteln Ein Beispiel sind Extremwerte von Gruppierungen. Wenn Sie in den Tabellen Artikel und Kategorien der Nordwind-Datenbank den teuersten Artikel einer Kategorie ermitteln möchten, ist das kein Problem. Die Abfrage aus Abbildung 3.30 hilft dann weiter hier wird beispielsweise der höchste Preis eines Artikels der Kategorie»Getränke«ermittelt. Abbildung 3.30: Ermitteln des maximalen Preises von Artikeln der Kategorie Getränke Leider gibt die Abfrage nur den Preis, aber keine weiteren Informationen zum Namen des Artikels aus, da das Ergebnis über eine Gruppierung herbeigeführt wurde. Sie können noch nicht einmal das Abfrageergebnis als Unterabfrage einer Abfrage verwenden, die dann alle gewünschten Daten enthält, da diese Unterabfrage kein eindeutiges Feld enthielte. Extremwert per TOP und ORDER BY Also tricksen Sie ein wenig: Verwenden Sie statt der Gruppierung eine nach dem Preis sortierte Abfrage und die TOP-Option der SELECT-Klausel, um nur den ersten und damit teuersten Datensatz zurückzugeben (siehe Abbildung 3.31).

31 156 3 Abfragen Abbildung 3.31: Variante 2 zur Ermittlung des teuersten Artikels der Kategorie»Getränke«Extremwerte per Unterabfrage Diese Abfrage liefert das richtige Ergebnis einschließlich Artikelinformationen zurück. Im nächsten Schritt sollen nun in einer Abfrage alle teuersten Artikel ihrer Kategorie ausgegeben werden und hier kommen die korrelierten Haupt- und Unterabfragen zum Zuge. Zum besseren Verständnis findet noch ein Zwischenschritt statt: Die Abfrage aus Abbildung 3.32 enthält eine Unterabfrage zur Ermittlung des teuersten Artikels, dessen Detaildaten in der Hauptabfrage angezeigt werden. Abbildung 3.32: Variante zum Ermitteln des teuersten Artikels über eine Unterabfrage

32 Datensätze mehrfach anzeigen 157 Extremwerte von Gruppierungen Von dieser Abfrage aus gelangen Sie mit wenigen Änderungen zu einer Variante, die die teuersten Artikel einer jeden Kategorie anzeigt. Dazu müssen Sie eine zusätzliche Beziehung zwischen der Haupt- und der Unterabfrage einbauen, die dazu führt, dass die Unterabfrage jeweils den teuersten Artikel der Kategorie des aktuellen Datensatzes des Hauptformulars zurückgibt. Hört sich kompliziert an, ist es aber nicht: Dazu müssen Sie lediglich die Tabellen in Haupt- und Unterabfrage mit einem Alias-Namen versehen und die Inhalte des Feldes Kategorie-Nr der beiden Abfragen gleichsetzen. Der SQL-Ausdruck dieser Abfrage sieht wie folgt aus: SELECT t1.[artikel-nr], t1.artikelname, t1.einzelpreis FROM Artikel AS t1 WHERE t1.[artikel-nr]=( SELECT TOP 1 t2.[artikel-nr] FROM Artikel AS t2 WHERE t1.[kategorie-nr] = t2.[kategorie-nr] ORDER BY t2.einzelpreis DESC ); In der Entwurfsansicht sieht die Abfrage wie in Abbildung 3.33 aus. Das Ergebnis ist in Abbildung 3.34 abgebildet. Abbildung 3.33: Korrelierte Haupt- und Unterabfrage zur Ermittlung des teuersten Artikels je Kategorie 3.7 Datensätze mehrfach anzeigen Für manche Aufgaben kann es erforderlich sein, Datensätze mehr als einmal auszugeben das Paradebeispiel ist wohl die Ausgabe eines Berichtes mit Adressetiketten. Es gibt einige Lösungen, die dieses Problem per VBA-Code angehen. Es funktioniert aber auch mit einer ausgefeilten Abfrage. Voraussetzung ist, dass sich ein Feld mit der auszugebenden Anzahl in der Tabelle befindet.

33 158 3 Abfragen Abbildung 3.34: Ergebnis der korrelierten Unterabfrage Außerdem benötigen Sie eine Tabelle, die lediglich ein einziges Feld namens Anzahl enthält, das mit den Zahlen von 0 bis 10 (oder der maximalen Anzahl vorgesehener Exemplare) gefüllt ist (siehe Abbildung 3.35). Abbildung 3.35: Die Kombination dieser beiden Tabellen liefert die im Feld Anzahl der Mitarbeitertabelle angegebenen Exemplare eines jeden Datensatzes. Abbildung 3.36 zeigt, wie Sie die Tabellen zusammenführen müssen. Beim Hinzufügen der beiden Tabellen fügt Access gegebenenfalls eine Verknüpfung zwischen den gleichnamigen Feldern (Anzahl) hinzu, diese entfernen Sie umgehend wieder. Dadurch zeigt Access alle Kombinationen der Datensätze aus der ersten und der Datensätze aus der zweiten Tabelle an. Das sind natürlich ein paar zu viel: Daher schränken Sie die Ergebnismenge noch ein wenig ein. Ziehen Sie neben den auszugebenden Daten das Feld Anzahl der Tabelle tblanzahl in das Entwurfsraster nicht jedoch das der Mitarbeitertabelle (!) und fügen Sie diesem Feld das Kriterium aus der Abbildung hinzu.

34 Datensätze mehrfach anzeigen 159 Somit enthält das Abfrageergebnis alle Kombinationen der Datensätze, für die das Feld Anzahl der Tabelle tblanzahl kleiner als die in der Mitarbeitertabelle angegebene Anzahl ist. Abbildung 3.36: Abfrage zur Anzeige einer bestimmten Anzahl je Datensatz Abbildung 3.37 zeigt das nach dem Feld MitarbeiterID sortierte Abfrageergebnis. Abbildung 3.37: Das Abfrageergebnis enthält jeden Datensatz in der gewünschten Anzahl. Die letzte Spalte zeigt den jeweiligen Wert des Feldes Anzahl der Tabelle tblanzahl.

35 160 3 Abfragen 3.8 Nummerierung von Datensätzen Felder wie der Primärindex taugen in den seltensten Fällen zum Bereitstellen einer lückenlosen Nummerierung von Datensätzen. Erstens sorgt jeder gelöschte Datensatz für eine Lücke (sofern es sich nicht um den letzten Datensatz handelt) und zweitens sollte eine Nummerierung auch mal eine Umsortierung oder das Setzen eines Kriteriums mitmachen. Da hierzu eine gewisse Dynamik erforderlich ist, funktioniert dies nur in Verbindung mit einer Abfrage auf Basis der zu nummerierenden Tabelle. Die Abfrage verwendet einen Ausdruck, der die Anzahl der vor dem aktuellen Datensatz liegenden Datensätze berechnet (siehe Abbildung 3.38). Das Ergebnis der Abfrage finden Sie in Abbildung Abbildung 3.38: Nummerieren von Daten ohne Sortierung und Gruppierung Abbildung 3.39: Nummerierte Datensätze per Abfrage

36 Nummerierung von Datensätzen 161 Alternative: Nummerieren per Unterabfrage Die gleiche Abfrage können Sie mit einem anderen Nummerierungsfeld ausstatten. Diesmal verwenden Sie eine Unterabfrage: Nummer: (SELECT Count(*) FROM Artikel As Temp WHERE Temp.[Artikel-Nr] < Artikel.[Artikel-Nr])+1 Ausnahmsweise ist die Alternative mit der Domänen-Funktion mal nicht die langsamere. Die Variante mit DCount ist je nach Datensatzmenge bis zu ca. 10% schneller als die Version mit der Unterabfrage. Nummerierung von Abfrageergebnissen mit alternativen Sortierungen Wenn die Daten nach einem anderen Feld als dem Primärschlüsselfeld der Tabelle sortiert werden sollen, geben Sie im WHERE-Teil der Unterabfrage einfach auf beiden Seiten der Bedingung das gewünschte Feld an und legen die Sortierung auch in der Hauptabfrage fest. Nummerierung von Abfrageergebnissen mit eingeschränkten Ergebnismengen Wenn das zu nummerierende Abfrageergebnis Kriterien enthält, fügen Sie diese auch der Unterabfrage hinzu. Um alle Artikel, deren Artikelname mit»c«beginnt, zu nummerieren, verwenden Sie die Abfrage aus Abbildung Der dort aus Platzgründen nicht vollständig abgebildete Nummer-Ausdruck lautet folgendermaßen: Nummer: (SELECT Count(*) FROM Artikel As Temp WHERE (Temp.Artikelname LIKE "C*") AND (Temp.[Artikelname] < Artikel.[Artikelname]))+1 Abbildung 3.40: Nummerierung einer sortierten und eingeschränkten Abfrage