3 abhängige Kombinationsfelder im Endlosformular mit Gruppierung

[KonradR]

Hallo liebe Accessfreunde,

ich habe ein Formular mit drei Unterformularen und möchte in dem dritten Unterformular, das ein Endlosformular ist, einen Datensatz aus einer Abfrage auswählen. In diesem möchte ich über drei abhängige Kombinationsfelder filtern, da sich der betreffende Datensatz aus 3 Feldern zusammensetzt, die indiziert sind.

Konkret die Felder "Laden", "Marke", "Produkt". Es soll also die Auswahl von Marken im Kombinationsfeld cboMarken eingeschränkt werden, wenn ich im Kombinationsfeld cboLaden eine Auswahl treffe. Die Auswahl von Produkten im Kombinationsfeld cboProdukte soll natürlich auch eingeschränkt werden, wenn ich anschließend eine Auswahl im Kombinationsfeld cboMarken treffe. Das funktioniert auch ganz gut.

Nun ist es nur so, dass es vorkommen kann, dass unter einer Marke eines Ladens verschiedene Produkte vorkommen können. Wenn ich dann einen Laden im Kombinationsfeld cboLaden auswähle, wird mir xmal z.B. die Marke BioBio angezeigt, obwohl ich die nur 1x sehen will, weil mir das die Auswahl erleichtert.

In der zugrundeliegenden Abfrage auf die sich der VBA-Code bezieht, sind natürlich auch mehrere Datensätze für eine Marke vorhanden, weil es auch mehrere Produkte von einer Marke gibt. Wie kann ich nun die Einschränkung im Kombinationsfeld cboMarke und anschließden im Kombinationsfeld cboProdukt gruppieren um nur 1x die Marke im cboMarke bzw. nur 1x das Produkt im cboProdukt angezeigt zu bekommen? Schon im Voraus vielen Dank.

Hier noch ein Bild der Beziehungsstruktur mit den ReferenzID's (rot eingekreist):
Sie dürfen in diesem Board keine Dateianhänge sehen.

Für das Kombinationsfeld cboLaden habe ich folgende Abfrage als Datensatzherkunft hinterlegt:
Sie dürfen in diesem Board keine Dateianhänge sehen.

Die dem Kombinationsfeld cboMarke zugrundeliegende Abfrage ist so aufgebaut:
Sie dürfen in diesem Board keine Dateianhänge sehen.

Und den Code für die Aktualisierung von den Kombinationsfeldern cboMarke und cboProdukt ist hier:

Code [Auswählen] Erweitern

Private Sub cboLaden_AfterUpdate()
Dim strSQL As String
    strSQL = "SELECT ZutatStammmarkeIDRef, MarkeText FROM qryCboZutatStammMarke WHERE ZutatStammladenIDRef = " & Me!cboLaden
    Me!cboMarke.RowSource = strSQL
    Forms![frm10TestAbhCbo].Form![cboMarke].Requery
    Forms![frm10TestAbhCbo].Form![cboProdukt].Requery
    Forms![frm10TestAbhCbo].Form![cboProdukt].Value = ""
End Sub

Private Sub cboMarke_AfterUpdate()
Dim strSQL As String
    strSQL = "SELECT ZutatStammID, ZutatStammladenIDRef, ZutatStammmarkeIDRef, ZutatStammnameIDRef, ZutatNameText " & _
    "FROM qryCboZutatStammProdukt WHERE ZutatStammmarkeIDRef = " & Me!cboMarke & " And ZutatStammladenIDRef = " & Me!cboLaden
    Me!cboProdukt.RowSource = strSQL
    Forms![frm10TestAbhCbo].Form![cboProdukt].Requery
End Sub


[ebs17]

Es soll also die Auswahl von Marken im Kombinationsfeld cboMarken eingeschränkt werden, wenn ich im Kombinationsfeld cboLaden eine Auswahl treffe.

Das ist per vorgelegten Datenmodell nicht möglich, es gibt zwischen den drei Tabellen keine Abhängigkeiten.

Was Du hier machen könntest, wäre die Verwendung einer ComboBox/ListBox, die per Kreuzprodukt aus den drei Tabellen alle möglichen Kombinationen bereitstellt und wo eine Auswahl dann alle drei Fremdschlüsselfelder mit Werten belegt.

[KonradR]

es gibt zwischen den drei Tabellen keine Abhängigkeiten.

