Access 2010 Grundlagen für Entwickler - Addison-Wesley

3
Formulare
Formulare sind das wichtigste Element der Benutzer oberfläche von Access-An wen dungen.
Sie sorgen dafür, dass der Benutzer bei der Da ten eingabe nicht mit ellen langen
Tabellen oder Ab fragen mit Tausenden von Da ten sät zen han tieren muss, sondern die
Daten übersichtlich dar gestellt bekommt – je nach Anforderung als Liste oder Detailansicht.
Mit Kombinationsfeldern, Listenfeldern und Un ter for mu la ren lassen sich auch die
Daten ver knüpf ter Tabellen problemlos darstellen.
Der große Vorteil von Access-Formularen gegen über denen von Visual Basic oder den
.NET-Pro grammiersprachen liegt in den speziellen Funk tio nen für die Verwendung mit
Tabellen und Ab fragen als Datensatzquelle. Diese Tech ni ken sind mit dafür verantwort-

Kapitel 3 Formulare
lich, dass Access heute das am weitesten verbreitete Datenbank-Ma na ge ment system
für Windows-Rechner ist. Abgerundet wird dies durch die Möglichkeit, For mulare und
die enthaltenen Steuerelemente zu programmieren und dabei die zahlreichen Er eignisse
zu nutzen.
In diesem Kapitel erfahren Sie zunächst, welche Neue rungen Access 2010 in Zu sam menhang
mit For mularen mitbringt, und erhalten eine kleine Einführung in Formulare. Dann
geht es ans Eingemachte: Sie lernen, wie Sie Daten auf Basis einzelner oder verknüpfter
Tabellen in Abfragen darstellen können und wie Sie VBA zur Realisierung wichtiger
Funktionen wie etwa zur Suche von Da ten sät zen verwenden.
Das folgende Kapitel geht dann genauer auf die verschiedenen Steuerelemente ein, die
Sie in Formularen einsetzen können. Dort geht es nicht nur um die Stan dard steuer elemen
te von Access, sondern auch um Steuerelemente wie das ListView-, TreeView- oder
ImageList-Steuerelement.
Da alle in diesem Kapitel beschriebenen Funktionen mehr oder weniger den Einsatz
von VBA und Ereigniseigenschaften von Formularen und Steuerelementen benötigen,
finden Sie zunächst eine Beschreibung der wichtigsten Ereignisse und ihre Abfolge für
das Formular selbst und einige Steuerelemente.
164
BEISPIELDATENBANK
Die Beispieldatei zu diesem Kapitel finden Sie unter dem Namen Formulare.accdb
auf www.acciu.de/aeb2010.
3.1 Formulare in Access 2010
Microsoft hat sich eine Menge Features einfallen lassen, die das Erstellen von For mula
ren für Einsteiger vereinfachen. Es gibt aber auch Neuerungen, die dem alteingesessenen
Access-Entwickler das Leben erleichtern. Auch hier haben wir die Neuerungen
seit Access 2007 mit berücksichtigt, damit Umsteiger von Access 2003 und älter sich
direkt zurechtfinden. Beim Gang durch das Entwerfen von For mu la ren lernen Sie alles
Neue kennen.
3.1.1 Anlegen eines Formulars
Das schnelle Anlegen von Formularen erfolgt in Access 2010 mit dem passenden Ribbon-Befehl
auf Basis des aktuell markierten Tabellen- oder Abfrage-Objekts. Die Ribbon-Einträge
befinden sich sämtlich im Bereich Erstellen|Formulare. Die einfachste
Variante mit der Bezeichnung Formular erstellt automatisch ein einfaches Formular

Formulare in Access 2010
in der Ansicht Einzelnes Formular. Dabei berücksichtigt diese Funktion eventuelle Unter
da ten blätter der zugrunde liegenden Tabelle/Abfrage und legt dafür passende
Unterformulare auf Basis der verknüpften Ta bel len an.
Mit dem Eintrag Erstellen|Formulare|Geteiltes Formular legen Sie ein geteiltes Formular
an, das gleichzeitig eine Liste der Datensätze der zugrunde liegenden Tabelle oder Abfra
ge und die Detailansicht des aktuell ausgewählten Datensatzes anzeigt. Mehr zu geteilten
Formularen erfahren Sie weiter unten in »Geteilte Formulare« ab Seite 172.
Weitere Ribbon-Schaltflächen verheißen das schnelle Anlegen der gängigen Ansichten.
Wer's manuell mag, der klickt direkt auf den Ribbon-Eintrag Erstellen|Formulare|Formu
lar entwurf und legt selbst Hand an.
Gebundene und ungebundene Formulare
Üblicherweise verwendet man in Access Formulare, um Daten aus den zugrunde liegenden
Tabellen anzuzeigen, und das bedeutet, dass man das Formular an eine Tabelle
oder Abfrage bindet. Dazu stellt man die Eigenschaft Datensatzquelle entweder auf den
Namen einer Tabelle, den Namen einer Abfrage oder einen passenden SQL-Ausdruck
ein.
Natürlich kann es auch ungebundene Formulare geben – etwa, um den Benutzer mit
einem Startdialog einige nützliche Hinweise mit auf den Weg zu geben, dem Benutzer
statt eines Ribbons ein Übersichtsformular zum Steuern der Anwendung zu bieten oder
Informationen abzufragen – beispielsweise Such- oder Filterkriterien für die Anzeige
von Daten in Formularen oder Berichten. Solche Formulare unterscheiden sich lediglich
durch das Leerlassen der Eigenschaft Datensatzquelle von gebundenen Formularen.
Gebundene Felder über die Feldliste anlegen
Wenn Sie sich entschieden haben, ein Formular von Grund auf selbst anzulegen (also
ohne eine der Funktionen zum automatischen Einfügen etwa von Feldern oder der
Daten satzquelle), gehen Sie folgendermaßen vor: Nach dem Auswählen der Daten satzquelle
können Sie die darin enthaltenen Felder auf dem Formular platzieren. Wie Sie
diese anordnen, hängt im Wesentlichen davon ab, wie Sie die Daten darstellen möchten
und welchen Zweck das Formular hat. Grundsätzlich geschieht das aber immer gleich:
» Aktivieren Sie die Entwurfs- oder die Layoutansicht des Formulars.
» Klicken Sie auf den Ribbon-Eintrag Entwurf|Tools|Vorhandene Felder hinzufügen, um
die Feldliste anzuzeigen.
» Ziehen Sie die benötigten Felder aus der Feldliste (auch per Mehrfachauswahl) auf
den gewünschten Bereich des Formulars. Welche Bereiche es gibt und wozu diese
dienen, erfahren Sie weiter unten.
165

Kapitel 3 Formulare
Die Feldliste zur Auswahl der anzuzeigenden Felder hat sich im Vergleich zu älteren
Access-Versionen stark verändert. Zwar zeigt sie noch die Felder der ausgewählten Datensatzquelle
an, aber anders als gewohnt (siehe Abbildung 3.1): Die eigentliche Feldliste
im oberen Bereich enthält nicht nur die Felder der Datensatzquelle, sondern auch
noch die Angabe der passenden Tabelle. Im mittleren Bereich zeigt Access direkt mit
der Datensatzquelle verknüpfte Tabellen und ihre Felder an (falls Sie im Beziehungen-
Fenster entsprechende Beziehungen angelegt oder den Nachschlageassistenten damit
betraut haben) und im unteren Bereich die übrigen Tabellen. Falls die Feldliste nur die
Felder der aktuellen Datensatzquelle anzeigt, können Sie die Ansicht mit einem Klick
auf die Schaltfläche Alle Tabellen anzeigen erweitern.
Abbildung 3.1: Auswahl der im Formular anzuzeigenden Felder
Bei Feldern aus verknüpften Tabellen fügt Access diese Tabellen einfach der Da ten satzquelle
hinzu, indem es den passenden SQL-Ausdruck in der Eigenschaft Datensatzquelle
anpasst, bei nicht verknüpften Tabellen ist noch ein wenig Handarbeit notwendig: Sie
müssen dann in einem Dialog angeben, über welches Feld ein Bezug hergestellt werden
soll (siehe Abbildung 3.2).
Prinzipiell stellen Sie mit diesem Dialog nachträglich eine Verknüpfung her (wenn auch
nur auf Datensatzquellen-Ebene), die in der zugrunde liegenden Abfrage gespeichert
wird. Das ist ein interessantes Werkzeug, wenn man mal eben ein Feld nachreichen
möchte, das man beim Anlegen der Datensatzquelle vergessen hat. Die Frage ist, ob
dies bei Tabellen, die noch nicht verknüpft sind, sinnvoll ist – und gerade dazu ist der
Dialog wohl vorgesehen.
166

Formulare in Access 2010
Das Hinzufügen von Feldern aus bereits verknüpften Tabellen hingegen kann eine echte
Erleichterung sein: Wie oft passiert es, dass man Felder etwa aus Lookup-Tabellen wie
einer Anrede-Tabelle beim Zusammenstellen der Datensatzquelle außer Acht lässt und
diese sonst nachträglich anpassen müsste. Das geht nun schon wesentlich schneller,
indem man einfach das passende Feld aus dem mittleren Bereich der Feldliste in den
Entwurf zieht.
Abbildung 3.2: Nachträgliches Hinzufügen von Feldern aus nicht verknüpften Tabellen
Felder über Steuerelemente anlegen
Der zweite Weg, ein gebundenes Feld anzulegen, ist ein wenig aufwändiger. Er ist sinnvoll,
wenn Sie kein Textfeld für die Anzeige des Feldinhaltes benötigen, sondern auf ein
an deres Steuerelement zurückgreifen möchten. Bei Kombinations- und Listenfeldern
kann man dem vorbeugen, indem man die Nachschlage-Eigenschaften des zugrunde
liegenden Feldes entsprechend vorbereitet (mehr dazu unter »Beziehungen herstellen«
ab Seite 54 und folgende).
Auch für Boolean-Felder legt Access au to ma tisch ein Kontrollkästchen an. Vielleicht
möchten Sie aber auch einmal eine Op tions grup pe anlegen, um die Werte eines
Zahlenfeldes abzubilden, oder Sie benötigen ein Kom bi na tions- oder Listenfeld, ohne
dass Sie die Nachschlage-Eigenschaften des Ta bellenfelds ent sprechend eingestellt
haben. Dann klicken Sie einfach auf die passende Schalt fläche im Ribbon-Bereich
Entwurf|Steuerelemente und ziehen dann das Feld, dessen Inhalt das Steuerelement
anzeigen soll, in den Formularentwurf. Die Eigenschaft Steuerelementinhalt wird dann
gleich auf das entsprechende Feld eingestellt.
Formularbereiche
Der meistverwendete Formularbereich ist vermutlich der Detailbereich. Er enthält in
der Regel die an die Datensatzquelle gebundenen Steuerelemente – eben jene Felder,
die Sie aus der Feldliste auf das Formular ziehen können. Die hier enthaltenen Felder
zeigt Access in allen Ansichten an – in manchen sogar nur diese Felder und keine
Steuerelemente der anderen Bereiche.
167

Kapitel 3 Formulare
Formulare können außerdem einen Formularkopf und einen Formularfuß aufweisen.
Der Formularkopf ist beispielsweise gut für die Anzeige von Überschriften, berechneten
Werten wie dem Systemdatum oder Steuerelementen wie Schaltflächen geeignet.
Der Formularfuß enthält oft Ergebnisse von Berechnungen wie etwa der Anzahl der
im Detailbereich angezeigten Datensätze oder einer Rechnungssumme. Dort können
Sie auch – wie in vielen Windows-Anwendungen – die Schaltflächen zum Steuern des
Formulars unterbringen. Viele Benutzer sind es gewohnt, dort Schaltflächen mit Beschrif
tungen wie OK oder Abbrechen zu finden.
Die Bereiche Seitenkopf und Seitenfuß sind nur interessant, wenn Sie Formulare ausdrucken
wollen. Für das Ausdrucken von Daten sind unter Access aber Berichte verantwortlich;
sie bieten auch wesentlich bessere Möglichkeiten zur optimalen Darstellung
der Daten. Daher behandelt dieses Buch diese Bereiche an dieser Stelle nicht weiter.
Das Ein- und Ausblenden der verschiedenen Formularbereiche erledigen Sie mit den
Kontextmenüeinträgen Seitenkopf/­fuß und Formularkopf/­fuß.
3.1.2 Formularansichten
Bei einem Formular, das der Eingabe von Daten dient, werden Sie vermutlich nur jeweils
einen einzigen Datensatz anzeigen. Sie stellen dann die Eigenschaft Standardansicht auf
Einzelnes Formular ein.
Das ist nicht nur die Basis zur Eingabe, sondern auch zur Anzeige von Daten im Detail
sowie zum Bearbeiten von Datensätzen. Generell können Sie die Ansicht eines For mulars
im Ribbon unter Start|Ansichten oder über das Kontextmenü der Titelleiste eines
For mulars oder des Formularhintergrunds einstellen.
Entwurfsansicht
In der Entwurfsansicht eines Formulars passen Sie das Formular an: Sie fügen Steuerele
mente hinzu, stellen Eigenschaften wie Höhe, Breite oder Farben ein und ordnen die
Ele mente wie gewünscht an. Es würde den Rahmen dieses Kapitels sprengen, wenn
es alle Einzelheiten in Zusammenhang mit der Entwurfsansicht beschreiben sollte.
Deshalb beschränkt es sich auf die Neuheiten seit Access 2007 (für alle, die von
Access 2003 oder älter zu Access 2010 wechseln), die sich vor allem auf die verbesserte
Ausrichtung von Steuerelementen beziehen (siehe »Hilfreiche Funktionen für den
Formularentwurf« ab Seite 173).
Wenn Ihnen die Grundlagen beim Erstellen von Formularen mit der Entwurfsansicht
nicht geläufig sind, liefert die Onlinehilfe von Access allerdings gutes Material: Geben
Sie dort als Suchbegriff einfach »Formulare« ein und Sie erhalten eine umfangreiche
Liste mit allen möglichen Themen rund um die Erstellung von Formularen.
168

Layoutansicht
Formulare in Access 2010
Die Layoutansicht ist ein neues Feature, das mit Access 2007 eingeführt wurde. Es stellt
eine Art Zwischenstufe zwischen der Entwurfsansicht und der Formularansicht dar. In
dieser Ansicht zeigt ein Formular die zugrunde liegenden Daten an und lässt sich gleichzeitig
wie in der Entwurfsansicht bearbeiten. Der wichtigste Vorteil der Layoutansicht
ist, dass Sie Größe, Position und Formatierung der Steuerelemente auf die enthaltenen
Daten abstimmen können. Bisher war dazu ein stetiges Wechseln zwischen Entwurfs-
und Formularansicht notwendig.
Der Wert der Eigenschaft Layoutansicht zulassen (VBA: LayoutView) entscheidet, ob
Sie ein Formular grundsätzlich in der Layoutansicht anzeigen können. Wenn diese
Voraussetzung geschaffen ist, können Sie sie problemlos einsetzen, um wie in
Abbildung 3.3 die Breite von Steuerelementen in der Endlosansicht eines Formulars
den vorhandenen Inhalten anzupassen.
Abbildung 3.3: Anpassen der Breite von Steuerelementen in der Layoutansicht
Im Gegensatz zu Access 2007 können Sie nun einige Entwurfsaufgaben mehr in der
Layoutansicht erledigen – so lassen sich etwa Steuerelemente über die Steu er ele ment-
Schaltflächen im Ribbon-Bereich Entwurf|Steuerelemente hinzufügen. Sie können nun
auch Steuer ele men te duplizieren oder mit den Cursor-Tasten in Kombination mit der
Um schalt- und der Strg-Taste fein positionieren beziehungsweise ihre Größe anpassen.
Dies ist nun auch nötig, denn in Webdatenbanken steht nur noch die Layoutansicht
für den Entwurf von Formularen und Berichten zur Verfügung (mehr dazu unter
»Webdatenbanken« ab Seite 603).
Datenblattansicht
Die Datenblattansicht zeigt die im Detailbereich befindlichen gebundenen Felder genau
wie in der von Tabellen und Abfragen bekannten Datenblattansicht an. Steuerele
mente im Kopf- und Fußbereich stellt die Datenblattansicht nicht dar. Aus dem
Detailbereich fallen auch einige Steuerelementtypen weg. Angezeigt werden nur Text-
169

Kapitel 3 Formulare
fel der, Kombinationsfelder, Listenfelder (als Kombinationsfeld), Optionsfelder und Kontrollkästchen,
die nicht in Optionsgruppen organisiert sind, Optionsgruppen (allerdings
nur als Textfeld, nicht mit Optionsfeldern), Umschaltflächen (als Wert) und einige andere
Steuerelemente. Bezeichnungsfelder, die an eines der genannten Steuerelemente
gebunden sind, zeigt die Datenblattansicht als Spaltenkopf an.
In der Praxis werden Sie die Datenblattansicht wohl nie für eigenständige Formulare
einsetzen, sondern nur als Unterformular – auch, wenn Sie eigentlich nur Daten in der
Datenblattansicht anzeigen möchten. Der Grund ist ganz einfach: Die Datenblattansicht
ist sehr egoistisch und lässt keinen Platz für andere Steuerelemente. Wenn Sie eine
solche Ansicht etwa mit einem kleinen Suchfeld oder mit Schaltflächen zum Schließen
oder Abbrechen versehen möchten, müssen Sie eine Art »Rahmen-Formular« verwenden
und das Formular in der Datenblattansicht dort als Unterformular einbetten. Wie
das aussieht, sehen Sie in Abbildung 3.4. Weitere Informationen zu dieser Ansicht finden
Sie unter »Einfache Daten in der Übersicht als Datenblatt« ab Seite 205.
Abbildung 3.4: Ein Formular in der Datenblattansicht mit Formular-Rahmen zum Hinzufügen von
Schaltflächen
Die Datenblattansicht kommt auch oft zum Einsatz, wenn es um die Darstellung von
1:n- oder m:n-Beziehungen geht. Dabei zeigt dann ein Hauptformular die Da ten der
Detailtabelle und das Unterformular die Daten der Mastertabelle in der Da ten blattan
sicht an. Ein Beispiel sehen Sie in Abbildung 3.5, weitere Informationen zu dieser
Dar stellung finden Sie in »1:n-Beziehung per Unterformular und Datenblattansicht« ab
Seite 214.
Einfaches Formular
Diese Ansicht ist für die Anzeige der Details eines Datensatzes geeignet. Sie zeigt jeweils
einen einzigen Datensatz an. Im Gegensatz zur Datenblattansicht können Sie die
Steuer elemente ganz nach Ihren Wünschen auf die Bereiche des Formulars aufteilen
und – noch wichtiger – Sie können alle Steuerelemente einsetzen, die Access hergibt.
Be sonders interessant sind dabei Listenfelder und Unterformulare, mit denen Sie die
struk turierte Anzeige von Daten aus mehreren verknüpften Tabellen anzeigen können.
170

Abbildung 3.5: Für Unterformulare bietet sich oft die Datenblattansicht an
Endlosformular
Formulare in Access 2010
Endlosformulare sind prinzipiell einfache Formulare, von denen Sie aber mehrere
gleichzeitig (und zwar untereinander) anzeigen können. Damit können Sie einige
Nachteile der Datenblattansicht ausmerzen: So lassen sich auch hier beliebige
Steuerelemente anzeigen. Eine Ausnahme sind Unterformulare: Diese können Sie nicht
in der Endlosansicht eines Formulars einsetzen. Um mit einem Endlosformular ein
Formular in der Datenblattansicht nachzubauen, brauchen Sie nur die Steuerelemente
genauso wie in der Datenblattansicht anzuordnen, passende Beschriftungsfelder im
Formularkopf zu platzieren und die Höhe des De tail be reichs entsprechend zu verkleinern.
Das kann etwa so wie in Abbildung 3.6 aussehen (weitere Informationen zu dieser
Ansicht finden Sie unter »Einfache Daten in der Übersicht mit Endlosformularen« ab
Seite 201). Eine solche Endlosansicht können Sie natürlich auch als Unterformular einsetzen,
um eine 1:n- oder m:n-Beziehung darzustellen.
Abbildung 3.6: Ein Endlosformular als Ersatz für die Datenblattansicht
PivotTable- und PivotChart-Ansicht
Diese beiden Ansichten bietet Access seit der Version XP an. Sie bieten eine recht gute
Entwurfsansicht, mit der sich schnell ansprechende Ergebnisse erzielen lassen. Aller-
171

Kapitel 3 Formulare
dings sind diese beiden Ansichten in Zusammenhang mit größeren Datenmengen recht
lang sam. Da das Interesse seitens der Access-Entwickler an diesen Ansichten relativ
gering ist, geht dieses Buch nicht näher darauf ein.
3.1.3 Geteilte Formulare
Seit Access 2007 gibt es einige Eigenschaften, mit denen Sie Formulare zur Anzeige
von Daten in Listen- und Detailansicht aufteilen können. Sicher haben Sie schon einmal
ein Unterformular oder ein Listenfeld in einem Formular verwendet, um eine
Über sicht über Datensätze – etwa von Mitarbeiterdaten – anzuzeigen und darüber die
Aus wahl eines Datensatzes zur Anzeige der Detaildaten in einem anderen Bereich des
Formulars einzublenden.
Hierzu ist VBA-Programmierung notwendig, und Microsoft hat mit den sogenannten
»Split Forms« eine Möglichkeit geschaffen, dies durch einfaches Anpassen einiger
Eigenschaften zu erreichen. (Natürlich können Sie dies auch per Assistenten durchführen,
aber diese kleinen Helfershelfer will dieses Buch ja beiseite lassen ...)
Grundvoraussetzung für das Teilen eines Formulars ist das Einstellen der Eigenschaft
Standardansicht auf den neuen Wert Geteiltes Formular (siehe Abbildung 3.7).
Abbildung 3.7: Mit der richtigen Einstellung für die Eigenschaft Standardansicht erreichen Sie die
Anzeige eines geteilten Formulars
Haben Sie diese Eigenschaft eingestellt, brauchen Sie eigentlich nur noch eine passende
Datensatzquelle auszuwählen und die Felder in der gewünschten Reihenfolge
anzuordnen. Das kann dann, in einem sehr einfachen Fall, wie in Abbildung 3.8 aussehen.
Ein Wechseln in die Formularansicht sorgt schließlich für die Anzeige des geteilten Formu
lars (siehe Abbildung 3.9). Mit einem Klick auf einen der Datensätze in der Hälfte mit
der Datenblattansicht zeigen Sie den jeweils angeklickten Datensatz im Detailbereich
des Formulars an.
172

Formulare in Access 2010
Abbildung 3.8: Dieser Entwurf soll den Detailbereich eines geteilten Formulars ausmachen
Abbildung 3.9: Die geteilte Ansicht eines Formulars mit Datenblatt und Detailansicht
Natürlich können Sie für geteilte Formulare einige Einstellungen vornehmen. Welche
dies sind, zeigt Tabelle 3.4.
Weitere Möglichkeiten bietet das Kontextmenü des Datenblatt-Bereichs des geteilten
Formulars: Hier haben Sie alle Möglichkeiten, die Sie auch sonst in der Datenblattansicht
haben.
Die Formatierung des Datenblattbereichs können Sie mit den Steuerelementen im
Ribbon unter Start|Schriftart anpassen – vorher müssen Sie allerdings den Fokus auf
das Datenblatt setzen.
Die passenden Eigenschaften unter VBA heißen DatasheetAlter nateBackColor, Datasheet
BackColor, DatasheetBorderLineStyle, DatasheetCellsEffect, Datasheet Column­
Header UnderlineStyle, DatasheetFontHeight, DatasheetFontItalic, Data sheet Font Name,
Data sheetFontUnderline, DatasheetFontWeight, DatasheetForeColor, Data sheet Grid lines­
Be ha viour und DatasheetGridlinesColor – für weitere Informationen siehe Onlinehilfe.
3.1.4 Hilfreiche Funktionen für den Formularentwurf
Seit Access 2007 gibt es einige neue Funktionen zum Entwerfen von Formularen, die mit
Access 2010 noch erweitert wurden.
173

Kapitel 3 Formulare
Eigenschaft
(deutsch)
Größe des geteilten
Formulars
Orientierung des
geteilten Formulars
Teilerleiste des
geteilten Formulars
Datenblatt des
geteilten Formulars
Drucken des geteilten
Formulars
Position der Teilerleiste
speichern
174
Eigenschaft
(VBA)
Beschreibung
SplitFormSize Legt die Höhe des Detailbereichs des
Formulars fest. Einheit in VBA: Twips
(567 Twips entsprechen 1 cm).
SplitFormOrientation Gibt die Position des Datenblatts an.
Mögliche Werte:
0 (acDatasheetOnTop, oben, Standard)
1 (acDatasheetOnBottom, unten)
2 (acDatasheetOnLeft, links)
3 (acDatasheetOnRight, rechts)
SplitFormSplitterBar Gibt an, ob der Benutzer die Größe der
Bereiche mit einer Teilerleiste einstellen kann.
Boolean.
SplitFormDatasheet Gibt an, ob der Benutzer Daten im Datenblatt
bearbeiten darf. Mögliche Werte:
0 (acDatasheetAllowEdits, editieren erlaubt)
1 (acDatasheetReadOnly, schreibgeschützt)
SplitFormPrinting Gibt an, welcher Bereich des Formulars gedruckt
wird. Mögliche Werte:
0 (acFormOnly, Detailansicht)
1 (acGridOnly, Datenblatt)
SplitFormSplitterBarSave Gibt an, ob die Position der Teilerleiste beim
Schließen gespeichert wird. Boolean.
Tabelle 3.4: Eigenschaften zum Anpassen der geteilten Formularansicht
Automatische Layouts
Wenn Sie Steuerelemente und ihre Beschriftungsfelder in Tabellenform anordnen
möchten, können Sie einfach alle betroffenen Elemente markieren und dann einen der
Ribbon-Einträge Anordnen|Tabelle|Tabelle oder Anordnen|Tabelle|Gestapelt auswählen.
Diese Funktionen stehen in der Entwurfs- und der Layoutansicht zur Ver fü gung. Access
ordnet die Steuerelemente dann wie in Abbildung 3.10 (Ausrichtung: Ta belle) oder wie in
Abbildung 3.11 (Ausrichtung: Gestapelt) an.
Abbildung 3.10: Felder mit tabellarischer Ausrichtung

