Komplexe Formulare mit abhängigen Kombinationsfeldern steuern: Ein Leitfaden

Moin. Ich bin Sönke Schäfer, der Datenschäfer. Wenn Du Formulare mit Access oder VBA entwickelst, kennst Du das Problem: Kombinationsfelder, die voneinander abhängen. Kunde wählt Land. Dann sollen im nächsten Feld nur noch passende Städte erscheinen. Klingt einfach. Wird in der Praxis schnell unübersichtlich. Und irgendwann sagt jemand: „Das geht in Excel einfacher.“

Geht’s aber nicht. Zumindest nicht richtig. Du brauchst saubere Logik, klare SQL und stabile Reaktion auf Benutzeraktionen. Genau darum kümmern wir uns heute.

Der Schmerz im Alltag

• Das Formular lädt zu langsam, weil alle Optionen auf einmal geladen werden.
• Das zweite Feld bleibt leer oder zeigt falsche Daten.
• Die Filter funktionieren – bis Du etwas löschst.

Ich hab das oft gesehen in KMUs: Die ersten zwei Felder gehen noch. Aber ab der dritten Abhängigkeit fängt das Chaos an. Und genau da setzen wir an. Strukturiert. Trocken. Effektiv.

Beispiel: Land ➝ Stadt

Du hast zwei Tabellen: tblLand und tblStadt. In tblStadt gibt es ein Fremdschlüsselfeld LandID.

So füllst Du das erste Kombinationsfeld (Land):

Me!cboLand.RowSource = "SELECT LandID, Landname FROM tblLand ORDER BY Landname"Me!cboLand.ColumnCount = 2Me!cboLand.ColumnWidths = "0cm;5cm"

Und jetzt das zweite Feld (Stadt), gefiltert nach Auswahl:

Private Sub cboLand_AfterUpdate()    Dim sql As String    sql = "SELECT StadtID, Stadtname FROM tblStadt " & _          "WHERE LandID = " & Nz(Me!cboLand, 0) & " ORDER BY Stadtname"        Me!cboStadt.RowSource = sql    Me!cboStadt.Requery    Me!cboStadt = NullEnd Sub

Erklärung:

• Bei Änderung von cboLand wird die Liste cboStadt aktualisiert.
• Der aktuelle Stadtwert wird gelöscht, damit es keine alten Daten gibt.

Mehrere Ebenen? Geht auch.

Du willst Land ➝ Stadt ➝ PLZ? Gleiche Logik, nächster Schritt im cboStadt_AfterUpdate.

Private Sub cboStadt_AfterUpdate()    Dim sql As String    sql = "SELECT PLZID, PLZ FROM tblPLZ " & _          "WHERE StadtID = " & Nz(Me!cboStadt, 0) & " ORDER BY PLZ"        Me!cboPLZ.RowSource = sql    Me!cboPLZ.Requery    Me!cboPLZ = NullEnd Sub

Damit bist Du schon bei einer dreistufigen Abhängigkeit. Und es bleibt lesbar.

Und was ist mit SQL Server?

Wenn Du über ODBC oder ADO arbeitest, kannst Du das genauso umsetzen. Nur die Abfragen sollten dann als Views oder Prozeduren hinterlegt sein – wegen Performance.

SELECT StadtID, StadtnameFROM dbo.vwStadtMitLandWHERE LandID = @LandIDORDER BY Stadtname

In VBA über ADO dann mit Parametern und Prepared Statements. Das machen wir, wenn’s schneller werden muss.

Stolperfallen und Tipps

• Setz immer Me!cboXY = Null, wenn sich die Quelle ändert.
• Keine ColumnWidths? Dann siehst Du IDs. Sieht keiner gern.
• Nutze keine gespeicherten RowSources bei abhängigen Feldern. Immer dynamisch setzen.

„Was im Frontend schick aussieht, muss im Code klar sein. Sonst kommt keiner mehr durch.“

Fazit vom Datenschäfer

Abhängige Kombifelder sind kein Hexenwerk. Aber sie brauchen Struktur. Und klare Regeln. Dann läuft das stabil – auch bei mehreren Ebenen. Du schaffst Übersicht, Geschwindigkeit und sauberes Verhalten. Genau das, was ein gutes Formular braucht.

Wenn Du willst, helf ich Dir, so ein Formular aufzubauen. Ohne Flimmern. Ohne Dropdown-Wahnsinn. Einfach klar.

Datenschäfer: Analyse, Auswertung und Automatisierung für KMU im Norden 🐑