Das stimmt. Allerdings sind die Fremdschlüssel zu den Tabellen in der Tabelle "tblZutatStamm" indiziert, so dass für die Kombination Laden/Marke/Produkt keine Duplikate möglich sind.

Was Du hier machen könntest, wäre die Verwendung einer ComboBox/ListBox, die per Kreuzprodukt aus den drei Tabellen alle möglichen Kombinationen bereitstellt und wo eine Auswahl dann alle drei Fremdschlüsselfelder mit Werten belegt.

Ich verstehe das so, dass ich ein Kombinationsfeld oder ein Listenfeld in mein Endlosformular einbaue, welches dann die Werte aller drei bzw. vier Tabellen in Kombination miteinander anzeigt und welche ich dann aus dem Kombinationsfeld auswählen kann. Meintest du das so?

[MzKlMu]

Hallo,

Allerdings sind die Fremdschlüssel zu den Tabellen in der Tabelle "tblZutatStamm" indiziert,

Das hat ja mit Abhängigkeiten nichts zu tun.
Diese Abhängigkeiten zu schaffen wird nicht so einfach sein wie Du Dir das gerade denkst, denn:

dass unter einer Marke eines Ladens verschiedene Produkte vorkommen können.

Das ist eine n:m Beziehung wozu eine Zuordnungstabelle erforderlich ist.
Die Tabelle mit dem Zutatnamen ist überflüssig. Der Name der Zutat gehört direkt in die Stammtabelle.

Allerdings sind die Fremdschlüssel zu den Tabellen in der Tabelle "tblZutatStamm" indiziert,

Das hat ja mit Abhängigkeiten nichts zu tun.

Im Grunde ist die Statmmtabelle der Zutaten auch falsch, denn die Eigenschaften Kj, Kcal etc. müssen in eine extra Tabelle und dann ist zwischen Zutat und Eigenschaft wieder eine n:m Zuordnungstabelle notwendig. Es ist auch nicht notwendig Kj und Kcal zu speichern, denn die sind ja umrechenbar.
Aber das hatten wir alles schon mal, hast Du aber nicht einfließen lassen.

[KonradR]

Das hat ja mit Abhängigkeiten nichts zu tun.
Diese Abhängigkeiten zu schaffen wird nicht so einfach sein wie Du Dir das gerade denkst, denn:

Das wird mir auch immer klarer, denn ich möchte aus Gründen einer komfortablen Eingabe in einem Endlosformular Laden, Marke und Produkt hintereinander in Textfeldern auswählen können, die sich dann abhängig voneinander aktualisieren.

Das ist eine n:m Beziehung wozu eine Zuordnungstabelle erforderlich ist.

Das macht Sinn, aber dann kann ich die Daten aus Laden, Marke und Produkt nicht mehr in mehreren Textfeldern hintereinander in einem Endlosformular darstellen.

Die Tabelle mit dem Zutatnamen ist überflüssig. Der Name der Zutat gehört direkt in die Stammtabelle.

Danke. Das denke ich auch. Das hatte ich nur wegen der Normalformen so eingerichtet um zu ereichen, dass keine Schreibfehler entstehen können. Hier hole ich die Daten für den Zutatnamen eh aus einem Kombinationsfeld. Damit ist es dann doppelt gemoppelt und somit überflüssig.

Das hat ja mit Abhängigkeiten nichts zu tun.

Danke. Habe ich jetzt auch gelernt.

Im Grunde ist die Statmmtabelle der Zutaten auch falsch, denn die Eigenschaften Kj, Kcal etc. müssen in eine extra Tabelle und dann ist zwischen Zutat und Eigenschaft wieder eine n:m Zuordnungstabelle notwendig.

Jedenfals kann ich mit meiner so erstellten Tabelle als Datensatzquelle die Nährwerte in einem Formular abrufen. Wenn ich die Nährwerte in eine Extratabelle auslagere und per n:m Beziehung verknüpfe, müsste ich für jeden Nährwert ein Unterformular erzeugen, bei dem ich dann die Bildlaufleisten nicht anzeigen lasse. Anschließend müsste ich den Bildlauf aller Unterformulare per Windows API synchronisieren. Da ich (noch) nicht der Windows API mächtig bin, habe ich diese Möglichkeit abgewählt.

[MzKlMu]

Hallo,
kannst Du bitte mal die Abhängikeit von Laden, Marke und Produkt genauer beschreiben ?

Wenn ich die Nährwerte in eine Extratabelle auslagere und per n:m Beziehung verknüpfe, müsste ich für jeden Nährwert ein Unterformular erzeugen, ............................