Abbildung 3.11: Felder in der »gestapelten« Ausrichtung
Formulare in Access 2010
Es handelt sich hierbei aber nicht nur um das automatische Anordnen, denn Access fügt
gleichzeitig eine Art Rahmen hinzu, der die Positionen der enthaltenen Steuerelemente
wahrt. Außerdem bietet dieser Rahmen die Möglichkeit, dass Sie die Reihenfolge der
Steuer elemente neu sortieren, ohne sich um die Wahrung der Abstände und der Po sition
kümmern zu müssen. Markieren Sie dazu einfach das zu verschiebende Feld und
ziehen Sie es an die gewünschte Stelle. Eine orange Linie zeigt dabei an, wo Access das
Steuerelement platziert.
Bei der tabellarischen Ausrichtung übernimmt Access automatisch die Aufgabe, die
Feld bezeichnungen als Spaltenköpfe in den Formularkopf zu kopieren. Wenn Sie einzelne
Elemente einer Gruppe von gemeinsam ausgerichteten Steuer ele men ten individuell
anpassen möchten, müssen Sie mit Einschränkungen leben: In der tabellarischen
Ausrichtung können Sie nur die Breite und in der gestapelten Ausrichtung nur die Höhe
der einzelnen Steuerelemente anpassen.
Das ist aber nicht schlimm: Wenn Sie die Steuerelemente mit einer der Ausrichten-
Funk tionen positioniert haben, können Sie den Layoutrahmen wieder entfernen, indem
Sie diesen markieren und den Ribbon-Eintrag Anordnen|Tabelle|Entfernen betätigen.
Danach können Sie manuell Hand an die Steuerelemente anlegen, um etwa die Breite
des PLZ-Felds in Abbildung 3.11 zu verringern.
Den Layoutrahmen markieren Sie im Übrigen mit einem Klick auf das kleine Kreuz,
das nach einem Klick auf eines der enthaltenen Steuerelemente erscheint (siehe
Abbildung 3.12).
Sie können dem Layout auch nachträglich einzelne Steuerelemente hinzufügen oder
Steuer elemente daraus entfernen. Zum Hinzufügen ziehen Sie einfach das passende
Steuerelement an die gewünschte Stelle im Layout, zum Entfernen markieren Sie das
175

Kapitel 3 Formulare
betroffene Steuerelement und klicken anschließend auf die Ribbon-Schalt flä che Anordnen|Tabelle|Layout
entfernen. Nach dem Entfernen verbleibt das ent fernte Steuerele
ment an Ort und Stelle und die daneben oder darunter befindlichen Steuer ele men te
rü cken an dessen Platz. Sie müssen auf einem Layout entfernte Steuer ele mente also
noch manuell verschieben, damit diese nicht mit den Steuer ele men ten des Layouts
über lappen.
Abbildung 3.12: Mit dem Kreuz links oben markieren Sie das komplette Layout
Die Layoutansicht sollte dem Entwickler einer Datenbank vorbehalten sein. Sie sollten
daher entweder die Eigenschaft Layoutansicht zulassen für die gewünschten Formulare
auf Nein einstellen oder die Ansicht für die komplette Datenbank deaktivieren, indem Sie
in den Access-Optionen die Eigenschaft Aktuelle Datenbank|Anwendungsoptionen|Lay outan
sicht aktivieren auf Ja einstellen. In VBA können Sie dieses Feature mit der Eigenschaft
AllowLayoutView des Formulars aktivieren und deaktivieren.
Mit Access 2010 gibt es einige Verbesserungen: So können Sie nun das Raster weiter
verfeinern. Sie können Zellen horizontal oder vertikal aufteilen, um zusätzliche
Steuerelemente einfügen zu können (etwa eine Schaltfläche), und diese wieder verbinden.
Jede Zelle darf aber nur ein Steuerelement enthalten.
Wenn Sie Zellen aufteilen, fügt Access in den entstandenen Leerräumen automatisch
das neue Steuerelement EmptyCell als Platzhalter ein. Dies ist vor allem dem Layout von
Webformularen und -berichten geschuldet.
Die notwendigen Befehle finden Sie im Kontextmenü des jeweiligen Elements (siehe
Abbildung 3.13). Außerdem finden Sie hier die Möglichkeit, komplette Zeilen und Spalten
einzufügen (Kontextmenüeinträge Einfügen|Links einfügen, Einfügen|Rechts einfügen,
Einfügen|Oben einfügen und Einfügen|Unten einfügen).
176

Abbildung 3.13: Aufteilen und verbinden der Zellen eines Rasters
Formulare in Access 2010
Diese Aktionen können Sie auch mit der RunCommand-Methode durchführen, und zwar
mit den folgenden Konstanten:
» acCmdLayoutInsertRowAbove
» acCmdLayoutInsertRowBelow
» acCmdLayoutInsertColumnLeft
» acCmdLayoutInsertColumnRight
» acCmdLayoutMergeCells
» acCmdLayoutSplitColumnCell
» acCmdLayoutSplitRowCell
Das komplette Layout markieren Sie mit RunCommand acCmdSelectEntireLayout.
Berechnungen in der Datenblattansicht
In Tabellen, Abfragen und Formularen steht seit Access 2007 für die Datenblattansicht
eine neue Funk tion zum Durchführen von Berechnungen und zur Anzeige ihrer Ergebnisse
bereit. Da der Benutzer Ihrer Datenbank keinen Kontakt mit der Datenblattansicht
der Tabellen und Abfragen haben soll, ist dies ein Fall für das Formulare-Kapitel. Wie
weiter oben er wähnt, erscheinen Daten in der Datenblattansicht meist in Form von
Unterformularen in der Datenblattansicht – ein Formular in der Datenblattansicht allein
macht wenig Sinn, da man beispielsweise keine zusätzlichen Steuerelemente
wie Schaltflächen dort un terbringen kann. Ob nun in einem Formular oder in einem
Unterformular: Sie können einem Daten blatt eine Zeile mit Berechnungen hinzufü-
177

Kapitel 3 Formulare
gen, indem Sie es in der Datenblatt an sicht markieren und im Ribbon die Schaltfläche
Start|Datensätze|Summen anklicken. Schon erscheint die gewünschte Zeile in der
Tabelle und Sie müssen nur noch das Feld und die Berechnungsmethode festlegen (siehe
Abbildung 3.14). Praktischerweise bleibt die Berechnungszeile am unteren Rand des
Datenblatts »kleben« und wird nicht nach unten weggeschoben, wenn das Datenblatt
mehr Datensätze enthält, als es gleichzeitig anzeigen kann.
Abbildung 3.14: Auswahl einer Berechnungsart für das Feld Betrag
Access stellt je nach dem Datentyp des Feldes unterschiedliche Funktionen zur Ver fügung.
Bei Zahlen stehen naturgemäß mehr Varianten bereit als für Textfelder – hier gibt
es lediglich die Möglichkeit, die Anzahl der Einträge auszugeben. Wie für viele neue Features
seit Access 2007 gilt: Probieren Sie es einfach aus, es geht ganz leicht.
3.1.5 Farben und Schriftarten per Design festlegen
Mit den sogenannten Designs können Sie das Aussehen von Formularen und Berichten
sowie der enthaltenen Steuerelemente einfach anpassen. Die dafür verantwortlichen
Elemente der Benutzeroberfläche finden Sie im Formular- beziehungsweise Berichtsentwurf
im Ribbon-Tab Entwurf (siehe Abbildung 3.15).
Abbildung 3.15: Aufruf der Funktionen zum Festlegen von Designs
178

Dies geschieht im Falle der Farben durch folgende Struktur:
Formulare in Access 2010
» Bei den Farben gibt es eine Zuordnung von Farbcode zu Platzhaltern wie beispielsweise
Text/Hintergrund ­ dunkel 1 (siehe Abbildung 3.16).
» In den Farbeigenschaften eines Formulars, Berichts oder Steuerelements legen Sie
entweder direkt einen Farbcode fest (also ein entsprechender Zahlenwert) oder Sie
geben einen der Platzhalter aus Abbildung 3.16 an, aufzurufen über den Ribbon-
Eintrag Designs|Farben|Neue Designfarben erstellen. Letzteres ist die Voraussetzung
für die zentrale Anpassung der Farben über den Dialog aus der Abbildung.
Abbildung 3.16: Zuordnung von Farben zu Platzhaltern
Sie können nun beliebig viele eigene Zusammenstellungen der Designfarben erstellen
und speichern. Anschließend klicken Sie mit der rechten Maustaste auf einen der
Einträge in der Liste der Farbschemata und legen fest, ob dieser auf alle Formulare
beziehungsweise Berichte angewendet werden soll oder nur auf das aktuell geöffnete.
Sie können hier auch eigene Schemata löschen oder bearbeiten (siehe Abbildung 3.17).
Die Platzhalter aus Abbildung 3.16 tauchen im Dialog zum Einstellen der Farbe eines
Elements der Benutzeroberfläche in etwas veränderter Form wieder auf (siehe
Abbildung 3.18).
Verändert deshalb, weil es beispielsweise statt Text/Hintergrund ­ dunkel 1 einen Eintrag
Schwarz, Text 1 gibt. Die einzelnen Schemafarben können Sie noch in helleren oder
dunkleren Tönen einsetzen – die entsprechenden Schaltflächen befinden sich unterhalb
der Hauptfarben des Schemas.
179

Kapitel 3 Formulare
Abbildung 3.17: Festlegen eines Farbschemas
Abbildung 3.18: Auswählen der Platzhalter des Farbschemas für ein Steuerelement
Wenn Sie einem Element eine Designfarbe zuweisen, legen Sie damit drei Eigenschaften
fest:
» Index der Designfarbe (BorderThemeColorIndex), siehe unten
» Abdunkelung (BorderShade): Wert zwischen 1 und 100, der die Abdunkelung des
Elements festlegt (100 entspricht der Originalfarbe)
180

Formulare in Access 2010
» Aufhellung (BorderTint): Wert zwischen 1 und 100, der die Aufhellung des Elements
festlegt (100 entspricht der Originalfarbe)
Die folgenden Zahlenwerte entsprechen dem Index für die Designfarben aus Abbildung 3.16:
» 0 (Text 1)
» 1 (Hintergrund 1)
» 2 (Text 2)
» 3 (Hintergrund 2)
» 4 (Akzent 1)
» 5 (Akzent 2)
» 6 (Akzent 3)
» 7 (Akzent 4)
» 8 (Akzent 5)
» 9 (Akzent 6)
» 10 (Hyperlink)
» 11 (Besuchter Hyperlink)
Diese Informationen sind einzeln nur per VBA zugänglich. Im Eigenschaftsfenster wählen
Sie nur einen Eintrag des Dialogs wie Schwarz, Text 1, Heller 25% aus.
Farben statisch gestalten
Wenn die Farben nicht durch den Wechsel des Designs beeinflusst werden sollen, wählen
Sie einfach eine der Standardfarben aus dem Dialog aus Abbildung 3.18 aus oder
legen manuell einen entsprechenden Zahlenwert fest.
Design oder nicht Design?
Mit der Eigenschaft Design verwenden (VBA: UseTheme) können Sie für Navi ga tionsschalt
flächen, Navigationssteuerelemente, Schaltflächen, Registerkarten-Steuer ele -
mente und Umschaltflächen festlegen, ob Sie das angegebene Design verwenden wollen
oder nicht.
Deshalb enthalten diese Steuerelemente für alle Elemente, deren Farbe eingestellt
werden kann, vier Eigenschaften.
Hat Design verwenden den Wert Nein, wird die in BackColor angegebene Farbe verwendet,
sonst die in den übrigen drei Ei gen schaften festgelegte:
181

Kapitel 3 Formulare
» ...Color
» ...Shade
» ...ThemeColorIndex
» ...Tint
Die drei Pünktchen werden dabei für die verschiedenen Eigenschaften durch Back-,
Border-, Fore-, Gridline-, Hover-, HoverFore-, Pressed- und PressedFore- ersetzt. Steht
Design verwenden für ein Steuerelement auf Nein, kommen auch die Effekte etwa für
den Farbverlauf nicht zum Tragen.
Design-Schriften
Für die Steuerelemente mit Beschriftung wie etwa Bezeichnungsfelder oder Schaltflächen
oder mit Texten wie das Textfeld können Sie auch die Schriftart per Design festlegen.
Wenn Sie im Ribbon unter Entwurf|Designs|Schriftarten einen Eintrag auswählen,
wirkt sich dies direkt auf alle Texte im aktuell geöffneten Formular aus. Sie legen damit
allerdings nur die Schriftart fest, andere Einstellungen wie Schriftgröße et cetera bleiben
unberührt.
Genau genommen können Sie sogar zwei Schriftarten pro Design festlegen. Klicken Sie
im Ribbon auf Entwurf|Designs|Schriftarten und wählen dann ganz unten den Eintrag
Neue Designschriftart erstellen... aus, erscheint der Dialog aus Abbildung 3.19.
Hier wählen Sie zwei Schriftarten aus, die Sie später auf die Steuerelemente des
Formulars verteilen können. Standardmäßig wird beim Neuanlegen von Steuerelementen
oder beim Zuweisen dieses Designs die Textkörper-Schriftart verwendet.
Nur wenn Sie aus dem Ribbon den Eintrag Entwurf|Kopfzeile/Fußzeile|Titel auswählen,
wird ein Bezeichnungsfeld mit der Überschriften-Schriftart erstellt.
Abbildung 3.19: Neue Design-Schriftarten festlegen
Sie können die Steuerelemente jedoch komfortabel über das Eigenschaftsfenster mit
den beiden Design-Schriftarten bestücken (siehe Abbildung 3.20). Beachten Sie, dass
nur die mit dem Zusatz (Kopfbereich) beziehungsweise (Detailbereich) versehenen
182

Formulare in Access 2010
Schrift arten die aktuellen Design-Schriftarten sind, die beim Wechseln des Designs
durch andere Schriftarten ersetzt werden. Wenn Sie etwa die Schriftart Arial ohne Zusatz
auswählen, bleibt diese Schriftart auch beim Design-Wechsel erhalten.
Abbildung 3.20: Einfache Auswahl der beiden Design-Schriftarten
Per VBA können Sie übrigens prüfen, ob ein Element der Benutzeroberfläche eine der
beiden Designschriftarten verwendet oder nicht: Die Eigenschaft ThemeFontIndex liefert
einen der folgenden Werte zurück:
» 0: Es wird die Designschriftart für den Kopfbereich verwendet.
» 1: Es wird die Designschriftart für den Detailbereich verwendet.
» ­1: Es wird keine Designschriftart verwendet.
Farben und Schriften zusammenführen
Wenn Sie mit den aktuell ausgewählten Farben und Schriftarten zufrieden sind, können
Sie beide kombiniert speichern. Dies erledigen Sie mit einem Klick auf den Ribbon-
Eintrag Entwurf|Designs|Designs und durch anschließendes Auswählen des Eintrags
Aktuelles Design speichern.
Die Informationen werden im Vorlagen-Verzeichnis von Office im Unterordner Document
Themes als Datei mit der Endung .thmx gespeichert (unter Win dows 7 beispielsweise im
Verzeichnis C:\Users\Andre Minhorst\AppData\Roaming\Micro soft\Templates\Document
Themes).
Wenn Sie eine mit einem Design ausgestattete Datenbank weitergeben, brauchen Sie die
.thmx-Datei übrigens nicht mit auf den Zielrechner zu übertragen – alle Eigenschaften
sind natürlich in der Datenbank gespeichert. Sie können das Design dann lediglich nicht
auf neue Formulare oder Berichte anwenden.
183

Kapitel 3 Formulare
3.1.6 Sonstige Neuerungen
Es gibt noch einige weitere kleine Neuheiten, die eine Erwähnung wert sind.
Alternierender Hintergrund in Datenblättern
Access 2010 bietet die Möglichkeit, die Datenblattansicht von Tabellen, Abfragen und
For mularen mit einer alternierenden Hintergrundfarbe zu versehen. Eine Access-weite
Op tion finden Sie in den Access-Optionen unter Datenblatt|Standardfarben|Alternative Hin ­
ter grund far be. Den Effekt können Sie sich in zahlreichen Abbildungen dieses Kapitels
an sehen. Wenn Sie eine individuelle Färbung für einzelne Objekte vornehmen möchten,
ver wenden Sie in der Datenblattansicht den Ribbon-Eintrag Start|Schriftart|Alternative
Füllung/Hintergrundfarbe. Alternativ können Sie dies auch mit VBA erreichen; die passende
Eigenschaft heißt DatasheetAlternateBackColor.
Steuerelemente mit Abstand
Mit den folgenden vier Eigenschaften stellen Sie den Abstand von Steuerelementen zur
nächsten Gitternetzlinie in einem der Layouts Tabelle oder Geschachtelt fest. Die Ei genschaf
ten sind für fast alle Steuerelemente verfügbar:
» Textabstand oben (TopPadding)
» Textabstand unten (BottomPadding)
» Textabstand links (LeftPadding)
» Textabstand rechts (RightPadding)
Steuerelemente verankern
Mit dem Ribbon-Eintrag Anordnen|Position|Anker können Sie Steuerelemente mit dem
Seitenrand des Formulars verankern. Alternativ stellen Sie die Eigenschaften Ho rizon
taler Anker (HorizonalAnchor) und Vertikaler Anker (VerticalAnchor) des betroffenen
Steuer elements ein. Die Standardeinstellungen sind Links für den horizontalen Anker
und Oben für den vertikalen Anker. Das bedeutet, dass sich das Steuerelement beim
Ver größern oder Verkleinern des Formulars nicht ändert.
Wie sich die unterschiedlichen Einstellungen auswirken, probieren Sie am besten selbst
aus – und zwar in der Layoutansicht, die dafür perfekt geeignet ist. Einen guten Eindruck
vermittelt das Beispiel in Abbildung 3.21.
Beschriftung der Navigationsleiste
Links von der Navigationsleiste von Formularen können Sie ab Access 2007 einen Text
an zeigen. Diesen legen Sie mit der Eigenschaft Navigationsbeschriftung fest (in VBA: Na­
184

Formulare in Access 2010
vi gationCaption). Abbildung 3.22 zeigt ein Beispiel für eine auf diese Weise beschriftete
Na vi gationsleiste. Da die Länge begrenzt und die Anzeige unauffällig ist, scheint der
Nut zen dieser Funktion eingeschränkt zu sein.
Abbildung 3.21: Verankerte Elemente eines Formulars
Abbildung 3.22: Die Beschriftung der Navigationsleiste darf nicht sehr lang sein
Wenn Sie den Benutzer mit der Beschriftung unbedingt auf die Navigationselemente
aufmerksam machen möchten, stellen Sie für die Eigenschaft Zeitgeberintervall des
Formulars den Wert 500 ein und hinterlegen für die Ereigniseigenschaft Bei Zeitgeber
die folgende Routine:
Private Sub Form_Timer()
Static bol As Boolean
bol = Not bol
If bol Then
Else
End If
End Sub
Me.NavigationCaption = "Hier navigieren!->"
Me.NavigationCaption = "->Hier navigieren!"
Listing 3.1: Wechselnde Navigationsleistenbeschriftungen per Zeitgeber
185

Kapitel 3 Formulare
Dies lässt die Beschriftung »Hier navigieren« hin- und herspringen. Beachten Sie, dass
die verwendeten Zeichen immer die gleiche Breite einnehmen, sonst springt auch die
eigentliche Navigationsleiste hin und her. (Kleiner Tipp: Nehmen Sie nicht alles ernst,
was in diesem Buch geschrieben steht.)
Formular-Ribbon
Sie können für jedes Formular eine der in der Datenbank gespeicherten Ribbon-Defi
ni ti onen festlegen. Damit können Sie beispielsweise dafür sorgen, dass bei Ak ti vierung
ei nes Formulars nur formularspezifische Ribbon-Elemente angezeigt werden,
oder ein fach das Ribbon um ein spezielles Tab-Element für das Formular erweitern.
Sie legen das Ribbon mit der Formular-Eigenschaft Name des Menübands (unter VBA:
RibbonName) fest.
Dies funktioniert nicht bei Popup- und geteilten Formularen. Weitere In formationen
zum Thema Ribbons finden Sie unter »Ribbon« ab Seite 679.
3.1.7 Formularvorlage
Nicht neu, aber möglicherweise nicht jedem bekannt sind die folgenden beiden Features,
die das Erstellen von Formularen vereinfachen.
Mit der Zeit werden Sie sich einen gewissen Stil angewöhnen, was das Aussehen von
For mu laren angeht. Vielleicht verwenden Sie eine bestimmte Hintergrundfarbe für
Kopf-, Fuß- und Detailbereich oder stellen weitere Eigenschaften immer auf die gleichen
Werte ein.
Wenn Sie solche Standardeinstellungen öfter benötigen, können Sie ein For mular mit
all den gewünschten Eigenschaften anlegen und es unter dem For mu lar na men Normal
speichern. Von nun an besitzen alle neu erstellten Formulare standardmäßig diese
Eigenschaften. Erst wenn Sie das Formular Normal entfernen oder umbenennen, verwendet
Access wieder die ursprünglichen Standardeinstellungen beim Anlegen von
Formularen.
Das Gleiche gilt übrigens auch für Berichte, auch hier verwenden Sie standardmäßig den
Berichtsnamen Normal für die Vorlage. Wenn Sie einen anderen Formular- beziehungsweise
Berichtsnamen als Normal einsetzen möchten, können Sie dies in den Access-
Optionen unter Objekt­Designer|Formular/Berichte|Formularvorlage/Berichtsvorlage einstel
len.
Beim Öffnen filtern und sortieren
Mit den beiden Eigenschaften Beim Laden filtern (VBA: FilterOnLoad) und Beim Laden
sortieren (VBA: OrderByOnLoad) legen Sie fest, ob eine in den Eigenschaften Filter (Filter)
186

Formulare öffnen
oder Sortiert nach (OrderBy) angegebene Filterung beziehungsweise Sortierung direkt
beim Laden des Formulars ausgeführt werden soll.
An Bildschirmgröße anpassen
Mit der gleichnamigen Eigenschaft bestimmen Sie, ob Formulare, die zu groß für die
aktuelle Access-Fensterbreite sind, dem verfügbaren Platz angepasst werden sollen.
Unter VBA lautet der Name dieser Eigenschaft FitToScreen – obwohl dies streng genommen
keine Anpassung an den Bildschirm, sondern an den freien MDI-Bereich von
Access ist.
Keine Entwurfsänderungen in der Formularansicht
Die Eigenschaft Entwurfsänderungen zulassen (AllowDesignChanges) entfällt. Sie bewirkte
in älteren Versionen, dass Formulare nur in der Entwurfsansicht das Eigenschaftenfenster
angezeigt haben. Seit Access 2007 können Sie das Eigenschaftenfenster grundsätzlich
nur noch in der Entwurfs- und der Layoutansicht einblenden.
3.1.8 Berichte in Unterformularen
Mit Access 2010 können Unterformulare erstmals Berichte anzeigen. Dazu legen Sie
einfach den Berichtsnamen als Wert für die Eigenschaft Herkunftsobjekt fest.
3.2 Formulare öffnen
Formulare öffnen Sie in der Regel mit der DoCmd.OpenForm-Anweisung. Es geht zwar
auch über das Instanzieren des entsprechenden Formularobjekts und anschließendes
Einstellen der Eigenschaft Visible auf den Wert True, das ist aber eher Spezialfällen wie
dem Öffnen mehrerer Instanzen des gleichen Formulars vor behalten.
Da die DoCmd.OpenForm-Anweisung allgemein bekannt sein dürfte (ansonsten liefert
die Onlinehilfe einen guten Überblick), soll sie hier nicht im Detail beschrieben werden.
Im Hinblick auf die nachfolgenden Beispiele sei nur erwähnt, dass die dortigen Aufrufe
»benannte Parameter« verwenden. Das bedeutet, dass die optionalen Parameter nicht
in der vorgegebenen Reihenfolge durch Kommata getrennt an die Anweisung angefügt
werden, sondern unter Angabe des jeweiligen Parameternamens:
DoCmd.OpenForm "frmKontakteDetailansicht", DataMode:=acFormAdd, _
WindowMode:=acDialog
Mit einer herkömmlichen Parameterliste hätte diese Anweisung so ausgesehen:
DoCmd.OpenForm "frmKontakteDetailansicht", , , , acFormAdd, acDialog
187

Kapitel 3 Formulare
3.3 Ereignisse in Formularen und Steuerelementen
Formulare lassen sich wie auch Berichte bis zu einem gewissen Grad ohne den Einsatz
von Ereigniseigenschaften und VBA verwenden. Sobald Sie aber auch nur eine OK-
Schaltfläche hinzufügen möchten, ist es so weit: Die Programmierung der ersten
Ereignisprozedur steht an. Ereignisse stellen die Schnittstelle zwischen Ober flächenelementen
und der VBA-Programmierung derselben bereit. In diesem Abschnitt erfahren
Sie, welche der zahlreichen Ereignisse von Formularen und der enthaltenen
Steuerelemente oft zum Einsatz kommen und wie Sie diese optimal einsetzen – dazu
gehört auch, dass Sie sich mit der Reihenfolge der Ereignisse vertraut machen.
3.3.1 Ereignisse in Formularen
Formulare bieten eine unüberschaubare Menge Ereignisse. Seit Access 2007 sind keine
mehr hinzugekommen, lediglich die neuen Steuerelemente bringen einige neue
Ereignisse mit. Weitere Informationen zu diesen Steuerelementen finden Sie im Kapitel
»Steuerelemente« ab Seite 265.
Anlegen eines Ereignisses
Abbildung 3.23 zeigt einen Teil der Ereigniseigenschaften von Formularen.
Abbildung 3.23: Übersicht der Ereigniseigenschaften eines Formulars
188

