Vorauswahl Filter über Kombifeld in Unterformular

[Lola_AT]

Hallo liebe Access Maniacs.
Bin nach 15 Jahren wieder dabei eine Access-Datenbank zu erstellen.
Diesmal zur Verwaltung von Photovoltaik-Anlagen.
Für eine gute Übersicht arbeite ich mit Unterformularen.
Trotz längerer Abstinenz läuft es eigentlich ganz gut, stehe aber jetzt bei einem Problem an:

Ich habe ein Unterformular PV-Teilgenerator (subformTeilgenerator) basierend auf Tabelle tblPVTeilgenerator in welchem die Wechselrichter ausgewählt werden sollen. Die tblPVTeilgenerator steht in einer n:1 Beziehung zur Tabelle tblWechselrichter.

Im subformTeilgenerator stenen 2 Kombolfelder für die Auswahl der Wechselrichter:
* WRHersteller (WechselrichterHersteller) zur Einschränkung der Suche auf den richtigen Hersteller mit der Datensatzherkunft
SELECT DISTINCT tblWechselrichter.Hersteller, tblWechselrichter.Hersteller FROM tblWechselrichter

* WRTyp enthält den Fremdschlüssel (ID)  der Tabelle tblWechselrichter und hat als Datensatzherkunft
SELECT tblWechselrichter.ID, tblWechselrichter.Typ FROM tblWechselrichter WHERE (((tblWechselrichter.Hersteller)=[WechselrichterHersteller])) ORDER BY tblWechselrichter.Typ, tblWechselrichter.Hersteller;

Um bei Auswahl eines andere WRHerstellers bzw.das dazugehörige Kombifeld zu aktualisieren wird folgendes Ereignis ausgeführt:

Private Sub cboWRHersteller_AfterUpdate()
DoCmd.Requery "cboWRTyp"
End Sub

Das ganze funktioniert bis zu dem Punkt wo zwei oder mehr unterschiedliche WRHersteller ausgewählt werden. Beim Requery werden dann immer ALLE Datensätze mit dem letzten WRHersteller abgefragt und im Feld WRTyp wird die Auswahl rückgesetzt. Somit kann ich keine unterschiedlichen WRTyp auswählen.
Könnt ihr mir da weiterhelfen?!   

[DF6GL]

Hallo,

--zeige bitte das Beziehungsfenster als Screenshot

--lad am besten die Db hier hoch, kompriniert/repariert und gezippt

Es ist zu befürchten, dass  der Tabellenaufbau nicht ganz korrekt ist  und/oder  dass Nachschlagefelder in Tabellen verwendete werden.

Zudem sollte dringend auf Leer- und Sonderzeichen bei der Namensgebung verzichtet werden.

[Lola_AT]

Danke für die schnelle Antwort. Beziehungen sind schon raufgeladen.
Bezüglich Sonderzeichen habe zumindest in den SQL und VBA referenzierten Feldern darauf geachtet, dass keine Sonderzeichen stehen, werde ich aber nochmal alles überarbeiten.
Bezüglich Nachschlagefelder ist mir die Problematik nicht ganz bewusst?
Der Hersteller in tblWechselrichter ist z.B. ein Lisentenfeld mit mehreren Einträgen.

[DF6GL]

Hallo,

Die Tabellenfeldnamen  sollten keine Sonderzeichen enthalten (z. B. "PV-Modul"   mit Minus-Zeichen,  Leerzeichen in "Art der Lieferung").

Die 1:1-Beziehung bei tblMessung solltest Du erklären.


Bedeutet

Der Hersteller in tblWechselrichter ist z.B. ein Lisentenfeld mit mehreren Einträgen.

dass es sich um ein Mehrwertfeld handelt?   wenn so, dann ändere das um in eine 1:n-Beziehung mit einer weiteren Tabelle "tblHersteller".

Warum steht eine Beziehung zwischen tblPVAnlage.Auftragsnummer und tblPVTeilgenerator.Auftragsnummer  und nicht zu tblPVAnlage.AnlagenID?

Die "ID"-Felder sollten eindeutig benamst werden, also z. B. MessID in tblMessung.

Klarere Bezeichnung wählen, z. B. "WechselrichterTyp" ---> "WechselrichterID_f"  und "tblwechselrichter.ID"  --> "tblWechselrichter.WechselRichterID"

tblPVTeilgenerator.WechselrichterHersteller ist überflüssig/falsch, weil der Hersteller schon durch die Beziehung zu tblWechselrichter definiert ist.




Die Nachschlagefelder (in Tabellen) gaukeln eine falsche/undurchsichtige Datenbeziehung vor und sind problematisch in der Handhabung.
Im Grunde sind Kombi-und Listennachschlagefelder nicht anderes als verdeckte 1:n Beziehungen für interne Tabellen.

[Beaker s.a.]

Hallo Lola,

Bezüglich Nachschlagefelder ist mir die Problematik nicht ganz bewusst?

Schaust du hier: https://dbwiki.net/wiki/Access_Anf%C3%A4nger:_Die_Nachteile_von_Nachschlagefeldern
Ansonsten stimmt da/fehlt da noch so Einiges.
Ganz grob, auf den ersten Blick:
- eine tblHersteller (ID = Fremdschlüssel (FK) in tblWechselrichter und
tblPVModul -> Name: "HerstellerID_F")
- eine tblAuftraege mit FK "AnlageID_F"
was soll den ein Primärschlüssel (PK) "Auftragsnummer" in einer Tabelle,
die Anlagen verwaltet?
Bei einer 1:1-Beziehung müssen beide Schlüssel gleich sein, - das geht
nicht mit AutoWerten. Da sollte wohl eher ein FK "PVStringID_F" in die
Tabelle tblMessungen.
Ansonsten kann ich erstmal nicht viel Weiteres sagen, da ich die abzubildende
Realität nicht kenne.
Noch was zu Benamsung, - zu den schon erwähnten Sonderzeichen gehört
auch der Bindestrich "-". Tabellen würde ich immer mit der Mehrzahl
benennen, denn sie enthalten ja mehrere Objekte. Die Schlüsselfelder
dann in der Einzahl mir Suffix "ID" (PK) bzw. "ID_F" (FK).
Hab' ich früher auch nicht gemacht, inzwischen aber angewöhnt (ist
hilfreich!).
gruss ekkehard

Inzwischen war Klaus schneller, nimm es daher als Ergänzung und
Hinweis darauf wie wichtig ein korrektes Datenmodell ist.

[Lola_AT]

OK sehe schon ich mussdie Tabellen nochmal bearbeiten und von Sonderzeichen und Nachschlagefeldern befreien.

Der Grund für keine eigene Herstellertabelle war:
Ich wollte die Auswahl und Anzeige so wie jetzt in jeweils einem Unterformular realisieren, außerdem sind es nur ungefähr 10 Hersteller. Die Konsistenz wollte ich mit der obligatorischen AfterUpdate Abfrage bei Änderung vom Hersteller sicherstellen.
Falls ich dafür kein gebundenes Feld verwenden darf kann ich das zumindest durch ein ungebundenes machen?

Die Auftragsnummer ist die Schnittstelle aus unserem ERP-System und jede Anlage hat eine eindeutige Auftragsnummer.
Kann die komprimierte Datenbank nicht hochladen  --> 800kB

[Beaker s.a.]

Hallo Lola,

Die Auftragsnummer ist die Schnittstelle aus unserem ERP-System und jede Anlage hat eine eindeutige Auftragsnummer.

Also ein FK, und nicht der PK in deiner tblAnlagen, - ändern!
gruss ekkehard