Wie kommst Du denn auf diese abenteuerliche Idee. Für die Darstellung von n:m Beziehungen braucht man genau ein Ufo, das über die Schlüsselfelder verknüpft wird. Jeder Nährwert ist dann ein Datensatz. Auch in der eigentlichen Nährwerttabelle sind alle Nährwerte als je ein Datensatz (nicht je ein Feld) erfasst. Zuordnung per Kombi. Und Api Funktionen braucht es da schon mal gar nicht, da muss man auch keinen Bildlauf synchronisieren, es gibt ja nur ein Ufo. Die ganze Gestaltung und Aufbau geht auch komplett ohne VBA. Für die normalen Funktionalitäten wirst Du hier mit Sicherheit keine API Funktionen benötigen.

Du solltest Dich mit dem Aufbau von n:m Beziehungen beschäftigen.

[KonradR]

Wie kommst Du denn auf diese abenteuerliche Idee. Für die Darstellung von n:m Beziehungen braucht man genau ein Ufo, das über die Schlüsselfelder verknüpft wird. Jeder Nährwert ist dann ein Datensatz. Auch in der eigentlichen Nährwerttabelle sind alle Nährwerte als je ein Datensatz (nicht je ein Feld) erfasst. Zuordnung per Kombi.

Wenn ich das so umsetze, dann sieht das in meiner Beziehunsstruktur so aus:
Sie dürfen in diesem Board keine Dateianhänge sehen.
Dann habe ich in der Tabelle tblNaehwerte100g für jeden Nährwert einen Datensatz, den ich per Kombinationsfeld zuordne. Die Reihenfolge kann demnach frei gewählt werden. So weit so gut. Bei der frei wählbaren Reihenfolge fangen für mich aber die Herausforderungen an, denn ich darf  sicherstellen, dass im Formular immer der gleiche Nährwert an der gleichen Stelle angezeigt wird. Steuerelemente, die ich im Unterformular platzieren kann und die über eine Filterfunktion in der Datensatzherkunft verfügen sind das Kombinations- und das Listenfeld. Ich würde hier das Listenfeld wählen, weil es optisch von einem Textfeld nicht zu unterscheiden ist. Dann würde ich im Listenfeld für jeden Datensatz das Kriterium bzw. die Where-Klausel auf den Namen bzw. die ID des Datensatzes aus dem Feld "Naehwnamepr100IDRef" setzen und genau nach diesem Wert filtern. Dann habe ich z.B. den Wert für die Angabe "kJ" gefiltert und kann diesen im Listenfeld des UFO's anzeigen.

Nun möchte ich aber auch noch die restlichen Nährwerte anzeigen. Also erzeuge ich für jeden weiteren Nährwert ein weiteres Listenfeld mit einer neuen Abfrage, denn ich kann die für den 1.Nährwert erstellte Abfrage nicht für den 2.Nährwert nehmen, denn da wird ja sonst nur der Wert für den 1.Nährwert angezeigt. Das könnte funktionieren. Dann würd ich nur ein Formular benötigen. Dann habe ich 9 Abfragen. Also für 9 Nährwerte je eine Abfrage, die ich auch noch in der Datensatzquelle des UFOS unterbringen darf. Das empfinde ich als sehr aufwendig. Selbst wenn es gelingt, bleibt noch die Frage, wie ich dann die Werte für meine weitergehenden Berechnungen definieren soll, wenn z.B. berechnet werden soll, wieviel kJ in einem TL Mandelmehl oder ähnlichem enthalten sind.

So wie ich das Datenmodell jetzt erstellt habe, steht alles fest definiert an fest definierter Stelle im Datensatz für die Zutat und die Berechnung der Werte funktioniert. Dann bleibt für mich nur die Frage: Warum soll ich mir den Mehraufwand machen, wenn ich mit weniger Aufwand das gleiche Ergebnis erhalte?

Du solltest Dich mit dem Aufbau von n:m Beziehungen beschäftigen.

Absolut. Da habe ich noch ein bisschen Nachholbedarf, denn oft stehe ich vor der Frage, welche Beziehung für meine Datenstruktur, in diesem konkreten Fall am sinnvollsten ist. Da haben mir deine Tips und Hinweise bisher sehr geholfen. Der Weg zu voller Erkenntnis ist halt ein Weg, der wahrscheinlich nie zu Ende ist, weil die Erkenntnis immer nur den Moment und nie alles erkennt.

[MzKlMu]