Ereignisse in Formularen und Steuerelementen
Zum Anlegen eines Ereignisses klicken Sie doppelt in das entsprechende Textfeld, sodass
dieses den Wert [Ereignisprozedur] erhält, und betätigen dann die Schaltfläche mit
den drei Punkten (…) wie in Abbildung 3.24. Wenn Sie es noch einfacher haben möchten,
aktivieren Sie in den Access-Optionen im Bereich Objekt­Designer|Formulare/Berichte
den Eintrag Immer Ereignisprozeduren verwenden.
Dann müssen Sie nur noch auf die beim Aktivieren des Feldes erscheinende Schaltfläche
klicken, um die Ereignisprozedur anzulegen. Wenn Sie dies beispielsweise mit
der ersten aufgeführten Ereigniseigenschaft Beim An zei gen machen, öffnet sich der
VBA-Editor und zeigt direkt den Rumpf der gewünschten Pro zedur an:
Private Sub Form_Current()
End Sub
Listing 3.2: Leerer Rumpf einer frisch angelegten Ereignisprozedur
Abbildung 3.24: Anlegen einer Ereignisprozedur
Neben den Ereignisprozeduren können Sie auch Access-Makros und VBA-Funktionen
per Ereignis auslösen. Dazu tragen Sie einfach den Namen des Access-Makros oder der
Funktion ein. Access-Makros bleiben in diesem Buch weitgehend außen vor; der Einsatz
von Funktionen kann jedoch durchaus sinnvoll sein. So können Sie beispielsweise für
OK-Schaltflächen eine globale Funktion schreiben, die eine Anweisung zum Schließen
des Formulars enthält, oder eine Funktion im For mu lar modul anlegen, die durch mehrere
Ereignisse des gleichen Formulars ausgelöst wird.
Ereigniseigenschaft und Ereignisprozedur — ein unzertrennliches Paar
Damit ein Ereignis durch die entsprechende Aktion – also etwa Betätigen einer Schaltflä
che – ausgelöst wird, muss die Ereigniseigenschaft den Eintrag [Ereignisprozedur] ent-
189

Kapitel 3 Formulare
halten und eine Ereignisprozedur mit dem für dieses Ereignis vorgesehenen Namen im
Klassenmodul des Formulars oder des Berichts vorliegen – beispielsweise cmdOK_Click.
3.3.2 Abfolge und Bedeutung der Ereignisse beim Öffnen und
Schließen eines Formulars
Besonders wichtig beim Umgang mit Ereigniseigenschaften ist die Reihenfolge ihrer
Abarbeitung und der Zusammenhang mit den im Hintergrund ausgelösten internen
Pro zessen wie Laden der angezeigten Daten, Übergeben von Öffnungsargumenten und
der gleichen in gebundenen Formularen. Selbst wenn Sie eine Access-Anwendung völlig
ohne Dokumentation programmieren müs sen, können Sie sich hier selbst weiterhelfen:
Schreiben Sie einfach für alle Er eig nis eigenschaften, die Sie interessieren, eine kleine
Prozedur, die den jeweiligen Er eig nis namen ausgibt. Wenn Sie dann das Formular öffnen
oder die gewünschte Aktion durch führen, können Sie anschließend oder währenddessen
beobachten, in welcher Rei hen folge die Ereignisse ablaufen. Wenn Sie beispielsweise herausfinden,
welche Sequenz von Ereignissen beim einfachen Öffnen und Schließen eines
Formulars abläuft, legen Sie die Ereignisprozeduren aus folgendem Listing an:
190
Private Sub Form_Activate()
End Sub
Debug.Print "Beim Aktivieren"
Private Sub Form_Close()
End Sub
Debug.Print "Beim Schließen"
Private Sub Form_Current()
End Sub
Debug.Print "Beim Anzeigen"
Private Sub Form_Deactivate()
End Sub
Debug.Print "Beim Deaktivieren"
Private Sub Form_Load()
End Sub
Debug.Print "Beim Laden"
Private Sub Form_Open(Cancel As Integer)
End Sub
Debug.Print "Beim Öffnen"

Private Sub Form_Resize()
End Sub
Debug.Print "Bei Größenänderung"
Private Sub Form_Unload(Cancel As Integer)
End Sub
Debug.Print "Beim Entladen"
Ereignisse in Formularen und Steuerelementen
Listing 3.3: Ausgabe von Meldungen beim Auslösen unterschiedlicher Ereignisprozeduren
Als Ergebnis erhalten Sie beim Öffnen des Formulars folgende Abfolge:
» Beim Öffnen: Tritt beim Öffnen ein. Bietet die Möglichkeit, das Öffnen abzubrechen,
wenn beispielsweise keine Daten vorhanden sind – diese werden dementsprechend
bereits vor dem Beim Öffnen-Ereignis eingelesen.
» Beim Laden: Tritt ein, wenn das Formular einschließlich Steuerelementen geöffnet,
aber noch nicht sichtbar ist. Eignet sich für Aktionen wie Setzen von Standardwerten
oder Werten von Steuer ele men ten.
» Bei Größenänderung: Wird beim Öffnen und bei der Änderung der Größe eines
For mu lars ausgelöst. Kann zum Anpassen der Größe von Steuerelementen
an die Größe des For mu lar s verwendet werden – falls Sie nicht zufällig von den
Möglichkeiten rund um die Verankerung von Steuerelementen Gebrauch machen.
» Beim Aktivieren: Wird ausgelöst, wenn das Formular den Fokus erhält.
» Beim Anzeigen: Wird beim Anzeigen, bei jedem Datensatzwechsel und beim Ak tu alisieren
ausgelöst.
Beim Schließen sieht der Ablauf so aus:
» Beim Entladen: Wird durch einen Klick auf eine Schließen-Schaltfläche oder die
DoCmd.Close-Anweisung ausgelöst, findet aber vor dem eigentlichen Schließen statt.
Der Schließen-Vorgang kann an dieser Stelle durch Setzen des Cancel-Parameters
auf den Wert True unterbrochen werden.
» Beim Deaktivieren: Wird ausgelöst, wenn das Formular den Fokus verliert.
» Beim Schließen: Wird im Moment des Schließens ausgelöst.
3.3.3 Abfolge und Bedeutung der Ereignisse beim Bearbeiten
von Datensätzen
Das Bearbeiten eines Datensatzes beginnt mit der ersten Änderung an einem der Felder
und endet mit dem Speichervorgang des Datensatzes.
191

Kapitel 3 Formulare
Ändern von Feldinhalten
Änderungen von Datensätzen beginnen mit dem Ändern des Inhalts mindestens eines
Fel des. Dies löst eines oder mehrere der folgenden Ereignisse aus:
» Vor Eingabe: Wird vor der Eingabe des ersten Zeichens ausgelöst, aber nur in Ver bindung
mit neuen Datensätzen. Kann abgebrochen werden.
» Bei Geändert: Wird beim ersten Eingeben oder Löschen eines Zeichens in einem der
Da tensätze ausgelöst. Kann abgebrochen werden.
Speichern der Änderungen
Wird die Änderung gespeichert, werden in der Regel die folgenden drei Ereignisse ausgelöst.
Das erste Ereignis Vor Aktualisierung kann den Ablauf allerdings abbrechen, etwa
wenn eine Validierung fehlschlägt.
» Vor Aktualisierung: Wird nach dem Auslösen des Speicherns, aber vor dem eigentlichen
Speichervorgang ausgelöst. Ist ein gängiger Platz für die Durchführung von
Validierungen. Folgendes Beispiel zeigt, wie Sie die Aktualisierung abbrechen, wenn
be stimmte Daten nicht vorhanden sind (weitere Informationen zum Validieren siehe
»Validieren vor dem Speichern« ab Seite 254):
192
If IsNull(Me!Telefon) And IsNull(Me!EMail) Then
End If
MsgBox "Bitte geben Sie eine Telefonnummer oder eine " _
& "E-Mail-Adresse ein.", vbExclamation + vbOKOnly, _
"Fehlende Daten"
Me!Telefon.SetFocus
Cancel = True
» Nach Aktualisierung: Wird nach dem Speichern des Datensatzes ausgelöst.
» Nach Eingabe: Wird nach dem Speichern eines neuen Datensatzes ausgelöst; gilt
nicht für bestehende Datensätze.
» Beim Anzeigen: Wird beim Wechseln beziehungsweise Speichern des Datensatzes
auf ge rufen.
Abbruch des Änderungsvorgangs
Neben dem Speichern bietet sich nach Änderungen an Feldern eines Datensatzes auch
die Möglichkeit, den Vorgang abzubrechen und die vorgenommenen Änderungen am
aktuellen Datensatz zu verwerfen. Dies löst das Bei Rückgängig-Ereignis des Formulars
aus. Das Ereignis kann durch Setzen des Cancel-Parameters auf den Wert True abgebrochen
werden.

Löschen eines Datensatzes
Ereignisse von Steuerelementen
Das Löschen von Datensätzen ist keine triviale Geschichte. Wenn Sie auf eine Löschen-
Schaltfläche klicken, ist der Datensatz noch lange nicht gelöscht.
Zunächst wird die Anzeige aktualisiert, die auf einem temporären, zwischengespeicherten
Datenbestand basiert, und dann noch abgewartet, ob die Ereignisse Bei
Löschbestätigung oder Nach Löschbestätigung Änderungen bringen. Erst dann überträgt
Access die Änderungen in die Tabellen der Datenbank.
» Beim Löschen: Wird beim Aufrufen des Löschvorgangs und unmittelbar vor dem
Löschen ausgelöst. Wenn mehrere Datensätze gleichzeitig gelöscht werden, wird
dieses Ereignis für jeden Datensatz einmal aufgerufen.
» Beim Anzeigen: Wird nach dem Löschen, aber vor dem Übernehmen der Änderungen
in die Tabelle ausgelöst.
» Bei Löschbestätigung: Wird nur ausgelöst, wenn Access eine Bestätigung der Datensatzänderung
anzeigt – diese Option lässt sich im Dialog aus Abbildung 3.25 einstellen.
Die Bestätigungsmeldung kann unterbunden und durch eine eigene Meldung
ersetzt werden. Beispiel:
If MsgBox("Möchten Sie den Datensatz wirklich löschen?", _
End If
vbExclamation + vbOKCancel, _
"Löschbestätigung") = vbCancel Then
Cancel = True
Response = acDataErrContinue
» Nach Löschbestätigung: Wird nur ausgelöst, wenn eine angezeigte Bestätigung einer
Datensatzänderung auch bestätigt wurde beziehungsweise wenn der Löschvorgang
nach einer benutzerdefinierten Meldung im Ereignis Bei Löschbestätigung nicht abgebrochen
wurde.
3.4 Ereignisse von Steuerelementen
Neben dem Formular selbst lösen auch die Steuerelemente Ereignisse aus. Nachfolgend
finden Sie einige wichtige Ereigniseigenschaften von Steuerelementen.
Unterformulare
Wenn Sie mit Unterformularen arbeiten, sollten Sie wissen, in welcher Reihenfolge die
Ereignisse beim Öffnen und Schließen von Unterformularen in Bezug auf die Ereignisse
des Hauptformulars ausgelöst werden.
193

Kapitel 3 Formulare
Abbildung 3.25: Aktivieren der Anzeige einer Meldung beim Ändern von Datensätzen
Die Abfolge sieht folgendermaßen aus:
» Unterformular Beim Öffnen
» Unterformular Beim Laden
» Unterformular Bei Größenänderung
» Unterformular Beim Anzeigen
» Hauptformular Beim Öffnen
» Hauptformular Beim Laden
» Hauptformular Bei Größenänderung
» Hauptformular Bei Aktivierung
» Hauptformular Beim Anzeigen
Das Unterformular wird in der Tat komplett vor dem Hauptformular geladen. Lediglich
das Filtern der Datensätze des Unterformulars in Abhängigkeit von den für das Hauptfor
mular vorgesehenen Datensätzen erfolgt noch vor dem Beim Öffnen-Ereignis des Unter
formulars.
Beim Schließen des Formulars wird zuerst das Hauptformular und dann das Unter formu
lar geschlossen:
194

» Hauptformular Beim Entladen
» Hauptformular Bei Deaktivierung
» Hauptformular Beim Schließen
» Unterformular Beim Entladen
» Unterformular Beim Schließen
Textfelder
Ereignisse von Steuerelementen
Beim Setzen der Einfügemarke in ein Textfeld, beim Ändern des Inhalts und beim anschließenden
Verlassen treten die folgenden Ereignisse auf:
» Beim Hingehen: Beim Eintreten in das Feld
» Bei Fokuserhalt
» Bei Geändert: Beim Ändern des ersten Zeichens. Stellt die Eigenschaft Dirty auf den
Wert True ein.
» Bei Änderung: Beim Ändern jedes Zeichens
» Vor Aktualisierung: Bei jeder Aktion, die zum Verlassen des Feldes führt. Dieses
Ereignis bietet die Möglichkeit, feldbezogene Validierungen durchzuführen und die
Aktualisierung abzubrechen. Beispiel:
If IsNumeric(Left(Me.Projekt, 1)) Then
End If
MsgBox "Der Projektname darf nicht mit einer Zahl " _
& "beginnen.", vbOKOnly + vbExclamation, _
"Fehlerhafte Eingabe"
Cancel = True
» Nach Aktualisierung: Nach dem Ereignis Vor Aktualsisierung, wenn dieses nicht abgebrochen
wurde. Bietet die Möglichkeit, den eingegebenen Wert weiter zu verwerten
oder zu ändern.
» Beim Verlassen: Nach Abarbeitung der Ereignisse Vor Aktualisierung und Nach
Aktualisierung
» Bei Fokusverlust: Beim Setzen des Fokus auf ein anderes Steuerelement
In Zusammenhang mit diesen Ereignissen sind drei Eigenschaften von Textfeldern wichtig:
Value, OldValue und Text. OldValue enthält während des ganzen Änderungsvorgangs
den vorherigen Wert des Feldes. Text enthält den aktuell im Textfeld angezeigten Wert
und Value den alten Wert, bis es mit dem Auslösen des Ereignisses Vor Aktualisierung
195

Kapitel 3 Formulare
den aktuellen Inhalt des Feldes beziehungsweise der Eigenschaft Text zugewiesen bekommt.
Kombinationsfelder
Das Auswählen eines Eintrags und das anschließende Verlassen eines Kombinations feldes
löst die folgenden Ereignisse aus (wenn dieses noch nicht den Fokus hat).
In runden Klammern finden Sie Ereignisse, die nur bei der manuellen Eingabe von
Zeichen ausgeführt werden, in eckigen Klammern die Ereignisse, die nur bei manueller
Eingabe nicht vorhandener Listeneinträge ausgelöst werden.
» Beim Hingehen
» Bei Fokuserhalt
» Bei Änderung: Beim Auswählen eines Eintrags oder bei der ersten Eingabe eines
Zeichens
» (Bei Geändert: Bei der manuellen Eingabe von Zeichen)
» [Bei nicht in Liste: Nach der manuellen Eingabe eines Wertes, der nicht in der Liste
enthalten ist. Hier können Sie eine Prozedur hinterlegen, die nicht in der Liste enthaltene
Einträge in der zugrunde liegenden Datensatzherkunft anlegt und den neuen
Wert im Kombinationsfeld festlegt. In diesem Fall folgen die übrigen Ereignisse,
sonst wird der Änderungsvorgang unterbrochen.]
» Vor Aktualisierung
» Nach Aktualisierung
» Beim Klicken
» Bei Geändert
» Beim Verlassen
» Bei Fokusverlust
Weitere Steuerelemente
Die übrigen Steuerelemente wie Listenfelder, Kontrollkästchen oder Optionsgruppen
haben je nach Typ unterschiedliche Ereignisse. Nachdem Sie erfahren haben, wie Sie
die Abfolge der Ereignisse von Formularen und Steuerelementen ermitteln, soll an dieser
Stelle nicht weiter auf die Ereignisse der noch nicht besprochenen Steuerelemente
und ihre Abfolge eingegangen werden. Diesbezügliche Unklarheiten lassen sich leicht
experimentell beseitigen, indem Sie die betroffenen Ereignisse mit entsprechenden
Prozeduren ausstatten.
196

Abbildung verschiedener Beziehungsarten
3.5 Abbildung verschiedener Beziehungsarten
Die vorhandene Fachliteratur beschränkt sich weitgehend auf die Darstellung von Daten
aus einzelnen oder aus per 1:n-Beziehung verknüpften Tabellen. Daher erhalten Sie in
diesem Abschnitt des Kapitels einen Überblick über die Realisierung der verschiedenen
Beziehungsarten in Formularen.
3.5.1 Einfache Daten in der Detailansicht
Die Daten aus einzelnen Tabellen oder einfachen Abfragen lassen sich mit wenigen
Schritten in einem Formular darstellen. Üblicherweise sind hier zwei Darstellungen gefragt:
Detailansichten oder Übersichtslisten.
Mit »einfachen Abfragen« sind hier Abfragen gemeint, deren Daten quasi wie eine
Tabelle gehandhabt werden – also etwa Abfragen, die zwei per 1:1-Beziehung verknüpfte
Tabellen darstellen oder die eine einzelne Tabelle mit einem oder mehreren Lookup-
Feldern beinhalten.
Detailansichten dienen dazu, die sich oft über viele Felder erstreckenden Daten in einer
Form anzuzeigen, die die Daten einerseits vernünftig strukturiert und andererseits eine
komfortable Bearbeitung ermöglicht.
Übersichtslisten dienen selten dazu, die Daten kompletter Tabellen anzuzeigen – es sei
denn, diese enthalten nicht besonders viele Felder.
Wenn der Benutzer scrollen muss, um alle Felder eines Formulars sehen zu können, ist
die Menge der angezeigten Felder zu groß.
Meist dienen solche Übersichtslisten dazu, wichtige Informationen zu den angezeigten
Datensätzen sowie die Anzeige einer Detailansicht zu bieten.
Übersichtlisten gibt es in drei Formen: als Endlosformular, Datenblattansicht oder in
geteilten Formularen.
Detailansicht einfacher Daten in Formularen
Die Erstellung einer Detailansicht einfacher Daten läuft in folgenden Schritten ab:
» Anlegen eines neuen, leeren Formulars
» Festlegen der Datensatzquelle im Eigenschaftsfenster
» Einfügen der benötigten Felder (Ribboneintrag Entwurf|Tools|Vorhandene Felder hinzufügen,
siehe Abbildung 3.26)
» Anpassen und Ausrichten der Felder und Anpassen der Beschriftungen
197

Kapitel 3 Formulare
Das ist im Prinzip einfach. Wichtig ist lediglich, dass Sie beim Anlegen der Datensatzquelle
in Schritt 2 darauf achten, dass die Datensatzquelle nur die Felder enthält, die Sie auch
wirklich benötigen.
Abbildung 3.26: Das Hinzufügen der Einträge der Feldliste in das Formular kann durch Ziehen
mit der Maus erfolgen
Muss man in Detailansichten blättern können?
Die oben erstellte Detailansicht enthält einige Elemente, die die Navigation in den
Datensätzen des Formulars erleichtern:
» Bildlaufleisten
» Datensatzmarkierer
» Navigationsschaltflächen
Das Formular aus Abbildung 3.27 enthält all diese Elemente. Die Frage ist nun: Welche
davon benötigen Sie in einer Detailansicht?
Was zu einer anderen Frage führt: Was macht der Benutzer eigentlich mit dieser
Detailansicht?
Nun, er soll die Details eines Datensatzes betrachten und gegebenenfalls die enthaltenen
Daten ändern beziehungs weise neue Datensätze anlegen oder bestehende löschen
können.
Soll er mit der Na vi gationsleiste arbeiten, um innerhalb der Datensätze zu navigieren?
Seit Access 2007 vielleicht: Immerhin befindet sich dort ein Suchen-Feld.
198

Abbildung verschiedener Beziehungsarten
Optimal wäre es trotzdem, wenn der Benutzer die oben genannten Elemente gar nicht
be nötigt, sondern mit anderen Mitteln zu einem gesuchten oder einem neuen Datensatz
ge langt – immerhin ist nicht jeder Benutzer mit diesen Steuerelementen vertraut und
in tuitiv zu bedienen sind sie auch nicht unbedingt.
Abbildung 3.27: Die Formularansicht des Detailformulars
Angenommen, der Benutzer benötigt diese zusätzlichen Elemente gar nicht: Dann zeigen
Sie diese doch gar nicht an.
Drei Mausklicks im Eigenschaftsfenster der Entwurfsansicht des Formulars, einer noch,
wenn das Formular beim Öffnen zentriert angezeigt werden soll, was immer Sinn macht,
und noch eine Beschriftung hinzufügen – blitzschnell sieht das Eigenschaftsfenster wie
in Abbildung 3.28 und das Formular wie in Abbildung 3.29 aus.
Abbildung 3.28: Eigenschaften eines Formulars …
199

Kapitel 3 Formulare
Abbildung 3.29: … ohne unnötigen Schnickschnack (frmKontakteDetailansicht)
Navigation und Aktion in Detailformularen
Nun fehlen noch die Möglichkeiten zum Auswählen eines Datensatzes, zum Anlegen
eines neuen und Löschen des bestehenden Datensatzes. Nur: Müssen diese Elemente
auf das Detailformular? Das ist sicher Geschmackssache, aber Sie sollten sich für eine
der folgenden beiden Möglichkeiten entscheiden: Entweder Sie verwenden nur eine OK­
und eine Abbrechen-Schaltfläche oder Sie fügen neben einer Möglichkeit zur Auswahl
von Datensätzen auch noch je eine Schaltfläche zum Löschen und zum Anlegen von
Datensätzen hinzu.
Nachfolgend finden Sie eine Beschreibung der ersten Variante. Die Schaltflächen zum
Auswählen, Anlegen und Löschen eines Datensatzes werden in Zusammenhang mit den
unten beschriebenen Übersichtsformularen in der Endlos- und der Datenblattansicht
beschrieben.
OK- und Abbrechen-Schaltflächen
Diese beiden Schaltflächen lösen jeweils Prozeduren mit nur einer Zeile VBA-Code aus.
Legen Sie die beiden Schaltflächen an, stellen Sie die Eigenschaft Beschriftung auf die
Werte OK und Abbrechen und die Eigenschaft Name auf die Werte cmdOK und cmdAbbrechen
ein. Legen Sie dann für beide je eine Prozedur für die Ereigniseigenschaft Beim
Klicken an (siehe Abbildung 3.30):
200
Private Sub cmdOK_Click()
End Sub
DoCmd.Close acForm, Me.Name
Private Sub cmdAbbrechen_Click()
End Sub
Me.Undo
DoCmd.Close acForm, Me.Name
Listing 3.4: Schließen mit und ohne Übernahme der Änderungen

Abbildung verschiedener Beziehungsarten
Die OK-Schaltfläche sorgt in der Regel nur dafür, dass ein Formular geschlossen wird.
Es gibt aber auch Ausnahmen: Wenn ein Formular geöffnet wurde, um Daten zu ermitteln,
die in der aufrufenden Routine weiter verarbeitet werden sollen, müssen diese
vor dem Schließen natürlich erst abgefragt werden. Wie dies funktioniert, erfahren Sie
weiter unten in »Von Formular zu Formular« ab Seite 235.
Abbildung 3.30: Anlegen der Beim Klicken-Ereigniseigenschaft für eine Schaltfläche (frmDetailansicht)
3.5.2 Einfache Daten in der Übersicht mit Endlosformularen
Ein Formular zur Anzeige der Übersicht von Datensätzen enthält die gleiche Daten satzquelle
wie das Formular zur Anzeige der Detailansicht, in der Regel jedoch mit weniger
Feldern. Für Tabellen, die so wenige Felder enthalten, dass diese leicht neben einander
angezeigt werden können, braucht prinzipiell gar keine Detailansicht erstellt zu werden.
Die Felder sind meist wie in Abbildung 3.31 nebeneinander angeordnet. In der Abbildung
finden Sie direkt die Elemente zum Steuern von Aktionen wie Neu anlegen, Löschen und
Bearbeiten von Datensätzen.
Abbildung 3.31: Entwurfsansicht eines Übersichtsformulars (frmKontakteEndlosformular)
201

Kapitel 3 Formulare
Die OK-Schaltfläche dient wie die Schaltfläche des zuvor beschriebenen Formulars lediglich
dem Schließen des Formulars.
Die Neu-Schaltfläche soll das oben beschriebene Formular zur detaillierten Ansicht
eines Datensatzes öffnen und einen leeren Datensatz anzeigen. Dafür ist die folgende
Ereigniseigenschaft verantwortlich, die durch das Beim Klicken-Ereignis der Schaltfläche
ausgelöst wird.
Formular mit leerem Datensatz öffnen
Die Routine verwendet die OpenForm-Methode des DoCmd-Objekts zum Öffnen des
For mu lars frmKontakteDetailansicht. Der Parameter DataMode erhält dabei den Wert
acForm Add, damit das Formular beim Öffnen direkt einen leeren Datensatz anzeigt.
Formular als modalen Dialog öffnen
Der Wert des Parameters WindowMode liefert die Voraussetzung dafür, dass das aufrufende
Formular – die Übersicht – den angezeigten Datenbestand direkt nach dem
Eingeben des neuen Datensatzes und Schließen des Detailformulars aktualisieren kann
(siehe Abbildung 3.32). Durch den Wert acDialog wird das Formular frmKontakteDetailansicht
als modaler Dialog geöffnet, was bedeutet, dass innerhalb der Access-Anwendung
nichts mehr geht, solange dieses Formular geöffnet ist – selbst der aufrufende Code
wird währenddessen angehalten. Erst wenn das Formular den Fokus verliert, also geschlossen
oder unsichtbar gemacht wird, läuft die aufrufende Routine weiter. Dadurch
kann die Übersicht direkt nach dem Schließen der Detailansicht aktualisiert werden.
202
Private Sub cmdNeu_Click()
End Sub
DoCmd.OpenForm "frmKontakteDetailansicht", DataMode:=acFormAdd, _
WindowMode:=acDialog
Me.Requery
Listing 3.5: Aufrufen des Detailformulars zum Anlegen eines neuen Datensatzes
Löschen von Datensätzen
Die nächste Schaltfläche dient dem Löschen des aktuell markierten Datensatzes. Die
ein fachste Variante des benötigten Codes sieht wie folgt aus:
Private Sub cmdLoeschen_Click()
End Sub
On Error Resume Next
DoCmd.RunCommand acCmdDeleteRecord
Listing 3.6: Löschen eines Datensatzes