Hallo,
Du denkst viel zu kompliziert. Für die ID des Nährwertnamens nimm in der Nährwerttabelle für "NamePr100ID" keinen Autowert, sondern eine Zahl (Longinteger) in 10er Schritten (dann kann man noch was dazwischen einfügen). Aufsteigend in der gewünschten Reihenfolge. Dann spielt die Eingabereihenfolge keine Rolle, Du musst zur Anzeige nur entsprechend sortieren (Über die Abfrage). Dann steht der Nährwert immer an der gleichen Stelle. Wenn Du die Nährwerte nebeneinander anzeigen willst, so geht das über eine Kreuztabellenabfrage.

Warum Du ein Listenfeld zur Auswahl des Nährwertes nimmst erschließt sich mir auch nicht. Ein Kombi ist doch da viel praktischer, außerdem sieht man - wegen des Pfeils - sofort dass hier was ausgewählt werden kann.
Was Du jetzt Filtern und wieso Du da jetzt 9 Abfragen brauchst verstehe ich auch nicht.
Die Tabelle tblZutatName ist wie bereits gesagt überflüssig. Der Name der Zutat gehört in die Stammtabelle der Zutat. Und in diese Tabelle muss auch der Fremdschlüssel zur Kategorie. Die Beziehung zwischen Laden und Marke zur Stammtabelle ist falsch. Du brauchst eine weitere Tabelle mit einem Fremdschlüssel zur Marke, zum Laden und zur Zutatstamm.

Was ist denn das Produkt bzw. was ist der Unterschied zwischen Produkt und Zutat ?

Der Preis einer Zutat muss auch in eine extra Tabelle, denn der ändert sich ja.

[KonradR]

Du denkst viel zu kompliziert.

Ich habe einen anderen Denkansatz was das Sortieren betrifft. Aber ja, ich weis einige Dinge, die Access betrifft, daher mache ich es mir wahrscheinlich zu schwer.

Für die ID des Nährwertnamens nimm in der Nährwerttabelle für "NamePr100ID" keinen Autowert, sondern eine Zahl (Longinteger) in 10er Schritten (dann kann man noch was dazwischen einfügen). Aufsteigend in der gewünschten Reihenfolge. Dann spielt die Eingabereihenfolge keine Rolle, Du musst zur Anzeige nur entsprechend sortieren (Über die Abfrage). Dann steht der Nährwert immer an der gleichen Stelle.

Dann muss ich ja immer die Reihenfolge im Kopf haben und diese immer in der korrekten Reihenfolge eingeben. Klar kann ich bei 10er Schritten immer was einfügen. Das scheint mir sehr fehleranfällig. Mit der Variante die Nummer für den Primärschlüssel manuel zu vergeben habe ich auch nicht so ein gutes Gefühl. Klar, der Primärschlüssel ist indiziert und erlaubt keine Duplikate. Es ist eine Möglichkeit.

Wenn Du die Nährwerte nebeneinander anzeigen willst, so geht das über eine Kreuztabellenabfrage

Danke, das war mir nicht klar. Da habe ich wieder was neues gelernt. Das eröffnet neue Möglichkeiten

Warum Du ein Listenfeld zur Auswahl des Nährwertes nimmst erschließt sich mir auch nicht. Ein Kombi ist doch da viel praktischer, außerdem sieht man - wegen des Pfeils - sofort dass hier was ausgewählt werden kann.

In dem Formular will ich ja nur die ausgerechneten Werte für die Nährwerte, welche anhand der Rezepteinheiten berechnet wurden anzeigen und nichts auswählen. Ein Listenfeld ist für den Zweck völlig ausreichend.

Was Du jetzt Filtern und wieso Du da jetzt 9 Abfragen brauchst verstehe ich auch nicht.

Mit deiner Variante sortierst du die Nährwerte und legst, wenn du die Nährwerte in die Tabelle schreibst bereits fest. Ich setzte die Listenfelder in der gewünschten Reihenfolge der Nährwerte und filtere dann den Inhalt der Listenfelder so wie ich es haben will. Also hat jedes Listenfeld einen gesetzten Filter für einen Nährwert. Wenn ich also 9 Nährwerte habe, dann benötige ich 9 Filter. Da ich in einer Abfrage nur einmal filtern kann, benötige ich also bei 9 Nährwerten auch 9 Filter. Klar kann ich 2 filter setzten. Aber filtern kann ich nur einmal.

Die Tabelle tblZutatName ist wie bereits gesagt überflüssig. Der Name der Zutat gehört in die Stammtabelle der Zutat.