Abbildung verschiedener Beziehungsarten
Abbildung 3.32: Öffnen eines Eingabeformulars vom Übersichtsformular aus (frmKontakte­
Endlos formular, frmKontakteDetailansicht)
Die Routine verwendet die RunCommand-Methode des DoCmd-Objekts mit dem Pa rame
ter acCmdDeleteRecord, um den aktuell markierten Datensatz zu löschen.
Da hier eigent lich nur der Fehler auftreten kann, dass kein Datensatz markiert ist, verhindern
Sie diesen mit der On Error Resume Next-Anweisung im Vorhinein.
Alternativ können Sie den ak tuellen Datensatz im Übrigen auch mit folgender Anweisung
löschen:
Me.Recordset.Delete
Etwas weniger rudimentär gestalten Sie das Abfangen dieses Fehlers, wenn Sie die On
Error Resume Next-Anweisung durch folgenden Code ersetzen. Dieser prüft, ob aktuell
kein Datensatz ausgewählt ist, und bricht in diesem Fall mit einer entsprechenden
Meldung ab:
If IsNull(Me!KontaktID) Then
End If
MsgBox "Bitte wählen Sie zunächst einen Datensatz aus."
Exit Sub
Sollte die Anzeige von Warnmeldungen bei Datensatzänderungen aktiviert sein (siehe
Abbildung 3.25), erscheint hier allerdings eine unschöne Meldung (siehe Abbildung 3.33).
Abbildung 3.33: Access-Meldung beim Löschen eines Datensatzes
203

Kapitel 3 Formulare
Wenn Sie diese Meldung durch eine eigene Meldung ersetzen möchten, verwenden Sie
die folgende Prozedur:
204
Private Sub cmdLoeschen_Click()
On Error Resume Next
DoCmd.SetWarnings False
If MsgBox("Möchten Sie den Kontakt '" & Me!Vorname & " " _
End If
End Sub
& Me!Nachname & "' wirklich löschen?", vbYesNo + vbExclamation, _
"Löschbestätigung") = vbYes Then
DoCmd.RunCommand acCmdDeleteRecord
DoCmd.SetWarnings True
Listing 3.7: Löschen eines Datensatzes mit benutzerdefinierter Warnmeldung
Die SetWarnings-Methode des DoCmd-Objekts deaktiviert dabei die Anzeige der eingebauten
Meldung und aktiviert diese anschließend wieder.
Anzeigen der Details zu einem Datensatz
Die letzte Schaltfläche des Übersichtsformulars dient dem Anzeigen der Detailansicht
des ausgewählten Datensatzes. Die dadurch ausgelöste Routine prüft zunächst, ob ein
Datensatz markiert ist.
Falls ja, öffnet sie das Detailformular wiederum mit der DoCmd.OpenForm-Methode. In
diesem Fall kommt für den Parameter DataMode jedoch der Wert acFormEdit zum Zuge
und der anzuzeigende Datensatz wird mit dem Parameter WhereCondition festgelegt.
Dieser erwartet als Wert – wie der Name schon sagt – eine Bedingung, die den anzuzeigenden
Datensatz festlegt. Hier lautet die Bedingung, dass der Wert des Feldes
KontaktID dem des ausgewählten Datensatzes im Übersichtsformular entsprechen
muss.
Private Sub cmdBearbeiten_Click()
If IsNull(Me!KontaktID) Then
End If
End Sub
MsgBox "Bitte wählen Sie zunächst einen Datensatz aus."
Exit Sub
DoCmd.OpenForm "frmKontakteDetailansicht", DataMode:=acFormEdit, _
WindowMode:=acDialog, WhereCondition:="KontaktID = " & Me!KontaktID
Listing 3.8: Öffnen eines Datensatzes in der Detailansicht

Abbildung verschiedener Beziehungsarten
3.5.3 Einfache Daten in der Übersicht als Datenblatt
Neben der Endlosansicht ist auch die Datenblattansicht von Formularen für die Ver wendung
als Übersichtsformular geeignet. Die Datenblattansicht hat den Vorteil, dass der
Be nutzer dort selbst die Spaltenbreite einstellen kann – das ist bei Endlosformularen
mit unter ein Problem, wenn wenig Platz vorhanden oder die maximale Länge der anzuzeigenden
Zeichenketten nicht bekannt ist. Auch die Performance ist in dieser Ansicht
besser. Allerdings hat auch das Endlosformular Vorteile. Warum das so ist, erfahren Sie,
wenn Sie das Formular frmKontakteUebersicht einmal in der Datenblattansicht anzeigen
(siehe Abbildung 3.34). Das Datenblatt ist zwar als Übersicht akzeptabel, aber Kopf- und
Fußbereich des Formulars sind völlig verschwunden. Tatsache ist: Beide können in der
Datenblattansicht schlicht nicht verwendet werden.
Abbildung 3.34: Übersichtsformular in der Datenblattansicht (sfmKontakteDatenblattansicht)
Datenblattansicht im Unterformular
Wer dennoch ein Formular in der Datenblattansicht verwenden möchte, setzt dies als
Un terformular in ein Hauptformular ein, das die Navigationselemente zum Anlegen, Löschen
und Bearbeiten der Einträge bereitstellt. Das Unterformular enthält einfach nur
die Felder, die in der Datenblattansicht angezeigt werden sollen (siehe Abbildung 3.35).
Abbildung 3.35: Der Entwurf eines Formulars in der Datenblattansicht braucht keine besonderen
optischen Ansprüche zu erfüllen.
Es gibt lediglich drei Punkte, auf die Sie achten sollten:
» Stellen Sie die Eigenschaft Standardansicht auf Datenblatt ein.
205

Kapitel 3 Formulare
» Versehen Sie die Bezeichnungsfelder der einzelnen Steuerelemente mit ordentlichen
Beschriftungen, da diese später als Feldüberschriften dienen.
» Sorgen Sie für die richtige Aktivierreihenfolge, da diese festlegt, in welcher Rei henfol
ge die einzelnen Felder später angezeigt werden (Dialog öffnen über den Eintrag
Aktivierreihenfolge des Steuerelement-Kontextmenüs).
Hauptformular als Container für ein Unterformular in der
Datenblattansicht
Bereiten Sie dann das Hauptformular vor. Dazu legen Sie ein neues, leeres Formular an
und kopieren die bereits erstellten Schaltflächen des Formulars frmKontakteEndlosformu
lar in den Detailbereich des neuen Formulars.
Lassen Sie dabei ein wenig Platz nach oben. Ziehen Sie dann das neue Unterformular
aus dem Navigationsbereich in den De tail bereich des Formulars (siehe Abbildung 3.36).
Abbildung 3.36: Ziehen des Unterformulars aus dem Navigationsbereich in den Detailbereich des
neuen Hauptformulars
Anpassen der Datenblattansicht eines Formulars
Das Erste, was Ihnen beim Blick auf die Formularansicht auffallen wird, ist, dass standardmäßig
fast alle Steuerelemente in Formularen in Schriftgröße 11 dargestellt werden,
das Unterformular in der Datenblattansicht aber mit Schriftgröße 10 aufwartet.
Außerdem ist die Breite der Felder des Unterformulars natürlich nicht den Inhalten angepasst.
Beides holen Sie nach – allerdings nicht in der Entwurfsansicht, sondern in
der Formularansicht des Unterformulars. Dieses müssen Sie dafür allerdings noch ein-
206

Abbildung verschiedener Beziehungsarten
mal separat öffnen. Wenn Tabellen, Abfragen und Formulare in der Datenblattansicht
grundsätzlich in einer anderen Schriftgröße oder in anderem Layout geöffnet werden
sollen, können Sie die gewünschten Einstellungen in den Access-Optionen im Bereich
Datenblatt anpassen. Dort finden Sie auch die neue Option zum Einstellen einer alternativen
Hintergrundfarbe.
Wenn Sie die dortigen Einstellungen je Formular individuell vergeben möchten, können
Sie dies entweder mit dem Ribbon-Eintrag Start|Textformatierung|Alternative Zeilenfarbe
im Entwurf oder Datenblatt|Formatierung|Alternative Zeilenfarbe in der Datenblattansicht
beziehungsweise per VBA durchführen.
Dazu hinterlegen Sie die folgende Prozedur für die Er eig nis ei gen schaft Beim Laden:
Private Sub Form_Load()
End Sub
Me.DatasheetAlternateBackColor = &HDDDDFF
Listing 3.9: Individuelles Anpassen der alternativen Hintergrundfarbe eines Formulars in der
Datenblattansicht
Die Farbe können Sie statt im hexadezimalen Format auch mit der RGB-Funktion angeben
– zum Beispiel so:
Me.DatasheetAlternateBackColor=RGB(255,240,204)
Wenn Sie die Farbe des aktuell angezeigten Datenblatts – unabhängig davon, ob es sich
um eine Tabelle, Abfrage oder ein Formular handelt – ändern möchten, können Sie diesen
Aufruf verwenden (beispielsweise im Direktfenster):
Screen.ActiveDatasheet.DatasheetAlternateBackColor=RGB(255,240,204)
Offensichtlich lässt sich die alternierende Farbe jedoch nicht auf eine der Design-
Farben einstellen – ein Wert wie 1 oder 2 wird als Schwarz interpretiert. Die übrigen
Einstellungen des Optionen-Dialogs können Sie ebenfalls auf diese Weise vor nehmen.
Die Namen der passenden Eigenschaften beginnen alle mit »Datasheet...«. Die Spaltenbreiten
bändigen Sie durch Ziehen des vertikalen Trennstriches zwischen zwei Spalten
und die Schriftgröße passen Sie in einem Dialog an, den Sie per Kon text me nü der
Titelleiste des Formulars öffnen. Solche Änderungen speichert der Benutzer etwa
mit Strg + S dauerhaft. Nachdem Sie im Hauptformular auch noch die Bildlaufleisten,
Datensatzmarkierer, Na vi gationsschaltflächen und Trennlinien deaktiviert haben, sieht
das Formular schon viel besser aus (siehe Abbildung 3.37).
Bezug auf Steuerelemente im Unterformular
Nun fehlen noch die Funktionen der Schaltflächen. Da sich die betroffenen Daten nun
in einem Unterformular befinden, können Sie nicht ohne Weiteres die Prozeduren aus
207

Kapitel 3 Formulare
dem Formular frmKontakteEndlosformular einsetzen – aber fast. Die Prozedur hinter der
Schaltfläche OK können Sie komplett übernehmen.
Abbildung 3.37: Datenblattansicht als Übersicht (frmKontakteDatenblattansicht)
Die Prozeduren zum Anlegen, Löschen und Bearbeiten des aktuell markierten
Datensatzes sehen nun folgendermaßen aus:
208
Private Sub cmdBearbeiten_Click()
If IsNull(Me!sfmKontakteDatenblatt!KontaktID) Then
End If
End Sub
MsgBox "Bitte wählen Sie zunächst einen Datensatz aus."
Exit Sub
DoCmd.OpenForm "frmKontakteDetailansicht", DataMode:=acFormEdit, _
WindowMode:=acDialog, WhereCondition:="KontaktID = " _
& Me!sfmKontakteDatenblatt!KontaktID
Me.Requery
Private Sub cmdLoeschen_Click()
If IsNull(Me!sfmKontakteDatenblatt.Form!KontaktID) Then
End If
MsgBox "Bitte wählen Sie zunächst einen Datensatz aus."
Exit Sub
DoCmd.SetWarnings False
If MsgBox("Möchten Sie den Kontakt '" _
End If
End Sub
& Me!sfmKontakteDatenblatt!Vorname & " " _
& Me!sfmKontakteDatenblatt!Nachname & "' wirklich löschen?", _
vbYesNo + vbExclamation, "Löschbestätigung") = vbYes Then
Me!sfmKontakteDatenblatt.SetFocus
DoCmd.RunCommand acCmdDeleteRecord
DoCmd.SetWarnings True

Private Sub cmdNeu_Click()
End Sub
Abbildung verschiedener Beziehungsarten
DoCmd.OpenForm "frmKontakteDetailansicht", DataMode:=acFormAdd, _
WindowMode:=acDialog
Me!sfmKontakteDatenblatt.Requery
Listing 3.10: Änderungen an den Prozeduren zum Löschen und Bearbeiten von Datensätzen im
Detailformular
Die Änderungen gegenüber den Prozeduren des Formulars mit der Endlosansicht sind
fett gedruckt. Dabei wird jeweils auf die im Unterformular befindlichen Steuerelemente
Bezug genommen, die im Formular frmKontakteEndlosformular alle im gleichen
Formular wie die Schaltflächen angesiedelt waren. Bei den Steuerelementen wird statt
Me!KontaktID etwa Me!sfmKontakteDatenblatt!Kontakt ID verwendet. Stattdessen könnte
man auch ausführlicher schreiben:
oder
Me!sfmKontakteDatenblatt.Form!KontaktID
Me.Controls("sfmKontakteDatenblatt").Form.Controls("KontaktID")
Vorteil Datenblattansicht
Ein klarer Vorteil der hier konstruierten erweiterten Datenblattansicht gegenüber der
Endlosansicht ist, dass nach dem Bearbeiten von Daten im Detailformular und der
Aktualisierung der überarbeiteten Daten im Übersichtsformular nicht der Datensatz
ge wechselt wird. Im Formular frmKontakteEndlosformular springt der Datensatzzeiger
nach dem Aktualisieren mit der Requery-Methode immer wieder auf den ersten Da tensatz.
Das ist in der Datenblattansicht nicht der Fall. Hier ist darüber hinaus nur eine
Ak tualisierung per Requery nach dem Anlegen eines neuen Datensatzes erforderlich,
im Detailformular vorgenommene Änderungen werden automatisch übernommen. Das
Gleiche gilt natürlich auch für die Datenblattansicht.
3.5.4 Daten in der Übersicht als Listenfeld
Die dritte Möglichkeit der Darstellung von Daten in der Übersicht ist die Verwendung
eines Listenfeldes. Wie Sie bemerkt haben werden, kann man mit den beiden zuvor beschriebenen
Varianten auch bereits in der Übersicht Daten verändern, wenn man nicht
gerade die einzelnen Steuerelemente sperrt oder die Eigenschaft RecordsetTyp des
Formulars auf Snapshot einstellt. Hier bringt das Listenfeld Vorteile: Es ist keine direkte
Bearbeitung möglich und außerdem scheint das Markieren zu bearbeitender oder zu
löschender Datensätze intuitiver zu sein. Davon abgesehen kann man den Doppelklick
für die schnelle Anzeige des Detailformulars auslegen.
209

Kapitel 3 Formulare
Mit den folgenden Schritten haben Sie rasch ein Listenfeld als Übersicht erstellt:
» Legen Sie ein Listenfeld in einem leeren Formular an und vergrößern Sie es auf etwa
12 cm Breite.
» Stellen Sie die Eigenschaft Name auf lstKontakte ein.
» Legen Sie als Datensatzherkunft eine Abfrage an, die auf der Tabelle tblKontakte basiert
und nur die wichtigsten Felder KontaktID, Nachname, Vorname, Telefonnummer
und EMail enthält. Gegebenenfalls können Sie auch eine Sortierung festlegen – etwa
nach dem Nachnamen.
» Stellen Sie die Eigenschaften Spaltenanzahl und Spaltenbreiten auf die Werte 5 und
0cm;2cm:2cm;3cm ein. Dadurch wird die gebundene Spalte KontaktID ausgeblendet
(Primärschlüsselfelder soll man, wie oben bereits erläutert, nur anzeigen, wenn
diese geschäftliche Informationen enthalten). Das Feld muss aber dennoch in der
Abfrage und auch im Listenfeld enthalten sein, da sonst kein Bezug zum entsprechenden
Datensatz hergestellt werden kann. Die weiteren Spalten werden in der
entsprechenden Breite angezeigt und die letzte Spalte füllt den restlichen Platz
aus.
» Je nach Geschmack stellen Sie die Eigenschaft Spaltenüberschriften auf Ja ein oder
legen selbst Beschriftungsfelder oberhalb des Listenfeldes an. Bedenken Sie, dass
die Spaltenüberschriften – falls angezeigt – eine Zeile belegen und damit der Index
des ersten angezeigten Datensatzes nicht 0, sondern 1 ist.
Wenn Sie noch die obligatorischen Schaltflächen wie in den beiden vorherigen Bei spie len
hinzufügen und die Eigenschaften Bildlaufleisten, Datensatzmarkierer, Na vi ga tions schaltflächen
und Trennlinien auf Nein einstellen, sieht das Formular wie in Abbildung 3.38 aus.
Abbildung 3.38: Übersicht per Listenfeld (frmKontakteListenfeld)
Nun fehlen noch die dem Listenfeld angepassten Prozeduren zum Anlegen, Löschen
und Bearbeiten des aktuell ausgewählten Datensatzes. Hierbei ist zu beachten, dass
nach Änderungen immer die Requery-Methode des Listenfeld-Steuerelements ausgeführt
werden muss.
210

Abbildung verschiedener Beziehungsarten
Um den Wert des Feldes KontaktID für den aktuellen Listenfeldeintrag zu ermitteln, lesen
Sie einfach den Wert des Listenfeldes aus. Das Feld KontaktID ist das gebundene
Feld der Datensatzherkunft und dadurch mit dem Wert des Listenfeldes identisch. Eine
weitere Änderung ist zum Löschen des markierten Datensatzes notwendig: Mit DoCmd.
RunCommand acCmdDeleteRecord ist einem Eintrag im Listenfeld nicht bei zu kom men,
hier müssen Sie direkt mit einer DELETE-Anweisung auf die zugrunde liegende Ta belle
zugreifen.
Private Sub cmdBearbeiten_Click()
If IsNull(Me!lstKontakte) Then
End If
End Sub
MsgBox "Bitte wählen Sie zunächst einen Datensatz aus."
Exit Sub
DoCmd.OpenForm "frmKontakteDetailansicht", DataMode:=acFormEdit, _
WindowMode:=acDialog, WhereCondition:="KontaktID = " _
& Me!lstKontakte
Me!lstKontakte.Requery
Private Sub cmdLoeschen_Click()
If IsNull(Me!lstKontakte) Then
End If
MsgBox "Bitte wählen Sie zunächst einen Datensatz aus."
Exit Sub
DoCmd.SetWarnings False
If MsgBox("Möchten Sie den Kontakt '" & Me!lstKontakte & " " _
End If
End Sub
& Me!lstKontakte & "' wirklich löschen?", _
vbYesNo + vbExclamation, "Löschbestätigung") = vbYes Then
CurrentDb.Execute "DELETE FROM tblKontakte WHERE KontaktID = " _
& Me!lstKontakte
Me!lstKontakte.Requery
DoCmd.SetWarnings True
Private Sub cmdNeu_Click()
End Sub
DoCmd.OpenForm "frmKontakteDetailansicht", DataMode:=acFormAdd, _
WindowMode:=acDialog
Me!lstKontakte.Requery
Listing 3.11: Anlegen, löschen und bearbeiten von Datensätzen eines Listenfeldes
211

Kapitel 3 Formulare
3.5.5 1:1-Beziehungen
Die Daten aus 1:1-Beziehungen lassen sich genau wie die oben beschriebenen »einfachen
Daten« in Formularen abbilden. Sie können eine Abfrage über die an der 1:1-Beziehung
beteiligten Tabellen erstellen und genau die gleichen Formulare wie oben verwenden. Sie
können aber auch beispielsweise im Übersichtsformular nur die Daten der einen Seite der
Beziehung anzeigen und die Details erst im Detailformular offenbaren.
Einen kleinen Trick müssen Sie anwenden, wenn Sie sicherstellen wollen, dass auch in
der Erweiterungstabelle zu jedem Datensatz der Haupttabelle ein passender Datensatz
angelegt wird – auch ohne dass der Benutzer explizit Daten für die Erweiterungstabelle
eingibt. Dazu legen Sie eine kleine Prozedur an, die durch die Ereigniseigenschaft Vor
Aktualisierung des Formulars ausgelöst wird. Dieses Ereignis stellt einfach den Wert des
Verknüpfungsfeldes der Erweiterungstabelle auf den Wert des Primärschlüsselfeldes der
Haupttabelle ein:
212
Private Sub Form_BeforeUpdate(Cancel As Integer)
End Sub
Me!tblAngestellte_PersonID = Me!tblPersonen_PersonID
Listing 3.12: Synchronisieren von Haupt- und Erweiterungstabelle im Formular
Das Beispielformular finden Sie nicht in der Datenbank zu diesem Kapitel, sondern in
der Beispieldatenbank Abfragen.accdb unter dem Formularnamen frmAngestellte.
3.5.6 n:1-Beziehungen
n:1-Beziehungen bestehen aus einer Tabelle, von der ein Feld in Form einer anderen
Tabelle ausgelagert wurde – das einfachste Beispiel ist wohl das Feld Anrede in einer
Kontakt-, Adress- oder Mitarbeitertabelle. Die Darstellung und Auswahl der Daten aus
der Mastertabelle erfolgt im Formular über ein Kombinationsfeld.
Wer gute Vorarbeit leistet und per Nachschlage-Assistent oder von Hand bereits beim
Da tenentwurf dafür sorgt, dass die Daten aus verknüpften Tabellen in einem Kom bina
tionsfeld ausgewählt werden können, hat beim Erstellen eines Formulars für diese
Be ziehungsart leichtes Spiel: Das Kombinationsfeld wird dann automatisch an ge legt
(siehe Abbildung 3.39). Wie Sie eine Tabelle mit einem Kombinationsfeld zur Dar stellung
einer n:1-Beziehung erstellen, erfahren Sie in »n:1-Beziehungen oder Lookup-
Beziehungen« ab Seite 91.
Sollte es aus irgendwelchen Gründen nicht gewünscht sein, dass das Kombinationsfeld
direkt in der Tabelle angelegt wird, müssen Sie selbst Hand anlegen. In diesem Fall
zeigt das Formular nach dem Hinzufügen der Felder aus der Feldliste zunächst ein herkömmliches
Textfeld statt eines Kombinationsfeldes an.

Abbildung 3.39: Darstellung einer n:1-Beziehung im Formular
Abbildung verschiedener Beziehungsarten
Wenn Sie wissen, aus welcher Datei das Fremdschlüsselfeld seine Daten beziehen soll,
gehen Sie folgendermaßen vor:
» Konvertieren Sie das Textfeld in ein Kombinationsfeld, indem Sie aus dessen Kontext
menü den Eintrag Ändern zu|Kombinationsfeld auswählen.
» Stellen Sie die Eigenschaft Datensatzherkunft des frisch gebackenen Kombinationsfel
des auf die Tabelle tblAnreden ein.
» Legen Sie für die Eigenschaften Spaltenanzahl und Spaltenbreiten die Werte 2 und 0
fest. Es sollen beide Felder der Tabelle enthalten sein, aber nur die zweite mit den
Anreden selbst angezeigt werden.
Das Kombinationsfeld zeigt nun die vorhandenen Einträge wie in Abbildung 3.39 an.
3.5.7 1:n-Beziehungen
1:n-Beziehungen trifft man während des Entwicklerlebens vermutlich am häufigsten an,
vor allem, wenn man n:1-Beziehungen auch darunter einstuft.
Ein klassisches Beispiel für eine 1:n-Beziehung sind Projekte und Kunden, wobei die
Projekte in der Detailtabelle und die Kunden in der Mastertabelle gespeichert werden
(siehe Abbildung 3.40).
Abbildung 3.40: 1:n-Beziehung zwischen Projekten und Kunden
213

Kapitel 3 Formulare
Die Gestaltung des Formulars für die Anzeige der Projekte entspricht vom Aufbau her
dem Formular aus Abbildung 3.40 – es enthält die Daten zum jeweiligen Projekt und der
Kunde kann mit einem Kombinationsfeld ausgewählt werden.
Interessanter ist die Darstellung eines Kunden und seiner Projekte. Der Kunde wird
dabei wie in »Einfache Daten in der Detailansicht« ab Seite 197 an gezeigt. Zusätzlich
sollen aber nun die Projekte des Kunden im Überblick dargestellt werden – und dazu
gibt es wiederum verschiedene Möglichkeiten. Auch diese Mög lich kei ten kennen Sie bereits
– wenn auch in vereinfachter Form – aus den Ab schnitten »Einfache Daten in der
Übersicht mit Endlosformularen« ab Seite 201, »Einfache Daten in der Übersicht als
Datenblatt« ab Seite 205, »Daten in der Übersicht als Listenfeld« ab Seite 209 und
»Geteilte Formulare« ab Seite 172.
Dabei müssen Sie in diesem Fall sowohl das Endlosformular als auch die Datenblattansicht
in ein Unterformular ausgliedern; lediglich das Listenfeld können Sie direkt in
das Kunden-Formular integrieren.
Verknüpfte Daten direkt bearbeiten oder nicht?
Welche Variante Sie verwenden, hängt zunächst einmal davon ab, ob Sie die verknüpften
Daten – also die Projekte – direkt im Kundenformular bearbeiten möchten oder nicht.
Falls ja, verwenden Sie ein Unterformular mit den Projekten in einem Endlosformular
oder der Datenblattansicht, ansonsten entscheiden Sie sich für ein Unterformular mit
dem Recordset-Typ Snapshot oder ein Listenfeld.
Da die Unterformular-Varianten technisch ähnlich sind und beide in einfacher Form bereits
ausführlich erläutert wurden, soll hier nur eine der beiden Möglichkeiten beschrieben
werden – die etwas einfacher zu realisierende Datenblattansicht.
3.5.8 1:n-Beziehung per Unterformular und Datenblattansicht
Das Unterformular zur Anzeige der Projekte in der Datenblattansicht ist genauso wie
das aus »Einfache Daten in der Übersicht als Datenblatt« ab Seite 205 aufgebaut. Es
basiert allerdings auf einer Abfrage, die alle Felder der Tabelle tblProjekte enthält und
diese zusätzlich nach dem Startdatum sortiert (siehe Abbildung 3.41).
Vorbereiten des Unterformulars
Das Unterformular selbst enthält lediglich die drei Felder Projekt, Startdatum und Enddatum.
Die anderen Felder werden zwar für die Funktionalität benötigt, sollen aber nicht
angezeigt werden – und die Datenblattansicht zeigt immer alle im Entwurf enthal tenen
Felder an. Daran ändert auch das Einstellen der Sichtbar-Eigenschaft auf den Wert Nein
nichts. Die einzige Möglichkeit, ein Feld »unsichtbar« zu machen, ist das Verkleinern
der Spaltenbreite auf den Wert 0. Dies erreichen Sie mit dem Kontextmenü-Ein trag
214

Abbildung verschiedener Beziehungsarten
Format|Spalten ausblenden des Spaltenkopfes oder mit den VBA-Eigenschaften Co lumn­
Width und ColumnHidden.
Abbildung 3.41: Datensatzquelle des Unterformulars zur Anzeige der Projekte eines Kunden
(sfm Pro jekte)
Vergessen Sie nicht, die Eigenschaft Standardansicht auf Datenblatt einzustellen und
die Spaltenbreiten und Schriftgröße Ihren Bedürfnissen anzupassen. Speichern Sie das
Formular unter dem Namen sfmProjekte (siehe Abbildung 3.42).
Abbildung 3.42: Das Unterformular zur Anzeige der Projekte in der Entwurfsansicht
Erstellen des Hauptformulars
Das Hauptformular basiert auf der Tabelle tblKunden und zeigt alle darin enthaltenen
Felder an. Ordnen Sie die Felder wie in Abbildung 3.43. Anschließend fügen Sie das
Unterformular in das Hauptformular ein, indem Sie dieses aus dem Navigationsbereich
in den Entwurf des Hauptformulars ziehen. Damit das Unterformular nur die Projekte
des im Hauptformular angezeigten Kunden ausgibt, müssen zwei Eigenschaften des
Unterformularsteuerelements entsprechend eingestellt werden, was beim Einfügen
des Unterformulars normalerweise automatisch geschieht – zumindest wenn schon
eine Beziehung zwischen den beiden Tabellen angelegt wurde.
215

Kapitel 3 Formulare
Abbildung 3.43: Haupt- und Unterformular zur Anzeige von Kunden und Projekten
Die beiden Eigenschaften heißen Verknüpfen von und Verknüpfen nach und erwarten den
Namen des Fremdschlüsselfeldes der Datensatzquelle des Unterformulars und den
Namen des Primärschlüsselfeldes der Datensatzquelle des Hauptformulars. Diese beiden
Felder haben üblicherweise den gleichen Namen – in diesem Fall KundeID.
Die Verknüpfungsfelder müssen nicht zwangsläufig mit dem Primär schlüssel feld
des Hauptformulars und dem Fremdschlüsselfeld des Unterformulars gefüllt werden.
Es gibt auch Fälle, in denen beispielsweise der Wert eines Kombinationsfeldes
im Hauptformular zur Auswahl der passenden Datensätze im Unterformular herangezogen
wird – hier würde man einfach den Namen des Kombinationsfeldes als Wert
der Eigenschaft Verknüpfen nach verwenden. Um die Eigenschaften einzusehen oder anzupassen,
markieren Sie das Unterfor mu lar steuerelement – dieses ist keinesfalls mit
dem Unterformular selbst zu verwechseln! Am einfachsten markieren Sie es, wenn Sie
erst ein anderes Steuerelement des Haupt for mulars markieren und dann einfach auf
das Unterformular klicken.
Wenn das Ei gen schafts fenster im Register Daten die beiden Eigenschaften anzeigt, liegen
Sie richtig. Wenn Sie das Formular nun in der Formularansicht öffnen, sieht dieses
etwa wie in Abbildung 3.44 aus. Beim Wechseln zu einem anderen Datensatz des
Hauptformulars zeigt das Unterformular automatisch die passenden Projekte an.
Anlegen, bearbeiten und löschen im Detailformular
Eine Projekttabelle wird in der Regel nicht mit derart wenig Feldern auskommen. Sie
werden also normalerweise, wie unter »Einfache Daten in der Übersicht als Datenblatt«
ab Seite 205, ein Detailformular zur Anzeige der Projekte benötigen. Um dieses anzuzeigen,
neue Projekte anzulegen oder Projekte zu löschen, können Sie die ebenfalls in
dem genannten Abschnitt vorgestellten Schaltflächen einschließlich VBA-Code für das
Formular frmKunden anpassen.
216

Abbildung verschiedener Beziehungsarten
Abbildung 3.44: Das fertige Formular zur Anzeige von Kunden und Projekten (frmKunden)
Die Prozeduren zum Löschen eines Datensatzes und für die Anzeige zum Bearbeiten
sind prinzipiell mit den oben beschriebenen identisch; bei Bedarf finden Sie diese im
Klassenmodul des Formulars frmKunden.
Eine wichtige Neuerung liefert das Neuanlegen per Detailformular. In der Routine, die
durch das Anklicken der Schaltfläche cmdNeu ausgelöst wird, enthält die DoCmd.Open-
Anweisung einen bislang nicht verwendeten Parameter. Mit OpenArgs kann man einen
einzelnen Wert, auch Öffnungsparameter genannt, an das aufgerufene Formular übergeben.
In diesem Fall handelt es sich dabei um den Wert des Feldes KundeID.
Private Sub cmdNeu_Click()
End Sub
DoCmd.OpenForm "frmProjekteDetailansicht", DataMode:=acFormAdd, _
WindowMode:=acDialog, OpenArgs:=Me!KundeID
Me.Requery
Listing 3.13: Aufruf des Detailformulars mit Öffnungsargument
Der Hintergrund ist, dass neue Datensätze im Detailformular zur Anzeige der Projekte
direkt mit dem richtigen Kunden ausgestattet werden sollen (siehe Abbildung 3.45).
Damit das Detailformular den Öffnungsparameter auch auswertet, legen Sie dort für
die Ereigniseigenschaft Beim Öffnen die folgende Prozedur an. Die Prozedur prüft, ob
ein Öffnungsparameter übergeben wurde (das ist notwendig, da das Formular etwa zum
Bearbeiten auch ohne Öffnungsparameter geöffnet werden soll – das Fehlen des Öffnungs
arguments würde sonst einen Fehler auslösen) und weist diesen dann der Ei genschaft
DefaultValue des Feldes KundeID zu.
Dadurch wird der entsprechende Eintrag im Kombinationsfeld zur Anzeige der verknüpften
Werte voreingestellt.
217

Kapitel 3 Formulare
218
Private Sub Form_Open(Cancel As Integer)
If Not IsNull(Me.OpenArgs) Then
End If
End Sub
Me!KundeID.DefaultValue = Me.OpenArgs
Listing 3.14: Auswerten des Öffnungsarguments beim Öffnen eines Formulars
Abbildung 3.45: Das Kunden-Formular und die Detailansicht für Projekte mit einem neuen
Daten satz (frmKunden, frmProjekteDetailansicht)
3.5.9 1:n-Beziehung per Listenfeld
Wenn Sie ohnehin ein Formular für die Anzeige der Details der verknüpften Datensätze
des Hauptformulars verwenden, müssen beziehungsweise sollten Sie im Hauptformular
nicht die Möglichkeit zur Bearbeitung der verknüpften Daten bieten. In diesem Fall reicht
ein Listenfeld zu deren Anzeige aus; außerdem bietet es die Möglichkeit, Datensätze
zur Bearbeitung und zum Löschen auszuwählen – alles wie bereits unter »Daten in der
Übersicht als Listenfeld« ab Seite 209 beschrieben.
Eine Besonderheit gibt es jedoch: Die im Listenfeld angezeigten Daten hängen nun von
dem im Hauptformular angezeigten Datensatz ab. Dementsprechend muss bei einem
Wechsel des Hauptformulars auch der Inhalt des Listenfeldes aktualisiert werden (siehe
Abbildung 3.46).
Damit das Listenfeld jeweils die Projekte zu dem im Hauptformular angezeigten Kunden
ausgibt, legen Sie für die Ereigniseigenschaft Beim Anzeigen die folgende Routine an.
Diese stellt einen SQL-Ausdruck mit einer Abfrage zusammen, die alle anzuzeigenden
Felder der Tabelle tblProjekte ausgibt und dabei nur jene Datensätze berücksichtigt,
deren Feld KundeID mit dem Wert des Formularfeldes KundeID übereinstimmt. Diesen

Abbildung verschiedener Beziehungsarten
SQL-Ausdruck weist die Routine dann der Eigenschaft Datensatzherkunft (RowSource)
des Listenfeldes zu:
Private Sub Form_Current()
End Sub
Dim strSQL As String
strSQL = "SELECT ProjektID, Projekt, Startdatum, Enddatum " _
& "FROM tblProjekte WHERE KundeID = " & Me!KundeID
Me!lstProjekte.RowSource = strSQL
Listing 3.15: Synchronisieren des Listenfeldinhalts mit dem Hauptformular
Abbildung 3.46: Darstellung einer 1:n-Beziehung per Listenfeld (frmKundenListenfeld)
Projekt anzeigen per Doppelklick
Wenn Sie dem Benutzer zusätzlichen Komfort bieten möchten, legen Sie für das
Listenfeld eine Prozedur an, die beim Doppelklick auf das Listenfeld den aktuell markierten
Eintrag im Detailformular anzeigt. Dazu verwenden Sie die Ereigniseigenschaft
Beim Doppelklicken:
Private Sub lstProjekte_DblClick(Cancel As Integer)
If IsNull(Me!lstProjekte) Then
End If
End Sub
MsgBox "Bitte wählen Sie zunächst einen Datensatz aus."
Exit Sub
DoCmd.OpenForm "frmProjekteDetailansicht", DataMode:=acFormEdit, _
WindowMode:=acDialog, WhereCondition:="ProjektID = " & Me!lstProjekte
Me!lstProjekte.Requery
Listing 3.16: Anzeigen der Detailansicht eines Projekts
219

Kapitel 3 Formulare
Die Routine hat exakt den gleichen Inhalt wie die Ereignisprozedur, die durch einen Klick
auf die Schaltfläche Bearbeiten ausgelöst wird. Den enthaltenen Code extrahieren Sie am
besten in eine separate neue Routine, die Sie von beiden Ereignisprozeduren aufrufen.
Wie das aussieht, können Sie dem Klassenmodul des Formulars frmKunden Listenfeld in
der Beispieldatenbank Formulare.accdb unter www.acciu.de/aeb2010 entnehmen.
3.5.10 m:n-Beziehungen in Haupt- und Unterformular
Wie bereits erwähnt, bieten Listenfelder zur Verwaltung von Daten aus m:n-Beziehungen
nicht den Komfort, dass man die im Listenfeld angezeigten Daten direkt bearbeiten
kann. Dafür ist eine andere Lösung wesentlich sinnvoller: Die Darstellung einer m:n-
Beziehung in einer Kombination aus Formular und Unterformular.
Dabei zeigt das Hauptformular die Daten der einen Seite der Beziehung an, während das
Unterformular die Daten der Verknüpfungstabelle und der anderen Seite der Be zie hung
enthält.
Das bekannteste Beispiel für eine solche Darstellung ist vermutlich das Formular Bestel
lun gen aus der Nordwind-Datenbank (siehe Abbildung 3.47).
Abbildung 3.47: Beispiel für die Verwaltung von Daten in einer m:n-Beziehung
Zu Demonstrationszwecken reicht eine einfache m:n-Beziehung mit den notwendigsten
Feldern wie in Abbildung 3.48. Die beiden Tabellen tblProjekte und tblMitarbeiter werden
über die Verknüpfungstabelle tblProjektzeiten miteinander verbunden. Interessant wird
220

Abbildung verschiedener Beziehungsarten
dieses Beispiel durch die Tatsache, dass auch die Verknüpfungstabelle einige Felder
enthält – in diesem Fall sogar die wichtigsten.
Die Verknüpfungstabelle dient dem Speichern der Zeiten, die die Mitarbeiter mit den jeweiligen
Projekten verbracht haben. Um diese Informationen nicht nur quantitativ, sondern
auch qualitativ auswerten zu können, wird nicht nur die Zeit, sondern auch das
Datum der Tätigkeit gespeichert.
Für die Beziehungen legen Sie referentielle Integrität fest, da so sichergestellt ist, dass
für jeden Eintrag in die Tabelle tblProjektzeiten ein Projekt und ein Mitarbeiter ausgewählt
werden.
Wer dieses Beispiel ausbauen möchte, wird natürlich die Projekt- und die Mitarbeitertabelle
noch um einige Felder erweitern. Aber auch die Verknüpfungstabelle tbl Projekt
zeiten kann noch weitere wichtige Informationen speichern: etwa eine Kurz beschrei
bung der jeweiligen Tätigkeit und eine Tätigkeitsart wie Konzeption, Pro grammie
rung oder Test.
Abbildung 3.48: Datenmodell der Beispieltabellen
Hauptformular der m:n-Beziehung
Bevor Sie sich der Erstellung des Hauptformulars zuwenden, müssen Sie bei m:n-Beziehungen
jeweils zunächst überlegen, von welcher der beiden Tabellen Sie nur je einen
Datensatz im Hauptformular anzeigen möchten und welche Tabelle die Datensätze für
das Unterformular liefert.
Im vorliegenden Fall sind beide Varianten interessant: Man könnte sich sowohl zu jedem
Projekt die Zeiten ansehen, die die einzelnen Mitarbeiter damit verbracht haben,
andererseits ist es vielleicht nicht ganz uninteressant, womit der eine oder andere
Mitarbeiter seine Zeit verbringt.
Wichtiger für die Auswertung von Projekten ist sicher die erste Variante. Das Hauptfor
mular zeigt also die Daten der Tabelle tblProjekte an, die dementsprechend auch als
Datensatzquelle des Formulars dient. Wenn Sie aus der Feldliste die beiden Fel der Projekt
ID und Projekt in den Detailbereich des Formulars ziehen, ist der erste Teil der Arbeit
be reits erledigt (siehe Abbildung 3.49).
221

Kapitel 3 Formulare
Abbildung 3.49: Hauptformular der m:n-Beziehung (frmProjektzeiten)
Als Nächstes fügen Sie nun noch das Unterformular zur Anzeige der Mitarbeiter und der
jeweiligen Projektzeiten hinzu.
Unterformular der m:n-Beziehung
Das Unterformular soll anzeigen, welcher Mitarbeiter an welchem Datum wie viele
Stunden mit einem Projekt verbracht hat. Dazu legen Sie für das Unterformular die
Abfrage aus Abbildung 3.50 als Datensatzquelle an.
Abbildung 3.50: Datensatzquelle des Unterformulars der m:n-Beziehung
Der Aufbau dieser Abfrage ist für alle Unterformulare von Formularen zur Darstellung
von m:n-Beziehungen gleich. Die Abfrage enthält jeweils die Verknüpfungstabelle und
die Tabelle, deren Daten nicht im Hauptformular angezeigt werden – in diesem Fall also
die Tabellen tblProjektzeiten und tblMitarbeiter. Auch für die Felder gibt es feste Regeln.
Sie benötigen immer folgende Felder:
» Fremdschlüsselfeld der Verknüpfungstabelle zur Tabelle, die im Hauptformular angezeigt
wird (hier ProjektID).
» Fremdschlüsselfeld der Verknüpfungstabelle zur anderen Tabelle der m:n-Beziehung
(hier MitarbeiterID). Dieses Feld wird in der Regel als Kombinationsfeld ausgeführt,
damit ein Datensatz dieser Tabelle ausgewählt werden kann.
222

Abbildung verschiedener Beziehungsarten
» Alle sonstigen Felder der Verknüpfungstabelle und der im Unterformular anzuzeigenden
Tabelle, die im Unterformular angezeigt werden sollen (hier die Felder
Datum und Zeit der Tabelle tblProjektzeiten und Telefon der Tabelle tblMitarbeiter).
Im Unterformular stellen Sie dann die Eigenschaft Datensatzherkunft auf die soeben
erstellte Abfrage ein. Im Detailbereich des Unterformulars finden nicht alle Felder der
zugrunde liegenden Abfrage Platz: Das Fremdschlüsselfeld, das auf den entsprechenden
Datensatz des Hauptformulars verweist, muss nicht angezeigt werden.
Lediglich das Feld zur Auswahl des Mitarbeiters sowie einige weitere Felder sollen später
sichtbar sein (siehe Abbildung 3.51).
Abbildung 3.51: Das Unterformular der m:n-Beziehung in der Entwurfsansicht
Datenblatt- oder Endlosansicht?
Da das Unterformular mehrere Datensätze anzeigen soll, stehen die Datenblatt- und
die Endlosansicht zur Verfügung. Wenn Sie keine besonderen Ansprüche an das Layout
der Steuerelemente im Unterformular haben und außer Text- und Kombinationsfeldern
keine Steuerelemente benötigen, sind Sie mit der Datenblattansicht gut bedient. In
diesem Beispiel ist das der Fall; stellen Sie daher die Eigenschaft Standardansicht auf
Datenblattansicht ein.
Das Unterformular sieht in der Datenblattansicht nun wie in Abbildung 3.52 aus. Wenn
Sie bereits Daten in die Tabelle tblMitarbeiter eingegeben haben oder die Tabellen und
Formulare aus der Beispieldatenbank verwenden, können Sie das Unterformular bereits
testen. Die Auswahl eines Mitarbeiters per Kombinationsfeld sorgt automatisch für
das Füllen der übrigen Felder, die Sie aus der Tabelle tblMitarbeiter in das Unterformular
übernommen haben.
Fehlt noch eine Eingabe in die beiden Felder Datum und Zeit und das Speichern eines
neuen Datensatzes. Letzteres schlägt wegen der Regeln zur referentiellen Integrität
freilich fehl, da noch kein Wert für das Feld ProjektID der Abfrage qryProjektzeiten angegeben
wurde – was ja auch gar nicht geht, da das Feld überhaupt nicht im Formular
angezeigt wird.
223

Kapitel 3 Formulare
Abbildung 3.52: Das Unterformular in der Datenblattansicht
Wie sollen Sie also Datensätze im Unterformular anlegen, wenn Sie gar keinen Zugriff
auf eines der wichtigsten Felder haben? Ganz einfach: Sie automatisieren die Eingabe
der Werte für dieses Feld. Das Unterformular ist ja eigentlich für den Einsatz im Hauptfor
mular frmProjektzeiten gedacht, in das Sie es nun einfügen können.
Nachdem Sie das Unterformular in das Hauptformular eingefügt haben, werfen Sie einen
Blick auf die Eigenschaften Verknüpfen von und Verknüpfen nach (siehe Abbildung 3.53).
Dort sollte Access beim Einfügen des Unterformulars automatisch jeweils den Wert
ProjektID eingetragen haben. Diese Einstellung gewährleistet Folgendes:
» Das Feld ProjektID wird bei neuen Datensätzen im Unterformular automatisch mit
dem entsprechenden Wert des Hauptformulars gefüllt.
» Das Unterformular zeigt nur Datensätze an, deren ProjektID dem entsprechenden
Wert des Hauptformulars entspricht.
Abbildung 3.53: Verknüpfen von Haupt- und Unterformular
Ein Wechsel in die Formularansicht demonstriert die Funktion des Formulars. Sie können
nun einen neuen Datensatz im Hauptformular anlegen und im Unterformular die
gewünschten Projektzeiten eintragen. Dazu wählen Sie dort einfach den Mitarbeiter
224

Abbildung verschiedener Beziehungsarten
aus und geben Datum und Zeit ein – um den Inhalt des Feldes ProjektID kümmert sich
Access selbst (siehe Abbildung 3.54).
Abbildung 3.54: m:n-Beziehung im Einsatz
3.5.11 m:n-Beziehungen per Listenfeld
Die Verwaltung von Daten aus m:n-Beziehungen erfolgt verhältnismäßig selten mit Hilfe
von Listenfeldern. Der Grund ist, dass Listenfelder keine direkte Bearbeitung der angezeigten
Daten ermöglichen. Daher sind Listenfelder eher zum übersichtlichen Zu wei sen
von Datensätzen der n-Seite zu den Datensätzen der m-Seite einer Beziehung ein setzbar.
Einsatzzwecke für die Anwendung von Listenfeldern in Zusammenhang mit m:n-Bezie
hungen gibt es genug: Die Verwaltung von Verteilerlisten, die das Zuordnen von
Empfängern zu einer Publikation ermöglichen, Benutzer und Benutzergruppen (wie im
obigen Beispiel) oder Fahrzeuge und Sonderausstattungen.
Das folgende Formular soll anhand des Beispiels der Fahrzeuge und Aus stat tungs merkmale
hergeleitet werden. Zum Nachvollziehen benötigen Sie drei Tabellen: Die beiden
Tab ellen tblFahrzeuge und tblAusstattungen werden über die Tabelle tblFahrzeugeAusstattungen
miteinander verknüpft (siehe Abbildung 3.55). Für die beiden Beziehungen
legen Sie jeweils referentielle Integrität mit Löschweitergabe fest.
Abbildung 3.55: Datenmodell der Beispieltabellen
225

Kapitel 3 Formulare
Das Formular zur Verwaltung der enthaltenen Daten besitzt als Datensatzquelle die
Tabelle tblFahrzeuge und enthält die folgenden Steuerelemente (siehe Abbildung 3.56):
» FahrzeugID und Fahrzeug: Textfelder, gebunden an die Datensatzquelle des For mu lars.
» lstVorhandeneAusstattung: Zeigt alle Datensätze der Tabelle tblAusstattungen an, die
über die Tabelle tblFahrzeugeAusstattungen mit der Tabelle tblFahrzeuge verknüpft sind.
» lstNichtVorhandeneAusstattung: Zeigt alle Datensätze der Tabelle tblAusstattungen
an, die das Listenfeld lstVorhandeneAusstattung nicht anzeigt.
» cmdEntfernen: Verschiebt das aktuell im linken Listenfeld markierte Aus stat tungsmerk
mal in das rechte Listenfeld.
» cmdAlleEntfernen: Verschiebt alle Einträge des linken Listenfeldes in das rechte Listen
feld.
» cmdHinzufuegen: Verschiebt das aktuell im rechten Listenfeld markierte Aus stattungs
merk mal in das linke Listenfeld.
» cmdAlleHinzufuegen: Verschiebt alle Einträge des rechten Listenfeldes in das linke
Lis tenfeld.
Zusätzlich zu den bereits erwähnten Funktionen soll ein Doppelklick auf einen Eintrag
eines der Listenfelder den betroffenen Eintrag in das jeweils andere Listenfeld verschieben.
Abbildung 3.56: Entwurfsansicht des Formulars zum Festlegen der Ausstattungsmerkmale eines
Fahrzeugs
Datensatzherkunft der Listenfelder
Die Beschreibung der Steuerelemente des Formulars hat den Inhalt der beiden Lis tenfel
der bereits scharf umrissen. Da der Inhalt des rechten Listenfeldes vom Inhalt des
linken Lis tenfeldes abhängt, beginnen Sie mit dem linken Listenfeld.
226

Abbildung verschiedener Beziehungsarten
Es soll alle Datensätze der Tabelle tblAusstattungen enthalten, die über die Tabelle
tblFahrzeugeAusstattungen mit der Tabelle tblFahrzeuge verknüpft sind. Das aktuell
angezeigte Fahr zeug lässt sich über das Feld FahrzeugID identifizieren. Da die
Verknüpfungstabelle den entsprechenden Wert bereits enthält, besteht die Abfrage für
die Datensatzher kunft aus den beiden Tabellen tblFahrzeugeAusstattungen und tblAusstattungen
(siehe Abbildung 3.57).
Das Listenfeld soll die Bezeichnung des Ausstattungsmerkmals anzeigen, aber das
Feld AusstattungID als gebundene Spalte verwenden; das Feld FahrzeugID ist nur als
Kriterium vorgesehen und muss gar nicht angezeigt werden.
Damit das Listenfeld die erste Spalte mit dem Feld AusstattungID ausblendet, stellen
Sie die Eigenschaften Spaltenanzahl und Spaltenbreite auf die Werte 2 beziehungsweise
0cm ein.
Abbildung 3.57: Datensatzherkunft des Listenfeldes lstVorhandeneAusstattung (frm Fahr zeu ge)
Wenn Sie die Tabellen aus der Beispieldatenbank verwenden oder bereits selbst Beispiel
da ten eingegeben haben, können Sie nun ausprobieren, ob das Listenfeld die gewünschten
Daten anzeigt. Beim ersten angezeigten Fahrzeug sollte dies funktionieren,
beim Blät tern zum nächsten Fahrzeug verändert sich der Inhalt des Listenfeldes allerdings
nicht. Das liegt daran, dass seine Datensatzherkunft nicht aktualisiert wird.
Legen Sie also die folgende Prozedur an, die durch das Ereignis Beim Anzeigen des
Formulars ausgelöst wird:
Private Sub Form_Current()
End Sub
'Aktualisieren des linken Listenfeldes
Me!lstVorhandeneAusstattung.Requery
Listing 3.17: Diese Prozedur sorgt für die Aktualisierung des Listenfeldes beim Datensatz wechsel
227