Ja, der ist überflüssig. Ich hatte nur das alte Datenmodel noch mal hervorgeholt um auf deine Antwort besser eingehen zu können. Da hatte ich das noch nicht angepasst.

Du brauchst eine weitere Tabelle mit einem Fremdschlüssel zur Marke, zum Laden und zur Zutatstamm.

Das erschließt sich mir nicht so ganz, denn die Kombination aus Laden, Marke und Produkt ist ja das was ich brauche. Wen ich da eine weitere Vermittlungstabelle einbaue, so meiner Sorge, mache ich das ganze Datenmodell noch komplizierter.

Was ist denn das Produkt bzw. was ist der Unterschied zwischen Produkt und Zutat ?

Keiner. Den Tabellennamen darf ich noch anpassen.

Der Preis einer Zutat muss auch in eine extra Tabelle, denn der ändert sich ja.

Du meinst mit einem Datum hinterlegen? Das würde ich mir sparen, denn eine zeitliche Nachverfolgung vom Preis brauche ich nicht. Den würde ich bei einer Änderung einfach im Datensatz anpassen.

[MzKlMu]

Hallo,

Dann muss ich ja immer die Reihenfolge im Kopf haben und diese immer in der korrekten Reihenfolge eingeben.

Nein, die Eingabereihenfolge ist völlig wurscht. Über die Sortierzahl (der neue PS) wird die Reihenfolge bei der Anzeige immer berichtigt. Die Reihenfolgezahl, kannst Du auch nach der einmaligen Eingabe vergessen. Die ist auch nie sichtbar, die wird nur zur unsichtbaren Sortierung benötigt.

die Nummer für den Primärschlüssel manuel zu vergeben habe ich auch nicht so ein gutes Gefühl.

Du wirst doch in der Lage sein, für 9 Nährwerte einmalig den Primärschlüssel zu vergeben, einfach von 10 bis 90.

denn die Kombination aus Laden, Marke und Produkt ist ja das was ich brauche.

eben, die neue Tabelle ist ja dazu da genau diese Kombination zu erfassen. Außerdem willst Du ja abhängige Kombis und das geht nur mit dieser Tabelle.

Was Du mit den Listenfeldern willst habe ich immer noch nicht verstanden. Im Moment geht es ja nur um die Zuordnung der Nährwerte zu einer Zutat. Mit der Berechnung für das Rezept hat das ja alles nichts zu tun. Die Berechnung erfolgt ja über das Rezept. Und im Rezept werden in einem Ufo die Zutaten erfasst. Und dort erfolgt erst die Berechnung der Nährwerte pro Rezept in je einem Datensatz im Ufo. Bei den Tabellen über die wir jetzt geredet haben wird noch nichts gerechnet.

Keiner. Den Tabellennamen darf ich noch anpassen.

Wenn zwischen Produktnamen und Zutatnamen kein Unterschied ist, dann ist doch die Tabelle "tblProdukte" ersatzlos überflüssig.

Das ganze Datenmodell scheint mir noch völlig unausgegoren und ziemlich verworren.

[KonradR]

Nein, die Eingabereihenfolge ist völlig wurscht. Über die Sortierzahl (der neue PS) wird die Reihenfolge bei der Anzeige immer berichtigt. Die Reihenfolgezahl, kannst Du auch nach der einmaligen Eingabe vergessen. Die ist auch nie sichtbar, die wird nur zur unsichtbaren Sortierung benötigt.

Das mit der Kreuztabelle funktioniert. Zumindest in der Anzeige, denn die Berechnung habe ich noch nicht ausprobiert. Aber was ist, wenn ich zusätzlich noch den Preis für die Zutat im Rezept berechnen will. Das geht mit der gleichen Kreuztabelle nicht, denn die kann für die Spalten nur einen Wert aufnehmen. Hast du da eine Idee?

Du wirst doch in der Lage sein, für 9 Nährwerte einmalig den Primärschlüssel zu vergeben, einfach von 10 bis 90.

Umgesetzt.

eben, die neue Tabelle ist ja dazu da genau diese Kombination zu erfassen. Außerdem willst Du ja abhängige Kombis und das geht nur mit dieser Tabelle.

Funktioniert. Danke

Wenn zwischen Produktnamen und Zutatnamen kein Unterschied ist, dann ist doch die Tabelle "tblProdukte" ersatzlos überflüssig.

Ja, dann ist sie überflüssig. Das habe ich auch schon angepasst.