Kapitel 3 Formulare
Legen Sie nun die Abfrage an, die als Datensatzherkunft für das zweite Listenfeld dient.
Das Listenfeld soll alle Ausstattungen anzeigen, die nicht zu einem Fahrzeug gehören
und die nicht über die Tabelle tblFahrzeugeAusstattungen mit der Tabelle tblFahrzeuge
verknüpft sind. Das sind alle Datensätze der Tabelle tblAusstattungen, die nicht im linken
Listenfeld angezeigt werden – also formulieren Sie die Abfrage auch einfach so. Diese
enthält zunächst lediglich die beiden Felder der Tabelle tblAusstattungen. Den Bezug zu
der Abfrage, die als Datensatzherkunft des linken Listenfeldes dient, erstellen Sie über
das Kriterium für das Feld AusstattungID: Dort schließen Sie über das Schlüsselwort
NOT IN alle Ausstattungen der Abfrage des linken Listenfeldes aus. Allerdings müssen
Sie die dortige Abfrage noch ein wenig bearbeiten, da die für IN-Bedingungen verwendeten
Unterabfragen nur ein Feld ausgeben dürfen. Den in Abbildung 3.58 nicht komplett
zu erkennenden Ausdruck für die Bedingung finden Sie hier:
228
Nicht In (SELECT tblAusstattungen.AusstattungID FROM tblAusstattungen
INNER JOIN tblFahrzeugeAusstattungen ON tblAusstattungen.AusstattungID = tblFahrzeuge-
Ausstattungen.AusstattungID WHERE tblFahrzeugeAusstattungen.FahrzeugID=[Forms]![frmFahr
zeuge]![FahrzeugID])
Abbildung 3.58: Datensatzherkunft des Listenfeldes der nicht vorhandenen Ausstattungs merkmale
(frmFahrzeuge)
Nun zeigen die beiden Listenfelder bereits die gewünschten Daten an (siehe
Abbildung 3.59). Als Nächstes bringen Sie ein wenig Leben in die Schaltflächen und
Lis ten fel der, um das Formular zum Hinzufügen und Entfernen von Datensätzen in der
Tabelle tbl FahrzeugeAusstattungen verwenden zu können.
Damit auch das rechte Listenfeld beim Datensatzwechsel aktualisiert wird, ergänzen
Sie die Ereignisprozedur Form_Current wie im folgenden Listing:
Private Sub Form_Current()
'Aktualisieren des linken Listenfeldes
Me!lstVorhandeneAusstattung.Requery
'Aktualisieren des rechten Listenfeldes

End Sub
Me!lstNichtVorhandeneAusstattung.Requery
Listing 3.18: Aktualisieren der Listenfelder
Abbildung verschiedener Beziehungsarten
Abbildung 3.59: Die Listenfelder zeigen bereits die richtigen Daten an (frmFahrzeuge)
Hinzufügen eines Ausstattungsmerkmals
Das Formular bietet zwei Möglichkeiten zum Hinzufügen eines einzelnen Aus stat tungsmerkmals
zu einem Fahrzeug: per Doppelklick auf den gewünschten Eintrag im Listen
feld lstNichtVorhanden oder durch Markieren des Eintrags im selben Listenfeld und
an schließendes Betätigen der Schaltfläche cmdHinzufuegen.
Da in beiden Varianten die gleiche Aktion ausgelöst werden soll, legen Sie diese in einer
separaten Prozedur an, die von der jeweiligen Ereignisprozedur der beiden Steuer elemen
te aus aufgerufen wird.
Für das Anlegen des neuen Datensatzes in der Tabelle tblFahrzeugeAusstattungen müssen
Sie die zukünftigen Werte der Felder FahrzeugID und AusstattungID kennen. Diese
er mitteln Sie in den beiden Ereignisprozeduren Beim Klicken der Schaltfläche cmdHinzufuegen
und Beim Doppelklicken des Listenfeldes lstNichtVorhanden und rufen von dort
aus die Prozedur Hinzufuegen auf. Sollte einer der beiden Werte nicht vorhanden sein,
was der Fall ist, wenn entweder kein hinzuzufügender Eintrag des Listenfeldes markiert
ist oder das Formular einen neu angelegten Fahrzeug-Datensatz enthält, wird die
Hinzufuegen-Prozedur nicht aufgerufen.
Private Sub cmdHinzufuegen_Click()
If Not IsNull(Me!FahrzeugID) And _
End If
End Sub
Not IsNull(Me!lstNichtVorhandeneAusstattung) Then
Hinzufuegen Me!FahrzeugID, Me!lstNichtVorhandeneAusstattung
229

Kapitel 3 Formulare
230
Private Sub lstNichtVorhandeneAusstattung_DblClick(Cancel As Integer)
If Not IsNull(Me!FahrzeugID) And _
End If
End Sub
Not IsNull(Me!lstNichtVorhandeneAusstattung) Then
Hinzufuegen Me!FahrzeugID, Me!lstNichtVorhandeneAusstattung
Listing 3.19: Aufrufen der Prozedur zum Anlegen eines neuen Datensatzes in der Tabelle tbl Fahrzeuge
Ausstattungen
Die Prozedur Hinzufuegen erwartet als Parameter die Fahrzeug-ID und die Ausstattungs-
ID des zu erstellenden Datensatzes. Nach der Durchführung der Aktionsabfrage aktualisiert
die Prozedur die beiden Listenfelder.
Private Sub Hinzufuegen(lngFahrzeugID As Long, _
End Sub
lngAusstattungID As Long)
Dim db As DAO.Database
Dim strSQL As String
Set db = CurrentDb
'Zusammen der Anfügeabfrage
strSQL = "INSERT INTO tblFahrzeugeAusstattungen" _
& "(FahrzeugID, AusstattungID) VALUES(" _
& lngFahrzeugID & ", " & lngAusstattungID & ")"
'Ausführen der Anfügeabfrage
db.Execute strSQL
'Aktualisieren der Listenfelder
Me!lstVorhandeneAusstattung.Requery
Me!lstNichtVorhandeneAusstattung.Requery
Set db = Nothing
Listing 3.20: Prozedur zum Hinzufügen eines Datensatzes zur Tabelle tbl Fahr zeuge Aus stat tun gen
Entfernen eines Ausstattungsmerkmals
Zum Entfernen eines Ausstattungsmerkmals eines Fahrzeugs gibt es ebenfalls zwei
Möglichkeiten. Entweder Sie markieren den zu entfernenden Datensatz und klicken auf
die Schaltfläche zum Entfernen eines Datensatzes oder Sie klicken doppelt auf den zu
entfernenden Eintrag im Listenfeld.
Der Aufbau der dadurch ausgelösten Prozeduren ist identisch mit dem der Prozeduren
zum Hinzufügen eines Ausstattungsmerkmals und die Prozedur Entfernen ist das
Pendant zur Prozedur Hinzufuegen. Lediglich die ver wen dete SQL-Anweisung hat ein
anderes Aussehen:

Abbildung verschiedener Beziehungsarten
Private Sub Entfernen(lngFahrzeugID As Long, lngAusstattungID As Long)
End Sub
Dim db As DAO.Database
Dim strSQL As String
Set db = CurrentDb
strSQL = "DELETE FROM tblFahrzeugeAusstattungen " _
& "WHERE FahrzeugID = " & lngFahrzeugID _
& " AND AusstattungID = " & lngAusstattungID
db.Execute strSQL
Me!lstVorhandeneAusstattung.Requery
Me!lstNichtVorhandeneAusstattung.Requery
Set db = Nothing
Listing 3.21: Prozedur zum Entfernen eines Ausstattungsmerkmals eines Fahrzeugs
Hinzufügen oder Entfernen aller Ausstattungsmerkmale
Die beiden Schaltflächen mit dem doppelten Kleiner- beziehungsweise Größer-Zeichen
bewegen jeweils alle Ausstattungen eines Fahrzeugs von einem Listenfeld ins andere.
Aus Datensicht bedeutet das, dass entweder für jedes Ausstattungsmerkmal in Kom bina
tion mit dem aktuell angezeigten Fahrzeug ein Datensatz in der Tabelle tblFahrzeuge­
Aus stattungen angelegt wird oder dass alle vorhandenen Einträge für ein Fahrzeug entfernt
werden. Das Hinzufügen aller Ausstattungsmerkmale erledigt die Prozedur, die
durch das Er eig nis Beim Klicken der Schaltfläche cmdAlleHinzufuegen ausgelöst wird.
Im Gegensatz zu den Prozeduren zum Hinzufügen eines einzelnen Datensatzes braucht
hier nicht ge prüft zu werden, ob ein Eintrag des Listenfeldes markiert ist:
Private Sub cmdAlleHinzufuegen_Click()
Dim db As DAO.Database
Dim strSQL As String
If Not IsNull(Me!FahrzeugID) Then
End If
End Sub
Set db = CurrentDb
strSQL = "INSERT INTO tblFahrzeugeAusstattungen " _
& "SELECT " & Me!FahrzeugID & " AS FahrzeugID, " _
& "AusstattungID FROM tblAusstattungen"
db.Execute strSQL
Me!lstVorhandeneAusstattung.Requery
Me!lstNichtVorhandeneAusstattung.Requery
Set db = Nothing
Listing 3.22: Hinzufügen aller vorhandenen Ausstattungsmerkmale zu einem Fahrzeug
231

Kapitel 3 Formulare
Das Entfernen aller Ausstattungen eines Fahrzeugs geschieht in der folgenden Prozedur.
Der wesentliche Unterschied zur vorherigen Prozedur liegt in der SQL-Anweisung:
232
Private Sub cmdAlleEntfernen_Click()
Dim db As DAO.Database
Dim strSQL As String
If Not IsNull(Me!FahrzeugID) Then
End If
End Sub
Set db = CurrentDb
strSQL = "DELETE FROM tblFahrzeugeAusstattungen " _
& "WHERE FahrzeugID = " & Me!FahrzeugID
db.Execute strSQL
Me!lstVorhandeneAusstattung.Requery
Me!lstNichtVorhandeneAusstattung.Requery
Set db = Nothing
Listing 3.23: Entfernen aller Ausstattungsmerkmale eines Fahrzeugs
3.5.12 Reflexive Beziehungen
Für die Darstellung der Daten aus reflexiven Beziehungen bietet sich das Treeview-
Steuerelement an. Mit ein wenig Fantasie lassen sich hierarchische Daten zwar auch in
Listenfeldern oder gar in Textfeldern anzeigen, aber ihre Anwendung macht nicht wirklich
Spaß. Daher finden Sie nachfolgend eine Anleitung zum Erstellen eines Formulars
mit einen Treeview-Steuerelement zur Darstellung der Hierarchie von Mitarbeitern und
ihren Vorgesetzten. Eine ausführliche Vorstellung der Funktionen und Möglichkeiten
des Treeview-Steuer ele ments finden Sie in »Steuerelemente« ab Seite 265.
Das Treeview-Steuerelement legen Sie über den Dialog ActiveX­Steuerelement einfügen
an, den Sie mit dem Ribbon-Eintrag Entwurf|Steuerelemente|ActiveX­Steuerelement
einfügen aufrufen (siehe Abbildung 3.60). Benennen Sie das neu hinzugefügte
Steuerelement ctl Tree view. Anschließend können Sie direkt den für das Füllen des
Treeview-Steuerelements be nötigten Code schreiben.
Füllen des Treeview-Steuerelements
Zum Speisen des Treeview-Steuerelements mit Daten aus einer Tabelle mit einer reflexiven
Beziehung benötigen Sie eine rekursive Prozedur. Das bedeutet, dass sich die Proze
dur immer wieder selbst aufruft, solange die Datensatzquelle tiefer verschachtelte
Ele mente enthält, und erst dann die folgenden Elemente der übergeordneten Ebenen
ab arbeitet. Den Start macht allerdings eine herkömmliche Routine. Sie legt eine modulweit
gültige Variable namens objTreeview mit einem Verweis auf das Steuerelement an.

Abbildung 3.60: Einfügen des Treeview-Steuerelements
Abbildung verschiedener Beziehungsarten
Anschließend durchläuft die Routine alle Datensätze eines Recordsets mit allen Mit arbeitern,
die keinen Vorgesetzten haben, und fügt je einen Knoten zum Treeview-Steuerele
ment hinzu. Dabei legt sie als Beschriftung den Nachnamen und den Vornamen des
ak tuellen Mitarbeiters an. Außerdem verwendet sie die Key-Eigenschaft des neuen
Ele ments, um den Wert des Feldes MitarbeiterID des aktuellen Datensatzes hinzuzufügen.
Da Werte der Eigenschaft Key mit einem Buchstaben beginnen müssen, stellt die
Routine ein x voran. Nach dem Anlegen des Knotens ruft sie die Routine zum Anlegen
der un tergeordneten Mitarbeiter auf – dazu weiter unten mehr. Im Anschluss daran
werden wei tere Datensätze – soweit vorhanden – auf die gleiche Art abgearbeitet.
Dim objTreeview As TreeView
Dim db As DAO.Database
Private Sub Form_Load()
Dim rst As DAO.Recordset
Dim objNode As Node
Dim objListItem As ListItem
Set objTreeview = Me!ctlTreeview.Object
objTreeview.Nodes.Clear
Set db = CurrentDb
Set rst = db.OpenRecordset( _
"SELECT * FROM tblMitarbeiterMitVorgesetzten " _
& "WHERE VorgesetzterID IS NULL", dbOpenDynaset)
Do While Not rst.EOF
Set objNode = objTreeview.Nodes.Add
With objNode
.Text = rst!Nachname & ", " & rst!Vorname
.Key = "x" & rst!MitarbeiterID
233

Kapitel 3 Formulare
234
Loop
End Sub
End With
AddChilds rst!MitarbeiterID
rst.MoveNext
Listing 3.24: Diese Routine fügt die Elemente der ersten Ebene in das Treeview-Steuerelement
ein
Die Routine AddChilds erwartet die MitarbeiterID des übergeordneten Mitarbeiters als
Parameter. Per OpenRecordset legt die Routine eine Datensatzgruppe an, die alle Mitar
beiter-Datensätze enthält, deren Vorgesetzter der Mitarbeiter mit der übergebenen
Mit ar beiterID ist. Anschließend wird für jeden »Untergebenen« ein Element unterhalb
des Vorgesetzten an gelegt.
Um das Element des Vorgesetzten zu ermitteln, setzt die Routine den Buch sta ben x
und die MitarbeiterID zu dem Wert zusammen, den die aufrufende Routine als Key für
den übergeordneten Mitarbeiter angelegt hat, und findet so das passende Ele ment. Für
jeden »Untergebenen« wird diese Routine rekursiv aufgerufen, um auch die »Un ter gebenen«
der »Untergebenen« zu finden und entsprechende Elemente anzulegen.
Private Sub AddChilds(lngMitarbeiterID As Long)
Dim rst As DAO.Recordset
Dim objNode As Node
Set rst = db.OpenRecordset( _
"SELECT * FROM tblMitarbeiterMitVorgesetzten " _
& "WHERE VorgesetzterID = " _
& lngMitarbeiterID, dbOpenDynaset)
Do While Not rst.EOF
Loop
End Sub
Set objNode = objTreeview.Nodes.Add(Relative:="x" _
& lngMitarbeiterID, Relationship:=tvwChild)
With objNode
.Text = rst!Nachname & ", " & rst!Vorname
.Key = "x" & rst!MitarbeiterID
End With
AddChilds rst!MitarbeiterID
rst.MoveNext
Listing 3.25: Rekursiver Teil der Prozeduren zum Füllen des Treeview-Steuerelements
Auf diese Weise werden alle Datensätze durchlaufen und dem Treeview-Steuerelement
hinzugefügt.

Anzeigen des Detailformulars zu einem Element
Von Formular zu Formular
Natürlich sollen Sie auch etwas mit dem gefüllten Treeview anfangen können. Daher finden
Sie nachfolgend eine kleine Routine, die nach einem Klick auf eine dafür vorgesehene
Schaltfläche ein Detailformular mit den Daten des aktuell im Treeview-Steuerelement
markierten Eintrags anzeigt:
Private Sub cmdDetails_Click()
End Sub
Dim lngMitarbeiterID As Long
lngMitarbeiterID = CLng(Mid(objTreeview.SelectedItem.Key, 2))
DoCmd.OpenForm "frmMitarbeiterDetail", _
WhereCondition:="MitarbeiterID = " & lngMitarbeiterID
Listing 3.26: Code zum Öffnen eines Detailformulars zum aktuellen Element des Treeview-
Steuerelements
Das gefüllte Treeview-Steuerelement mit Detailformular für einen der Einträge sieht wie
in Abbildung 3.61 aus.
Abbildung 3.61: Treeview-Steuerelement mit Detailformular (frmMitarbeiterMitVorgesetzten, frm­
Mit arbeiterDetail)
3.6 Von Formular zu Formular
Weiter oben haben Sie bereits einige Möglichkeiten kennen gelernt, mit denen Sie
von einem Formular aus ein weiteres Formular aufrufen und diesem bestimmte
Informationen übergeben können. Bei der Anwendung dieser Möglichkeiten sind einige
Voraussetzungen zu beachten, damit Sie länger Spaß an den auf diese Weise »verknüpften«
Formularen haben.
235

Kapitel 3 Formulare
Die wichtigste Regel ist: Sorgen Sie für möglichst wenig Abhängigkeiten zwischen aufrufendem
und aufgerufenem Formular. Das bedeutet in diesem Fall, dass Sie die Abhängigkeit
erstens unidirektional auslegen und zweitens an bestimmten Punkten konzentrieren
sollten – etwa auf das Öffnen und das Schließen des aufgerufenen For mu lars.
Zur besseren Verständlichkeit heißt das aufrufende Formular in den nächsten Ab schnitten
»Parent« und das aufgerufene Formular »Child«. Unidirektionale Abhängigkeit bedeutet,
dass zwar das Parent-Formular das Child-Formular kennen muss, aber nicht
umgekehrt. In der Praxis sieht das folgendermaßen aus:
» Das Parent-Formular kennt den Namen des Child-Formulars und ruft dieses darüber
auf.
» Das Parent-Formular kennt die Datensatzquelle des Child-Formulars und weiß, wie
eine Bedingung zur Einschränkung der Datensatzquelle aussehen muss.
» Das Parent-Formular weiß, welche Werte es dem Child-Formular mit dem Öffnungsargument
übergeben kann.
Umgekehrt weiß das Child-Formular nichts vom Parent-Formular – es wertet lediglich
die vom Parent-Formular übergebenen Informationen aus, ist aber nicht von der Lie ferung
dieser Informationen abhängig.
Andersherum soll das Parent-Formular neben den beim Aufruf übergebenen In forma
tio nen nach dem Schließen des Child-Formulars Werte von dort auslesen können.
Daher darf das Child-Formular nicht geschlossen, sondern nur unsichtbar gemacht
wer den.
Außer diesen zwei Kontakten – Parameterübergabe beim Aufruf und Auslesen des
Child-Formulars vor dem Schließen – finden im Optimalfall keine Kontakte statt. Das
heißt insbesondere, dass das Child-Formular nicht auf das Parent-Formular zugreift.
Es gibt natürlich die Möglichkeit, Variablen, die zwischen Parent- und Child-Formular
hin- und hergereicht werden sollen, in globalen Variablen zu speichern; man könnte
auch vom Child-Formular aus lesend und schreibend auf das Parent-Formular zugreifen.
Ersteres bedingt, dass beide Formulare die globalen Variablen kennen müssen, und
Letz teres, dass das Parent-Formular das Child-Formular kennen muss und umgekehrt
und diese damit voneinander abhängig sind.
Seit Access 2007 gibt es mit den TempVars noch eine weitere Möglichkeit. Nähere
Informationen dazu finden Sie unter »TempVars« ab Seite 450.
Formulare aufrufen und vor dem Schließen auslesen
VBA-technisch sieht das wie folgt aus. Der Aufruf des Child-Formulars erfolgt mit der
DoCmd.OpenForm-Methode. Damit das Parent-Formular das Child-Formular nach dem
236

Von Formular zu Formular
Aus blenden und vor dem Schließen auslesen kann, muss das Child-Formular als modaler
Dialog geöffnet werden. Das bedeutet, dass keine anderen Aktionen in der Access-
An wendung möglich sind, solange das Child-Formular geöffnet ist. Auf diese Weise verhindern
Sie Wechsel wir kungen zwischen Child-Formular und anderen Elementen der
Benutzeroberfläche. Um ein Formular mit der OpenForm-Methode als modalen Dialog
zu öffnen, verwendet man den Parameter WindowMode mit dem Wert acDialog:
DoCmd.OpenForm "frmChild", WindowMode:=acDialog
Wichtigster Nebeneffekt des Öffnens als modaler Dialog ist, dass auch die aufrufende
Prozedur angehalten wird. Diese läuft erst dann weiter, wenn das Child-Formular durch
Setzen der Eigenschaft Visible auf den Wert True oder durch Schließen den Fokus verliert.
Die aufrufende Routine weiß dann bei der nächsten Zeile zumindest sicher, dass
das Child-Formular entweder geschlossen oder ausgeblendet ist. Erstrebenswert ist
natürlich Letzteres, denn sonst könnten Sie von dort keine Informationen mehr erlangen.
Also sorgen Sie dafür, dass das Formular nicht auf herkömmlichem Wege geschlossen,
sondern nur über eine spezielle Schaltfläche ausgeblendet werden kann. Die passende
Er eignisprozedur der Schaltfläche mit dem Namen cmdOK sieht dann folgendermaßen
aus:
Private Sub cmdOK_Click()
End Sub
Me.Visible = True
Listing 3.27: Ausblenden eines Formulars
In der aufrufenden Prozedur sollten Sie auf jeden Fall prüfen, ob das Formular noch
geöffnet ist. Dazu können Sie die Eigenschaft IsLoaded des entsprechenden Elements
der AllForms-Auflistung verwenden:
If CurrentProject.AllForms("").IsLoaded = True Then
Aber auch das verschafft noch keine Sicherheit, denn das Formular könnte ja auch in der
Entwurfsansicht geöffnet sein. Also folgt eine weitere Prüfung:
…
If CurrentProject.AllForms("").CurrentView = _
acCurViewFormBrowse Then
Anschließend kann das Child-Formular in Ruhe ausgelesen werden, bevor es geschlossen
wird.
Beispiel für das Aufrufen eines weiteren Formulars
Wenn Sie ein Kombinationsfeld etwa für die Auswahl der Kategorie eines Artikels verwenden,
sollten Sie die Möglichkeit bieten, leicht weitere Kategorien anzulegen. Im
237

Kapitel 3 Formulare
fol genden Beispiel wird bei der Eingabe eines Eintrags, der in der Datensatzherkunft
eines Kombinationsfeldes noch nicht vorhanden ist (siehe Abbildung 3.62), ein weiteres
Formular zum Anlegen eines neuen Datensatzes in der Kategorien-Tabelle angezeigt
(siehe Abbildung 3.63).
Abbildung 3.62: Anlegen einer neuen Kategorie (frmArtikel) …
Abbildung 3.63: … in einem eigenen Formular (frmKategorien)
Ob der Benutzer einen noch nicht in der Datensatzherkunft eines Kombinationsfeldes
vorhandenen Datensatz eingefügt hat, stellen Sie daran fest, dass das Ereignis Bei nicht
in Liste ausgelöst wird. Dieses Ereignis machen Sie sich zu Nutze und fragen darin den
Benutzer, ob er den neuen Eintrag tatsächlich anlegen möchte – vielleicht hat er sich ja
auch nur vertippt.
Anderenfalls öffnet die Routine das Formular frmKategorien (siehe Abbildung 3.63) mit
einem neuen Datensatz, der automatisch mit der neuen Kategorie gefüllt wird – dazu
später mehr.
Nach der Eingabe und dem Ausblenden des Formulars prüft die Routine, ob das
Formular noch in der Formularansicht geöffnet ist, und liest gegebenenfalls die
KategorieID des neuen Eintrags ein. Nach dem Schließen des aufgerufenen Formulars,
das zu diesem Zeitpunkt nur ausgeblendet, aber nicht geschlossen ist, stellt die Routine
das Kombinationsfeld auf den neuen Wert ein.
238
Private Sub KategorieID_NotInList(NewData As String, Response As Integer)
Dim lngKategorieID As Long
If MsgBox("Möchten Sie diese Kategorie anlegen?", _

End If
End Sub
vbYesNo + vbExclamation, "Neue Kategorie") = vbYes Then
DoCmd.OpenForm "frmKategorien", DataMode:=acFormAdd, _
OpenArgs:=NewData, WindowMode:=acDialog
Besonderheiten von Unterformularen
If CurrentProject.AllForms("frmKategorien").IsLoaded = True Then
End If
If CurrentProject.AllForms("frmKategorien").CurrentView = _
End If
acCurViewFormBrowse Then
lngKategorieID = Forms!frmKategorien!KategorieID
DoCmd.Close acForm, "frmKategorien"
Me!KategorieID = lngKategorieID
Me!KategorieID.Requery
Response = acDataErrContinue
Listing 3.28: Aufrufen eines weiteren Formulars zum Eingeben verknüpfter Daten
3.7 Besonderheiten von Unterformularen
Unterformulare können auf verschiedene Arten eingesetzt werden. Meist gibt es hier
und da Probleme – etwa, wenn Daten im Unterformular eingegeben werden, ohne
dass ein Datensatz im Hauptformular existiert, oder wenn Änderungen rückgängig
gemacht werden sollen, obwohl diese Änderungen im Unterformular bereits gespeichert
sind.
3.7.1 Eingabe von Daten ohne Detaildatensatz
In Abschnitt 4.5.10 haben Sie ein Formular mit Unterformular zur Eingabe von Pro jekten
und Projektzeiten kennen gelernt. Wenn Sie dort im Hauptformular auf einen neuen
Datensatz springen und im Unterformular Daten anlegen, bekommen Sie folgendes
Problem: Die Datensätze im Unterformular sind dann nicht mit einem Datensatz im
Hauptformular verknüpft und verschwinden in die ewigen Jagdgründe – zumindest aus
Sicht dieses Formulars, denn es zeigt im Unterformular nur Datensätze an, die mit dem
im Hauptformular befindlichen Datensatz verknüpft sind (siehe Abbildung 3.64).
Das ist zumindest das Standardverhalten: Seit Access 2007 können Sie mit der Eigen
schaft Leeren Hauptentwurf filtern (VBA: FilterOnEmptyMaster) des Unterformular-
Steuer ele ments festlegen, ob im Falle eines leeren Datensatzes im Hauptformular
alle Da ten sätze der Datensatzquelle des Unterformulars oder keiner angezeigt werden
soll.
239

Kapitel 3 Formulare
Abbildung 3.64: Eingabe von Daten in ein Unterformular ohne verknüpften Datensatz im Hauptformular
(frmProjektzeiten)
Um diese Probleme zu vermeiden, sollten Sie verhindern, dass der Benutzer mit der
Be ar beitung von Daten im Unterformular beginnt, bevor er nicht mindestens ein Feld
im Hauptdatensatz ausgefüllt hat. Dazu legen Sie für die Ereigniseigenschaft Beim
Hingehen die folgende Prozedur an:
240
Private Sub sfmProjektzeiten_Enter()
If Me.NewRecord Then
End If
End Sub
If Not Me.Dirty Then
End If
MsgBox "Bitte legen Sie zuerst einen Projektnamen an."
Me!Projekt.SetFocus
Listing 3.29: Kein Datensatz im Unterformular ohne Pendant im Hauptformular
Die Prozedur prüft, ob das Hauptformular einen neuen Datensatz enthält und ob dieser
gegebenenfalls bereits bearbeitet wurde – womit der benötigte Primärschlüsselwert
vorhanden wäre. Falls nicht, fordert die Routine den Benutzer auf, zunächst ein Projekt
im Hauptformular anzulegen.
3.7.2 Undo in Haupt- und Unterformular
Viele Formulare zeigen nicht nur selbst Daten an, sondern enthalten auch noch ein Unter
formular zur Bearbeitung von Daten aus verknüpften Tabellen. Wie in gebundenen
For mularen üblich, gilt auch hier: Wechselt man den Datensatz, wird er auch in der
zu grunde liegenden Tabelle gespeichert. Bis dahin lassen sich Änderungen am aktuell
bearbeiteten Datensatz noch relativ leicht durch Auslösen des Undo-Ereignisses rückgängig
machen, etwa durch Betätigen der Esc-Taste.

Besonderheiten von Unterformularen
Viele Formulare enthalten eine Implementierung einer Undo-Funktion in Form einer
Abbrechen-Schaltfläche. Den unbedarften Benutzer täuscht man freilich damit, denn
diese Schaltfläche macht lediglich die Änderungen an dem im Hauptformular angezeigten
Datensatz rückgängig. Die Änderungen im Unterformular sind und bleiben gespeichert.
Abbildung 3.65 zeigt, wie solch ein Formular aussieht. Es handelt sich um das bereits
weiter oben hergeleitete Formular mit zunächst zwei (sichtbaren) Erweiterungen: einer
OK­ und einer Abbrechen-Schaltfläche.
Abbildung 3.65: Formular mit Unterformular und Abbrechen-Funktion (frmProjekt zeiten_Un do)
Der Code, der durch das Beim Klicken-Ereignis der jeweiligen Schaltfläche ausgelöst
wird, sieht etwa wie folgt aus:
Private Sub cmdOK_Click()
End Sub
'Formular schließen
DoCmd.Close acForm, Me.Name
Private Sub cmdAbbrechen_Click()
'Prüfen, ob Datensatz seit letzter Speicherung geändert wurde
If Me.Dirty = True Then
End If
End Sub
'Falls ja, Änderungen rückgängig machen
Me.Undo
'Formular schließen
DoCmd.Close acForm, Me.Name
Listing 3.30: Ereignisprozeduren der OK- und der Abbrechen-Schaltfläche
241

Kapitel 3 Formulare
Eine Änderung im Unterformular wird auf jeden Fall gespeichert, da das Verlassen des
Unterformulars das Speichern des aktuellen Datensatzes zur Folge hat.
Wenn Sie nun einmal eine Korrektur an den Projektzeiten eines Projekts vornehmen
und dabei aus Versehen einige Datensätze löschen, weil Sie sich in einem anderen
Projekt wähnten, gibt es keine Undo-Funktion: Solche Änderungen führen Sie ohne Netz
und doppelten Boden aus.
In den folgenden Abschnitten erfahren Sie, wie Sie den Benutzern Ihrer Datenbank
(und vielleicht auch sich selbst) das Leben in dieser Hinsicht erleichtern können. Dabei
machen Sie Gebrauch von einer Transaktion, die bei der ersten Änderung an einem
Datensatz des Hauptformulars oder der verknüpften Datensätze im Unterformular gestartet
und mit Speichern des Datensatzes im Hauptformular (etwa durch Betätigen der
OK-Schaltfläche oder den Wechsel zu einem anderen Datensatz) beendet wird – was
zum endgültigen Speichern der Änderungen im Haupt- und Unterformular führt. Auch
die Abbrechen-Schaltfläche kann die Transaktion beenden – allerdings sollen dabei alle
seit Beginn der Transaktion durchgeführten Änderungen verworfen werden.
Normalerweise ist eine Transaktion ein gängiges Mittel, um mehrere Da ten bank operatio
nen zu bündeln und je nach Verlauf der Operationen komplett durchzuführen oder zu
ver werfen. Das kann doch bei den Aktionen innerhalb eines Formulars nicht viel anders
sein: Also startet man die Transaktion einfach beim Öffnen des Formulars und beendet
sie mit Betätigen der OK­ oder der Abbrechen-Schaltfläche. Oder doch nicht? Nein, ganz
so einfach ist es nicht. Access führt nämlich die in Zusammenhang mit gebundenen Formu
laren anfallenden Datenbankzugriffe nicht im Kontext des aktuellen Workspace aus.
Wenn Sie also einen Datensatz ändern und speichern, bekommt die Transaktion davon
überhaupt nichts mit.
Abhilfe schafft überhaupt erst die mit Access 2000 eingeführte Recordset-Eigenschaft
von Formularen. Damit lässt sich ein Formular an ein zuvor erstelltes Recordset-
Objekt binden, das wiederum sehr wohl unter die Kontrolle einer Transaktion fallen
kann. Es sind also folgende Maßnahmen für die Verwendung einer Transaktion zur
Zu sam men fassung von Datenbankoperationen in einem Formular mit Unterformular
notwendig:
» Binden des Haupt- und des Unterformulars an Recordset-Objekte
» Starten der Transaktion beim Ändern des Datensatzes im Hauptformular oder in
einem der verknüpften Datensätze im Unterformular
» Durchführen der Transaktion beim Klick auf die OK-Schaltfläche oder beim Wechseln
des Datensatzes im Hauptformular
» Verwerfen der Operationen der Transaktion beim Betätigen der Abbrechen-Schaltfläche
242

Besonderheiten von Unterformularen
Die letzten beiden Punkte setzen voraus, dass die entsprechenden Prozeduren Infor
ma tionen über den aktuellen Status haben – ist bereits eine Transaktion gestartet
wor den und wurde diese bereits beendet? Diese Information muss vom Haupt- und
vom Unterformular aus schreib- und lesbar sein, da Datenbankoperationen in beiden
Formularen eine Transaktion in Gang setzen können.
Das ist deshalb wichtig, weil das Beenden einer Transaktion, die noch nicht gestartet
wurde, zu einem Fehler führt. Genauso wichtig ist es, keine zweite Transaktion zu starten,
wenn bereits eine Trans ak tion gestartet wurde. Dies würde als »verschachtelte«
Transaktion gewertet werden; die Be tätigung der OK­ oder Abbrechen-Schaltfläche würde
möglicherweise nur die innere von mehreren verschachtelten Transaktionen beenden
und zu einem unvorhersehbaren Er gebnis führen.
Öffentliche Variablen für den Transaktionsstatus
Es gibt mehrere Möglichkeiten, den Status bezüglich der Transaktion zu speichern und
in Haupt- und Unterformular zugänglich zu machen. Globale Variablen verwendet man
besser nicht, da diese allzu leicht von einer anderen Stelle aus geändert werden können.
Besser ist die Verwendung von Membervariablen in einem der beiden Formulare und
ihre Veröffentlichung über entsprechende Property-Prozeduren.
Der folgende Quellcode zeigt, wie der Kopf des Klassenmoduls des Hauptformulars
aussieht:
Option Compare Database
Option Explicit
Dim mDirtyForm As Boolean
Dim mDeletedForm As Boolean
Dim db As DAO.Database
Dim wrk As DAO.Workspace
Public Property Get DirtyForm() As Boolean
DirtyForm = mDirtyForm
End Property
Public Property Let DirtyForm(bolDirtyForm As Boolean)
mDirtyForm = bolDirtyForm
End Property
Listing 3.31: Kopf des Klassenmoduls des Formulars frmProjektzeiten_Undo
Die Eigenschaft mDirtyForm machen Sie durch die nachfolgenden Property-Prozeduren
von außerhalb schreib- und lesbar. Auf diese Weise können Sie auf die wichtigen In for-
243

Kapitel 3 Formulare
ma tionen über den Zustand der Transaktion vom Haupt- und auch vom Un ter for mu lar
aus zugreifen.
Die Verwendung von Property Get- und Property Let-Pro ze duren ist ein kleiner Vorgriff
auf das Kapitel »Objektorientierte Programmierung« ab Seite 845.
Recordset-Objekt als Datensatzquelle
Weiter oben wurde bereits erwähnt, dass Transaktionen von den Vorgängen im For mu lar
und im Unterformular nur etwas mitbekommen, wenn die Datensatzquelle ein Re cordset-Objekt
ist.
Für das Hauptformular weisen Sie diese Eigenschaft am besten direkt beim Öffnen zu.
Die Prozedur, die durch die Ereigniseigenschaft Beim Öffnen ausgelöst wird, hat folgendes
Aussehen:
244
Private Sub Form_Open(Cancel As Integer)
End Sub
'Recordset-, Database- und Workspace-Objekt deklarieren
Dim rst As DAO.Recordset
Set db = DBEngine(0)(0)
Set wrk = DBEngine.Workspaces(0)
'Recordset-Objekt öffnen...
Set rst = db.OpenRecordset("tblProjekte", dbOpenDynaset)
'...und der entsprechenden Eigenschaft des Formulars zuweisen
Set Me.Recordset = rst
Listing 3.32: Ereignisprozedur Form_Open des Hauptformulars frmProjektzeiten_Undo
Da Sie dem Formular nun dynamisch die Datensatzquelle zuweisen, können Sie die
Eigenschaft Datensatzquelle leeren. Wichtig ist, dass die Felder weiterhin an die entsprechenden
Felder der Datensatzquelle gebunden sind. Anderenfalls können diese natürlich
nicht die gewünschten Daten anzeigen.
Neben dem Zuweisen der Datensatzquelle per Recordset-Eigenschaft ist die Deklaration
des Workspace-Objekts wrk die zweite Besonderheit in dieser Prozedur. Ein benutzerdefiniertes
Workspace-Objekt können Sie anschaulich als Arbeitsbereich betrachten, in
dem die aktuelle Anwendung temporär abläuft.
Kein neues Formular-Recordset während einer Transaktion
Wenn eine Transaktion einmal gestartet ist, können Sie dem Formular kein neues
Recordset-Objekt zuweisen. Diese Regel bedeutet kein besonderes Problem, da
Formular und Unterformular durchaus vor der ersten Änderung der Daten und damit
dem Starten der Transaktion mit den benötigten Recordsets versehen werden können.

Besonderheiten von Unterformularen
Es ergibt sich nur eine Einschränkung: Sie können während einer Transaktion nicht den
Datensatz im Hauptformular wechseln. Warum nicht? Weil bei der Anzeige eines neuen
Datensatzes im Hauptformular auch die im Unterformular angezeigten Daten aktualisiert
werden müssen. Und das geht wiederum nur durch das Zuweisen eines neuen Recordsets,
das die mit dem Datensatz im Hauptformular korrespondierenden Daten enthält.
Das ist aber nicht schlimm, denn dass beim Wechseln des Datensatzes die Daten des
vor herigen Datensatzes gespeichert werden, sollte dem Benutzer klar sein. Die technische
Umsetzung indes ist nicht ganz einfach.
Fest steht nur, dass beim Wechsel des Datensatzes, der das Ereignis Beim Anzeigen des
Hauptformulars auslöst, dem Un ter for mu lar ein neues Recordset zugewiesen werden
muss. Um den Rest kümmern Sie sich später. Die Prozedur Form_Current sieht nun
folgendermaßen aus:
Private Sub Form_Current()
End Sub
Dim strSQL As String
Dim rst As DAO.Recordset
'Zusammenstellen des SQL-Strings für das Recordset
strSQL = "SELECT tblProjektzeiten.ProjektID, " _
& "tblProjektzeiten.ProjektzeitID, " _
& "tblProjektzeiten.MitarbeiterID, " _
& "tblProjektzeiten.Datum, " _
& "tblProjektzeiten.Zeit, " _
& "tblMitarbeiter.Telefon " _
& "FROM tblProjektzeiten INNER JOIN tblMitarbeiter " _
& "ON tblProjektzeiten.MitarbeiterID = " _
& " tblMitarbeiter.MitarbeiterID " _
& "WHERE ProjektID = " & Nz(Me!ProjektID, 0)
'Öffnen des Recordset
Set rst = db.OpenRecordset(strSQL, dbOpenDynaset)
'Zuweisen des Recordset an das Unterformular
Set Me!sfmProjektzeiten_Undo.Form.Recordset = rst
Listing 3.33: Quellcode der Prozedur Form_Current des Hauptformulars
Alternativ können Sie auch die gespeicherte Abfrage qryProjektzeitenMitarbeiter verwenden
(siehe Abbildung 3.50). Die Prozedur sähe dann folgendermaßen aus:
Private Sub Form_Current()
Dim rst As DAO.Recordset
'Öffnen des Recordset
Set rst = db.OpenRecordset("SELECT * FROM " _
245

Kapitel 3 Formulare
246
End Sub
& "qryProjektzeitenMitarbeiter WHERE ProjektID = " _
& Nz(Me!ProjektID, 0), dbOpenDynaset)
'Zuweisen des Recordset an das Unterformular
Set Me!sfmProjektzeiten_Undo.Form.Recordset = rst
Listing 3.34: Vereinfachte und performantere Version der Prozedur Form_Current
Dadurch, dass die im Unterformular angezeigten Datensätze ohnehin nach dem im
Hauptformular angezeigten Projekt gefiltert werden, sind die beiden Eigenschaften
Verknüpfen von und Verknüpfen nach im Unterformularsteuerelement nicht mehr
notwen dig. Leeren Sie also diese beiden Eigenschaften.
Dadurch müssen Sie beim Anlegen neuer Datensätze im Unterformular dafür sorgen,
dass diese Datensätze irgendwie mit der ProjektID des Datensatzes im Hauptformular
versehen werden. Dazu jedoch später mehr.
Sie kommen trotzdem nicht umhin, dafür zu sorgen, dass keine Datensätze im Un ter formu
lar angelegt werden, ohne dass sich ein Datensatz im Hauptformular befindet. Dazu
kön nen Sie die Routine aus Listing 3.29 verwenden.
Transaktionen in Formularen
Nun geht es an das eigentliche Problem: Das Einfassen von Änderungen im Haupt- und
Un terformular in eine Transaktion, um getätigte Änderungen für Haupt- und Unter formu
lar komplett revidieren zu können.
Dazu veranschaulichen Sie sich zunächst, welche Datensatzänderungen überhaupt berücksichtigt
werden müssen, und leiten davon ab, in welchen Ereignisprozeduren die
Transaktion gestartet, durchgeführt oder abgebrochen wird.
» Hinzufügen eines Datensatzes im Hauptformular: löst Form_Dirty im Hauptformular
aus.
» Ändern eines Datensatzes im Hauptformular: löst Form_Dirty im Hauptformular aus.
» Löschen eines Datensatzes im Hauptformular: kann nicht rückgängig gemacht werden,
da das Formular unmittelbar nach dem Löschen auf einen anderen Datensatz
springt.
» Hinzufügen eines Datensatzes im Unterformular: löst Form_Dirty im Unterformular
aus.
» Ändern eines Datensatzes im Unterformular: löst Form_Dirty im Unterformular aus.
» Löschen eines Datensatzes im Unterformular: löst Form_Delete im Unterformular
aus.

Besonderheiten von Unterformularen
Damit stehen bereits die Ereignisse fest, die eine Transaktion starten sollen. Schauen
Sie sich die dadurch ausgelösten Prozeduren an. Den Anfang macht die Prozedur Form_
Dirty des Hauptformulars:
Private Sub Form_Dirty(Cancel As Integer)
'Wenn aktueller Datensatz noch nicht geändert...
If Me.DirtyForm = False Then
End If
End Sub
'Eigenschaft DirtyForm auf True setzen
Me.DirtyForm = True
'Transaktion starten
wrk.BeginTrans
Listing 3.35: Start einer Transaktion beim Ändern oder Hinzufügen eines Datensatzes im Hauptformular
Im Unterformular muss die Prozedur Form_Dirty noch ein wenig mehr leisten. Sie sorgt
nicht nur dafür, dass im Falle der ersten Änderung die Transaktion gestartet und die
Eigenschaft DirtyForm des Hauptformulars auf True gesetzt wird.
Zusätzlich prüft sie, ob es sich bei der Änderung um einen neuen Datensatz handelt.
Wie weiter oben erwähnt, sind Haupt- und Unterformular nicht über die entsprechenden
Werte für die Eigenschaften Verknüpfen von und Verknüpfen nach miteinander verknüpft.
Der Wert des Verknüpfungsfeldes ProjektID wird nicht automatisch gefüllt. Die Prozedur
übernimmt daher auch diese Aufgabe und weist dem Feld ProjektID des Unterformulars
den entsprechenden Wert des Hauptformulars zu.
Damit im Unterformular überhaupt eine Transaktion gestartet werden kann, sind noch
einige Zeilen Code notwendig. So befindet sich im Modulkopf neben den obligatorischen
Zeilen noch die Deklaration des Workspace-Objekts für das Unterformular:
Option Compare Database
Option Explicit
Dim wrk As DAO.Workspace
Dieses stellt das Form_Open-Ereignis des Unterformulars auf den gleichen Workspace
wie im Hauptformular ein:
Private Sub Form_Open(Cancel As Integer)
End Sub
Set wrk = DBEngine.Workspaces(0)
Listing 3.36: Zuweisen des Workspace-Objekts
247

Kapitel 3 Formulare
Die Prozedur Form_Dirty ist eine von zwei Prozeduren, die vom Unterformular aus eine
Transaktion starten können:
248
Private Sub Form_Dirty(Cancel As Integer)
'Wenn es sich um einen neuen Datensatz handelt,
'Wert für die Herstellung der Verknüpfung über das
'Feld ProjektID zuweisen
If Me.NewRecord Then
End If
Me!ProjektID = Me.Parent!ProjektID
'Wenn noch keine Änderung im Haupt- oder Unterformular
'vorliegt, DirtyForm auf True setzen und Transaktion starten
If Me.Parent.DirtyForm = False Then
End If
End Sub
Me.Parent.DirtyForm = True
wrk.BeginTrans
Listing 3.37: Form_Dirty-Prozedur des Unterformulars sfmProjektzeiten_Undo
Die Prozedur, die durch die Beim Löschen-Eigenschaft des Unterformulars ausgelöst
wird, muss sich nicht um die ProjektID scheren. Sie startet lediglich die Transaktion,
falls dies noch nicht geschehen ist:
Private Sub Form_Delete(Cancel As Integer)
'Wenn noch keine Änderung im Haupt- oder Unterformular...
If Me.Parent.DirtyForm = False Then
End If
End Sub
Me.Parent.DirtyForm = True
wrk.BeginTrans
Listing 3.38: Die Prozedur Form_Delete startet gegebenenfalls eine Transaktion
Abbrechen der Transaktion
Das Abbrechen der Transaktion erreichen Sie durch Betätigen der Abbrechen-
Schaltfläche. Die dadurch ausgelöste Prozedur prüft, ob Änderungen im Haupt- oder
Unterformular durchgeführt wurden und damit eine Transaktion gestartet wurde.
Falls ja, werden die Änderungen durch die Rollback-Methode des Workspace-Objekts
wieder verworfen.
Private Sub cmdAbbrechen_Click()
'Prüfen, ob Daten geändert wurden

If Me.DirtyForm = True Then
End If
End Sub
'Transaktion abbrechen
wrk.Rollback
'Formular schließen
DoCmd.Close acForm, Me.Name
Besonderheiten von Unterformularen
Listing 3.39: Die Abbrechen-Schaltfläche verwirft alle Änderungen der aktuellen Daten des
Haupt- und Unterformulars
Durchführen der Transaktion
Die Durchführung der Transaktion erfolgt durch Speichern des Datensatzes im Hauptformular.
Dazu gibt es zum Beispiel folgende Möglichkeiten:
» Schließen des Formulars mit der OK-Schaltfläche
» Wechseln zu einem anderen Datensatz im Hauptformular
» Schließen des Formulars auf anderem Wege (beispielsweise Betätigen des Schließen-
Buttons oben rechts im Formular)
In diesem Beispiel werden nur die beiden ersten Möglichkeiten zum Speichern eines
Datensatzes beschrieben. Zum Schließen des Formulars mit der OK-Schaltfläche ist die
Prozedur verantwortlich, die durch das Ereignis Beim Klicken der Schaltfläche ausgelöst
wird. Die Prozedur prüft anhand der Eigenschaft DirtyForm, ob überhaupt Änderungen
im Haupt- oder Unterformular durchgeführt wurden und dementsprechend eine
Transaktion gestartet wurde.
Falls ja, schließt sie die Transaktion mit der Methode CommitTrans ab.
Private Sub cmdOK_Click()
'Speichern der Änderungen
DoCmd.RunCommand acCmdSaveRecord
'Wenn Änderungen vorliegen und damit eine
'Transaktion gestartet wurde:
If Me.DirtyForm = True Then
End If
End Sub
'Transaktion durchführen
wrk.CommitTrans
'Formular schließen
DoCmd.Close acForm, Me.Name
Listing 3.40: Das Schließen des Formulars mit der OK-Schaltfläche führt die Transaktion durch
249

Kapitel 3 Formulare
Der Wechsel zu einem anderen Datensatz im Formular löst das Ereignis Beim Anzeigen
aus. Die erste Version dieser Prozedur (siehe Listing 3.33) sieht noch keine Funktion
zum Abschließen einer Transaktion vor.
Die folgende Variante holt dies nach:
250
Private Sub Form_Current()
'Wenn Daten geändert und Transaktion gestartet...
If Me.DirtyForm = True Then
End If
'aktuellen Datensatz speichern
DoCmd.RunCommand acCmdSaveRecord
'Transaktion durchführen
wrk.CommitTrans
'Formular als "gespeichert" kennzeichnen
Me.DirtyForm = False
If mDeletedForm = False Then
Else
End If
End Sub
'Prozedur zum Aktualisieren des Unterformulars aufrufen
UnterformularAktualisieren
mDeletedForm = False
Listing 3.41: Abschließen der Transaktion beim Datensatzwechsel im Hauptformular
Die eigentliche Funktionalität zum Aktualisieren der Datensatzquelle des Unter for mulars
wird dabei in eine eigene Prozedur ausgegliedert, weil diese noch von einer weiteren
Ereignisprozedur aufgerufen werden soll. Die ausgegliederte Prozedur sieht wie
folgt aus:
Private Sub UnterformularAktualisieren()
End Sub
Dim strSQL As String
Dim rst As DAO.Recordset
'Zusammenstellen des SQL-Strings
strSQL = "SELECT * FROM qryProjektzeitenMitarbeiter " _
& "WHERE ProjektID = " & Nz(Me!ProjektID, 0)
'Öffnen des Recordset
Set rst = db.OpenRecordset(strSQL, dbOpenDynaset)
'Zuweisen des Recordset an das Unterformular
Set Me!sfmProjektzeiten_Undo.Form.Recordset = rst
Listing 3.42: Prozedur zum Aktualisieren des Unterformulars

Löschen des aktuellen Datensatzes im Hauptformular
Besonderheiten von Unterformularen
Bleibt noch ein Problem: Wenn Sie den aktuell im Hauptformular angezeigten Datensatz
löschen möchten, erscheint der Fehler aus Abbildung 3.66. Das Merkwürdige ist, dass
beim Löschen gar keine Transaktion per VBA gestartet wurde – woher kommt nun diese
Transaktion? Offensichtlich schließt Access den Löschvorgang automatisch in eine
Transaktion ein. Normalerweise würden Sie davon gar nichts mitbekommen, da innerhalb
dieser Transaktion keine unerlaubten Aktionen erfolgen wie das hier bemängelte
Zuweisen eines Recordset-Objekts an die entsprechende Eigenschaft.
Hier liegt der Fall anders und bei genauer Betrachtung des Ablaufs der Ereignisse beim
Löschen eines Datensatzes wird einiges klarer. Die Ereignisse haben folgende Reihenfolge:
» Form_Delete
» Form_Current
» Form_BeforeDelConfirm
» Form_AfterDelConfirm
Dabei werden die beiden letzten Ereignisse nur ausgelöst, wenn die Einstellung Er weitert|Be
arbeiten|Bestätigen|Datensatzänderungen in den Access-Optionen aktiviert ist.
Abbildung 3.66: Fehler beim Löschen des Datensatzes im Hauptformular
Wichtig ist zunächst, dass nach dem Delete-Ereignis der zu löschende Datensatz beziehungs
weise die zu löschenden Datensätze zunächst temporär gespeichert werden, bis
fest steht, dass der Löschvorgang nicht durch das Ereignis Vor Löschbestätigung des Formu
lars abgebrochen wird. Und genau dieses temporäre Speichern erledigt die Trans aktion,
die sich nicht mit dem Zuweisen des Recordset-Objekts zum Unterformular verträgt.
Das Problem lösen Sie, indem Sie den Zeitpunkt der Zuweisung des Recordset-Objekts
ein fach nach hinten verschieben – vom Form_Current- ins Form_AfterDelConfirm-
Ereignis. Dazu verwenden Sie die folgenden Prozeduren.
Die Prozedur Form_Delete stellt die Variable mDeletedForm auf den Wert True ein. Diese
Eigenschaft wird in der Prozedur Form_Current ausgewertet; wenn sie den Wert True enthält,
wird das Aktualisieren des Unterformulars unterbunden (siehe auch Listing 3.41).
251

Kapitel 3 Formulare
252
Private Sub Form_Delete(Cancel As Integer)
End Sub
mDeletedForm = True
Listing 3.43: Setzen einer Eigenschaft, an der andere Prozeduren den laufenden Löschvorgang
erkennen können
Die Prozedur Form_BeforeDelConfirm können Sie theoretisch auch weglassen. In diesem
Fall unterbindet sie die Standardmeldung von Access beim Löschen des Datensatzes
(siehe Abbildung 3.67).
Private Sub Form_BeforeDelConfirm(Cancel As Integer, Response As Integer)
End Sub
Response = acDataErrContinue
Listing 3.44: Verhindern der Rückfrage beim Löschen
Abbildung 3.67: Standardmeldung von Access beim Löschen von Daten
Die Prozedur Form_AfterDelConfirm ist wiederum sehr wichtig: Sie wird nur ausgelöst,
wenn Sie wie in Listing 4.42 die Access-Meldung unterbinden oder wenn Sie den
Löschvorgang im Fall der Anzeige bestätigen.
Die Prozedur ruft die Routine auf, die das Unterformular aktualisiert, und holt damit genau
den Vorgang nach, der durch Setzen der Variablen mDeletedForm im Form_Current-
Ereignis unterbunden wurde.
Private Sub Form_AfterDelConfirm(Status As Integer)
End Sub
UnterformularAktualisieren
Listing 3.45: Aktualisieren des Unterformulars nach vollendetem Löschvorgang
Restarbeiten
Damit das Beispiel wie beschrieben funktioniert, brauchen Sie lediglich die Eigenschaften
der Beziehungen zwischen den im Haupt- und Unterformular angezeigten Tabellen so
anzupassen, dass beim Löschen des Datensatzes im Hauptformular direkt die entsprechenden
Unterformulareinträge mitgelöscht werden. Dazu reicht das Setzen der
Eigenschaft Löschweitergabe an verwandte Datensätze im Eigenschaftsfenster der passenden
Beziehung (siehe Abbildung 3.68).

Abbildung 3.68: Aktivieren der Löschweitergabe zwischen verknüpften Tabellen
Einsatz in eigenen Formularen
Eingabevalidierung
Dem Einsatz dieser Technik in Ihren eigenen Formularen steht prinzipiell nichts im
We ge. Sie müssen lediglich alle in den beiden Formularmodulen enthaltenen De klara
tionen und Prozeduren in Ihre Formulare übertragen und einige Zeilen Code den
Ge gebenheiten Ihrer eigenen Datenbank anpassen – etwa die Datenherkünfte für
Haupt- und Unterformular und die Zeile, die beim Anlegen eines neuen Datensatzes im
Unterformular den Wert für den Fremdschlüssel festlegt (siehe Listing 3.37).
3.8 Eingabevalidierung
Zur defensiven Programmierung gehört, dass Sie keine ungültigen Daten zulassen. Das
fängt bei der Eingabe von Daten in Formularen an. Dieser Teil beschreibt die unterschiedlichen
Möglichkeiten zur Validierung der Eingabe. Die wichtigste Frage bei der
Validierung ist nicht, wie diese erfolgen soll, sondern zu welchem Zeitpunkt. Die folgenden
drei Regeln sind praxiserprobt:
» Fehlerhafte Eingaben wie Zeichenketten in Datumsfelder werden sofort geahndet.
» Fehlende Eingaben werden erst beim Bestätigen des Datensatzes bemängelt.
» Die Handhabung von abhängigen Feldern ist Geschmackssache – Beispiel Startdatum
und Enddatum. Am einfachsten ist eine Prüfung beim Bestätigen des Datensatzes.
3.8.1 Validieren direkt bei der Eingabe
Das Validieren unmittelbar nach der Eingabe erfolgt in einer Prozedur, die durch die
Ereigniseigenschaft Vor Aktualisierung des jeweiligen Steuerelements ausgeführt wird.
Eine solche Routine könnte beispielsweise wie folgt aussehen:
253

Kapitel 3 Formulare
254
Private Sub Projekt_BeforeUpdate(Cancel As Integer)
If IsNumeric(Left(Me!Projekt, 1)) Then
End If
End Sub
MsgBox "Der Projektname muss mit einem Buchstaben beginnen.", _
vbOKOnly + vbExclamation, "Eingabefehler"
Cancel = True
Exit Sub
Listing 3.46: Validierung bei der Eingabe
Die Routine prüft, ob die in das Feld Projekt eingegebenen Werte nicht mit einer Zahl
anfangen. Sollte dies doch der Fall sein, erscheint eine entsprechende Meldung (siehe
Abbildung 3.69).
Abbildung 3.69: Projektbezeichnungen, die mit einer Zahl beginnen, sind nicht erlaubt (frm ­
Projekte Detailansicht)
3.8.2 Validieren vor dem Speichern
Vor dem Speichern werden vor allem Pflichtfelder geprüft. Falls im obigen Formular die
Felder Projekt und Startdatum Pflichtfelder wären, würde die Prüfung wie folgt aussehen:
Private Function Validierung() As Boolean
If IsNull(Me!Projekt) Then
End If
MsgBox "Bitte geben Sie einen Projektnamen ein.", _
vbOKOnly + vbExclamation, "Fehlende Eingabe"
Me!Projekt.SetFocus
Exit Function
If IsNull(Me!Startdatum) Then
MsgBox "Bitte geben Sie das Startdatum ein.", _
vbOKOnly + vbExclamation, "Fehlende Eingabe"

End If
Me!Startdatum.SetFocus
Exit Function
If Not IsNull(Me!Startdatum) And Not IsNull(Me!Enddatum) Then
End If
If Me!Startdatum > Me!Enddatum Then
End If
MsgBox "Das Enddatum darf nicht hinter " _
& "dem Startdatum liegen.", _
vbOKOnly + vbExclamation, "Falsche Datumsangabe"
Me!Enddatum.SetFocus
Exit Function
Validierung = True
End Function
Listing 3.47: Validierung vor dem Speichern des Datensatzes
Eingabevalidierung
Die Prozedur prüft von oben nach unten alle Pflichtfelder. Sobald sie auf eines trifft, das
leer ist, gibt sie eine Fehlermeldung aus, setzt den Fokus auf das Feld mit dem fehlenden
Inhalt und bricht die Prozedur ab. Außerdem wird der Funktionswert nur auf True
gesetzt, wenn alle Validierungen erfolgreich verlaufen sind.
Abhängige Felder prüfen
Im letzten Teil der Routine aus Listing 3.47 finden Sie ein Beispiel, wie sich abhängige
Felder prüfen lassen. In diesem Beispiel wird sichergestellt, dass das Startdatum nicht
hinter dem Enddatum liegt.
Aufruf der Validierung vor dem Speichern
Nun müssen Sie diese Funktion nur noch von geeigneter Stelle aus aufrufen. Leider
reicht es nicht, dies mit der Ereigniseigenschaft Vor Aktualisierung abzudecken. Die dazugehörende
Ereignisprozedur enthält auch den passenden Cancel-Parameter, der das
Speichern des Datensatzes bei falschen oder fehlenden Daten abbrechen könnte.
Es gibt allerdings eine Schwachstelle: Theoretisch wird diese Routine zwar durch alle
relevanten Vorgänge wie Wechsel des Datensatzes oder Schließen des Formulars aufgerufen
– aber wenn das Schließen einmal ausgelöst wurde, hält auch das Setzen des
Cancel-Parameters der Form_BeforeUpdate-Prozedur das Schließen nicht mehr auf.
Somit würde in diesem Fall ein Datensatz mit falschen oder fehlenden Daten gespeichert.
Daher rufen Sie die Funktion Validierung von zwei Prozeduren aus auf: Von der Form_
BeforeUpdate-Prozedur sowie von der cmdOK_Click-Prozedur aus. Um auszuschließen,
255

Kapitel 3 Formulare
dass das Formular anders als mit der OK-Schaltfläche geschlossen wird, stellen Sie
noch die Eigenschaft Schließen-Schaltfläche auf den Wert Nein ein.
Die beiden Ereignisprozeduren sehen schließlich wie folgt aus:
256
Private Sub cmdOK_Click()
If Validierung = True Then
End If
End Sub
DoCmd.Close acForm, Me.Name
Private Sub Form_BeforeUpdate(Cancel As Integer)
If Validierung = False Then
End If
End Sub
Cancel = True
Listing 3.48: Diese beiden Routinen rufen die Funktion Validierung auf
Alternativ können versierte Benutzer das Formular natürlich noch mit Strg + F4 schließen.
Um dem vorzubeugen, verwenden Sie eine Prozedur, die beim Ereignis Bei Taste
ausgelöst wird und das Betätigen dieser Tastenkombination unterbindet.
Gleichzeitig müssen Sie die Eigenschaft Tastenvorschau auf den Wert Ja einstellen:
Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = 115 And Shift = 2 Then
End If
End Sub
KeyCode = 0
Listing 3.49: Unterbinden der Tastenkombination zum Schließen eines Formulars
Tastenkombinationen sperren und bereitstellen mit dem
AutoKeys-Makro
Davon abgesehen ist das eine gute Gelegenheit, hier das AutoKeys-Makro vorzustellen:
Das ist nämlich neben dem AutoExec-Makro das zweite Makro, das aufgrund seines
Namens automatisch zu bestimmten Gelegenheiten ausgeführt wird – in diesem Fall
beim Eingeben von Tastenkombinationen.
Sie können damit nämlich beliebige Tastenkombinationen festlegen. Legen Sie einfach
ein neues Makro an und fügen Sie pro Tastenkombination eine Anweisung hinzu. Die
Tastenkombination tragen Sie dabei in der Spalte Makroname ein und verwenden dabei
die Syntax der SendKeys-An wei sung von VBA – die Kürzel für die Tastenkombinationen

Eingabevalidierung
finden Sie in der VBA-On line hilfe. Die Tastenkombination Strg + F4 fügen Sie dort etwa
so ein: ^{F4}.
Lassen Sie die Spalte Aktion leer, veranlasst Access beim Betätigen dieser Tastenkombination
schlicht nichts mehr – genau wie gewünscht. Natürlich können Sie auf diese
Weise auch Tastenkombinationen für richtige Funktionen festlegen. Das beschriebene
Makro finden Sie in der Beispieldatenbank.
3.8.3 Sonderfälle beim Validieren
Mit der oben genannten Vorgehensweise können Sie nicht alle möglichen
Eingabefehler abfangen. Wenn im Tabellenentwurf festgelegte Einschränkungen (siehe
»Integritätsregeln« auf Seite 81) bei der Eingabe oder beim Speichern des Datensatzes
nicht berücksichtigt werden, werden die dadurch hervorgerufenen Meldungen vor dem
Auslösen der Vor Aktualisierung-Ereignisprozeduren von Steuerelementen und For mularen
angezeigt.
Das ist zum Beispiel der Fall, wenn Sie einen Text in ein Da tums feld ein geben (siehe
Abbildung 3.70).
Abbildung 3.70: Access-eigene Validierungsmeldung
Wenn Sie diese Meldungen umgehen möchten, verwenden Sie die Bei Fehler-Er eig nisei
gen schaft des Formulars. Hier müssen Sie zwar ein wenig mehr Aufwand betreiben
als bei den oben beschriebenen Validierungsfunktionen, aber dafür ersetzen Sie damit
auch die Access-eigenen Validierungsmeldungen.
Im Formular frmProjekteDetailansicht kann es etwa passieren, dass eines der Felder
Startdatum oder Enddatum mit einem Wert bestückt wird, der nicht den Datentyp Datum/
Uhrzeit enthält, oder dass kein Kunde für das Projekt ausgewählt wird. Beide Fehler würden
die Integritätsregeln verletzen und eine Access-eigene Meldung heraufbeschwören.
Diese Meldungen können Sie nur im Bei Fehler-Ereignis abfangen. Die folgende Routine
wird durch dieses Ereignis ausgelöst und prüft, ob eines der beiden Datumsfelder einen
ungültigen Wert enthält. Falls ja, gibt es eine entsprechende Meldung aus; der Fokus
wird dann automatisch auf das betroffene Steuerelement gesetzt.
Damit Sie auf den richtigen Fehler reagieren, prüfen Sie in einer Select Case-
Verzweigung die in DataErr enthaltene Fehlernummer und verzweigen entsprechend.
Mit der An wei sung Screen.ActiveControl ermitteln Sie, bei welchem Steuerelement der
257

Kapitel 3 Formulare
Fehler ausgelöst wurde, und behandeln den Fehler dem betroffenen Feld entsprechend.
Ähnlich ist es beim Speichern des Datensatzes ohne Füllen des Pflichtfeldes KundeID. Die
Fehlernummer lautet 3201 und Sie ermitteln ganz einfach, ob das Feld KundeID für diesen
Fehler verantwortlich ist, indem Sie dessen Inhalt überprüfen. Ist dieser Null, muss
der Benutzer den entsprechenden Kunden noch nachreichen. Wenn Sie nicht sicher sind,
welche Fehlernummer sich hinter den eingebauten Feh ler mel dungen verbirgt, lassen Sie
sich in dieser Routine einfach den Wert DataErr mit der Debug.Print-Methode ausgeben.
258
Private Sub Form_Error(DataErr As Integer, Response As Integer)
End Sub
Dim ctl As Control
Select Case DataErr
Case 2113
Set ctl = Screen.ActiveControl
Select Case ctl.Name
Case "Startdatum", "Enddatum"
End Select
Case 3201
End Select
MsgBox "Bitte geben Sie ein Datum im Format " _
"'dd.mm.jjjj' ein.", vbOKOnly + vbExclamation, _
"Eingabefehler"
Response = acDataErrContinue
Exit Sub
If Me!KundeID = 0 Then
End If
MsgBox "Bitte wählen Sie einen Kunden für dieses " _
& "Projekt aus.", vbOKOnly + vbExclamation, _
"Fehlende Eingabe"
Response = acDataErrContinue
Me!KundeID.SetFocus
Exit Sub
Listing 3.50: Behandlung von Verletzungen der Integrität bei der Dateneingabe
3.9 Suchen in Formularen
Die Suche nach bestimmten Daten erfordert je nach Anwendungsfall unterschiedliche
Maßnahmen. In den folgenden Abschnitten finden Sie zwei Möglichkeiten, die sich für
viele Anwendungen eignen – eine Schnellauswahl per Kombinationsfeld und ein Text feld
zum schnellen Filtern von Listenfeldern.

3.9.1 Schnelles Suchen in Formularen
Suchen in Formularen
Für die Suche in Tabellen, Abfragen und Formularen bietet Access ab Version 2007 ein
unscheinbares Text feld im Navigationsbereich dieser Objekte. Hier geben Sie einfach
den gesuchten Be griff Buchstabe für Buchstabe ein und Access sucht die jeweils nächste
Fundstelle in den Daten der Datensatzquelle des Formulars (siehe Abbildung 3.71).
Das Betätigen der Ein ga betaste bewirkt das Aufsuchen der nächsten Fundstelle.
Der Nachteil dieses Suchfelds ist, dass es die Suche nicht auf bestimmte Datenfelder
begrenzt, sondern einfach in allen Steuerelementen des Formulars sucht – und das ist
nicht immer unbedingt erwünscht.
Abbildung 3.71: Die eingebaute Suche von Access
3.9.2 Schnelles Filtern in der Datenblattansicht
Seit der Version 2007 liefert Access eine Filter-Funktion für die Datenblattansicht
von Tabellen, Abfragen und Formularen mit. Sie rufen diese Funktion über die kleine
Schaltfläche mit dem Pfeil nach unten in den Spaltenköpfen der Datenblattansicht auf
(siehe Abbildung 3.72).
Die Filterkriterien unterscheiden sich je nach Datentyp. Sehr nützlich ist der Datumsfilter:
Er bietet Vergleichskriterien wie morgen, heute, gestern, nächste Woche, diese Woche,
letz te Woche und so weiter. Dieses Feature liefert einen guten Grund, dem Benutzer
Da ten in der Datenblattansicht statt in einem Endlosformular zu präsentieren. Die Bedie
nung dieses Filters ist im Übrigen selbsterklärend.
3.9.3 Schnellauswahl per Kombinationsfeld
Eine der einfachsten Möglichkeiten zum Einbau einer Suche ist ein Kombinationsfeld zur
Auswahl von Werten aus einem oder aus mehreren kombinierten Feldern. Das folgende
Beispiel basiert auf einem Formular zum Bearbeiten von Kontakten.
259

Kapitel 3 Formulare
Abbildung 3.72: Filtern von Datenblättern
Die Schnellauswahl per Kombinationsfeld ist nur dann sinnvoll, wenn die gewünschten
Datensätze nach einem einzigen Kriterium durchsucht werden – beispielsweise nach
dem Nachnamen eines Kontaktes.
Diese Variante finden Sie im folgenden Beispiel: Das Formular aus Abbildung 3.73 enthält
alle Felder der Tabelle tblKontakte, zwei Schaltflächen mit der Beschriftung OK und
Abbrechen sowie ein Kombinationsfeld namens cboSchnellsuche.
Abbildung 3.73: Formular mit Schnellauswahl in der Entwurfsansicht
Das Kombinationsfeld verwendet die Abfrage aus Abbildung 3.74 als Datensatzherkunft.
Die Abfrage enthält ein Feld mit dem Primärschlüsselfeld der Tabelle tblKontakte sowie
ein aus den beiden Feldern Nachname und Vorname zusammengesetztes Feld, wobei die
beiden Werte durch ein Komma getrennt werden.
260

Suchen in Formularen
Abbildung 3.74: Datensatzherkunft des Kombinationsfeldes zur Schnellauswahl von Kontakten
Damit lassen sich mit dem Kombinationsfeld alle Einträge der Tabelle tblKontakte in
der Form , anzeigen. Damit das Formular auch den ausgewählten
Datensatz einblendet, fügen Sie der Ereigniseigenschaft Nach Aktualisierung des
Kombinationsfeldes die folgende Prozedur hinzu:
Private Sub cboSchnellauswahl_AfterUpdate()
End Sub
Me.Recordset.FindFirst "KontaktID = " & Me!cboSchnellauswahl
Listing 3.51: Datensatz suchen für Formulare mit Recordset-Eigenschaft
Das Auswählen eines Eintrags des Kombinationsfeldes führt nun zur Anzeige des gewünsch
ten Datensatzes im Formular (siehe Abbildung 3.75).
Abbildung 3.75: Die Schnellsuche im Einsatz (frmSchnellsuchePerKombinationsfeld)
Es fehlt nur noch die Ak tu alisierung der Datensatzherkunft des Kombinationsfeldes
beim Ändern, Hinzufügen oder Löschen von Datensätzen im Formular. Diese Aufgabe
261

Kapitel 3 Formulare
übernimmt die folgende Prozedur, die durch die Ereigniseigenschaft Beim Anzeigen des
Formulars ausgelöst wird:
262
Private Sub Form_Current()
End Sub
'Aktualisieren des Inhalts des Kombinationsfeldes
Me!cboSchnellauswahl.Requery
Listing 3.52: Aktualisieren des Kombinationsfeldes
3.9.4 Schnelles Filtern von Listenfeldern
Listenfelder kommen oft zum Einsatz, wenn Datensätze in einer Übersicht zur Auswahl
angeboten werden sollen. Wenn viele Datensätze zur Auswahl bereitstehen, macht eine
Möglichkeit zum Filtern der Datensätze Sinn.
Die üblichen Filter-Funktionen bestehen aus verschiedenen Textfeldern zur Eingabe der
Filterkriterien und einer Schaltfläche zum Auslösen des Filtervorgangs mit den neuen
Parametern. Je mehr Felder man mit einer solchen Filter-Funktion abdeckt, desto
mächtiger ist diese – dafür benötigt man aber auch entsprechend viele Steuerelemente,
durch die sich der Benutzer erst einmal hindurchkämpfen muss.
In vielen Fällen ist das gar nicht notwendig; dort lässt sich eine viel handlichere Lösung
einsetzen: Stellen Sie dem Benutzer einfach ein Textfeld bereit, das in beliebig vielen
Feldern des Listenfeldes sucht und unmittelbar nach der Eingabe eines jeden
Buchstabens die angezeigten Datensätze filtert.
Dazu ist neben ein wenig Routinearbeit noch ein kleiner Trick notwendig – sehen Sie
einfach selbst. Abbildung 3.76 zeigt das fertige Formular in der Entwurfsansicht. Es
enthält ein Lis ten feld zur Anzeige der Datensätze, eine Schaltfläche zum Anzeigen der
Detailansicht des markierten Datensatzes und ein Textfeld zur Eingabe des Suchbegriffs.
Abbildung 3.76: Listenfeld mit Schnellfilter

Suchen in Formularen
Das erste Textfeld namens txtSuche dient der Eingabe des Suchbegriffs. Der Inhalt des
Listenfeldes lstKontakte soll nach jeder Änderung des im Textfeld txtSuche enthaltenen
Suchbegriffs aktualisiert werden.
Das Listenfeld bezieht seine Daten aus der Abfrage qryKontakteListenfeld (siehe
Abbildung 3.77). Die Abfrage enthält die anzuzeigenden Felder in der gewünschten Reihen
fol ge und Sortierung.
Damit das Listenfeld nach jeder Änderung des Inhalts des Textfeldes txtSuche aktualisiert
wird, verwenden Sie eine sonst recht stiefmütterlich behandelte Ereigniseigenschaft.
Die Ereigniseigenschaft Bei Änderung des Feldes zur Eingabe des Suchbegriffs wird bei
jeder Änderung des Inhalts ausgelöst. Für die entsprechende Ereignisprozedur fügen
Sie den folgenden Code ein:
Abbildung 3.77: Datensatzherkunft des Listenfeldes zur Anzeige der Kontakte
Private Sub txtSuche_Change()
End Sub
Dim strSuchbegriff As String
'Suchbegriff in Variable speichern
strSuchbegriff = Me!txtSuche.Text
'Neue Datensatzherkunft zuweisen
Me!lstKontakte.RowSource = "SELECT * FROM qryKontakteListenfeld " _
"WHERE Nachname LIKE '" & strSuchbegriff & "*'"
'Inhalt des Listenfeldes aktualisieren
Me!lstKontakte.Requery
Listing 3.53: Prozedur zum Filtern des Listenfeldes
Der Trick ist, dass Sie nicht den Inhalt des Textfeldes über die Eigenschaft Value auswerten,
sondern die Text-Eigenschaft verwenden. Die Value-Eigenschaft wird nämlich erst
nach dem Aktualisieren des Textfeldes auf den tatsächlichen Inhalt eingestellt.
263

Kapitel 3 Formulare
Der Abfrageausdruck ermittelt alle Datensätze der Abfrage qryKontakteListenfeld, in denen
der Nachname mit dem im Textfeld angegebenen Ausdruck beginnt.
Der Vollständigkeit halber finden Sie hier noch den Code zum Anzeigen des im Listenfeld
ausgewählten Kontaktes. Der Kontakt soll im Formular aus dem vorherigen Beispiel
angezeigt werden. Zwei Aktionen sollen dazu führen: ein Doppelklick auf das Listenfeld
und ein Klick auf die Schaltfläche cmdAnzeigen. Die entsprechenden Ereignisse sollen
prinzipiell die gleiche Aktion auslösen – daher legen Sie dafür eine neue Prozedur an
und rufen diese über die beiden Ereignisprozeduren auf:
264
Private Sub cmdAnzeigen_Click()
End Sub
Anzeigen
Private Sub lstKontakte_DblClick(Cancel As Integer)
End Sub
Anzeigen
Private Sub Anzeigen()
If Not IsNull(Me!lstKontakte) Then
End If
End Sub
DoCmd.OpenForm "frmSchnellsuchePerKombifeld", _
WhereCondition:="KontaktID = " & Me!lstKontakte, _
WindowMode:=acDialog
Listing 3.54: Prozeduren zum Anzeigen der Details eines Kontaktdatensatzes

Copyright
Daten, Texte, Design und Grafiken dieses eBooks, sowie die eventuell
angebotenen eBook-Zusatzdaten sind urheberrechtlich geschützt. Dieses eBook
stellen wir lediglich als persönliche Einzelplatz-Lizenz zur Verfügung!
Jede andere Verwendung dieses eBooks oder zugehöriger Materialien und
Informationen, einschließlich
der Reproduktion,
der Weitergabe,
des Weitervertriebs,
der Platzierung im Internet, in Intranets, in Extranets,
der Veränderung,
des Weiterverkaufs und
der Veröffentlichung
bedarf der schriftlichen Genehmigung des Verlags. Insbesondere ist die
Entfernung oder Änderung des vom Verlag vergebenen Passwortschutzes
ausdrücklich untersagt!
Bei Fragen zu diesem Thema wenden Sie sich bitte an: info@pearson.de
Zusatzdaten
Möglicherweise liegt dem gedruckten Buch eine CD-ROM mit Zusatzdaten bei.
Die Zurverfügungstellung dieser Daten auf unseren Websites ist eine freiwillige
Leistung des Verlags. Der Rechtsweg ist ausgeschlossen.
Hinweis
Dieses und viele weitere eBooks können Sie rund um die Uhr und legal auf
unserer Website herunterladen:
http://ebooks.pearson.de