Access: Unterformular mit LEFT JOIN als DataSource

[Rouven]

Hello,

ich hab da wieder mal ein Bastelproblem für Microsoft Access, hoffe für dieses Standardproblem gibt es eine Lösung.
Ich habe ein Hauptformular, auf dem immer genau ein Datensatz bearbeitet wird. In dieses Formular ist ein Unterformular eingebettet, das Kategorien mit optional befüllten Werten anzeigt. Im Design-View des Unterformulars ist als Datenquelle etwas der folgenden Art angegeben:
SELECT ... FROM t1 LEFT JOIN t2 ON ...
Als Verbindung zwischen Haupt- und Unterformular wird nun die ID des Hauptdatensatzes genutzt. Diese steht aber, wenn überhaupt, in t2. Was jetzt offenbar passiert ist, dass das Unterformular keine Datensätze findet, weil Access offenbar den LEFT-JOIN ausführt, danach aber einen Filter auf die entsprechende ID legt und somit nichts mehr findet.
Gibt es eine Möglichkeit zu sagen "zeige mir alle, bei denen entweder das Link-Feld übereinstimmt oder der Wert in den Unterdaten leer ist".

Hintergrund ist etwa folgendes Anwendungsszenario:
Standort  (->Hauptformular)
Kategorietabelle (->t1; was für Kategorien gibt es (Name, Typ, ...))
Standort_hat_Kategoriewert (->t2; für den Standort existiert ein Wert für die Kategorie)

Ich versuche ein Formular zu erzeugen, das definitiv alle Kategorien und zusätzlich den Wert für den aktuellen Standort anzeigt, sofern dieser vorhanden ist.
Brauche ich denn dafür wirklich wieder eine Skript-Logik, so dass das Formular nur alle Kategorien anzeigt und ich die Werte selbst befülle sobald sich die Auswahl des Hauptdatensatzes ändert?

MfG
Rouven

[King^Lully]

Hintergrund ist etwa folgendes Anwendungsszenario:
Standort  (->Hauptformular)
Kategorietabelle (->t1; was für Kategorien gibt es (Name, Typ, ...))
Standort_hat_Kategoriewert (->t2; für den Standort existiert ein Wert für die Kategorie)

Ich verstehe die gesamte Anforderung nicht richtig.
Deine Aufgabe wäre es m.E. die beteiligten Entitäten zu benennen und die Beziehungen zwischen denselben, zurzeit ahne ich irgendwie, dass es eine Tabelle "Objekte" gibt, denen "Standorte" zugewiesen sind (wenn genau ein Standort zugewiesen ist, darf ich von einer Tabelle ausgehen?!), diese Objekte werden Kategorien zugeordnet, wir haben eine "1:n" zwischen Objekte und Kategorien?! Und dann haben wir noch einen nullable Zeiger in "Objekte" auf die Tabelle "t2" für was genau?!

Ist es denn nicht möglich ein SQL zu schreiben und dieses an ein Grid im "Nebenformular" zu binden? Das "Nebenformular" wird doch nicht bearbeitet, oder?

[Rouven]

Hello,

Ich verstehe die gesamte Anforderung nicht richtig.

hab's befürchtet...

Stammdaten:
id
Straße
Hausnummer
PLZ
Ort
...

Kategorie:
id
Name
Typ
Beschreibung
...

Stammdaten_Kategorien
id_stammdaten
id_kategorie
wert

Formular
--------------------------------------------------------------
| Strasse: ________________                                  |
| Haus-Nr: ________________                                  |

...
----------------------------------------------------------
--------------------------------------------------------------

• Das Hauptformular ist gebunden an die Tabelle Stammdaten
• Das Unterformular ist definiert als gebunden an
  SELECT ... FROM kategorie LEFT JOIN stammdaten_kategorien ON id = id_kategorie
• Haupt- und Unterformular sind verbunden über Master=id Child=id_stammdaten

Ziel:

• Alle Kategorien im Unterformular sehen mit einem Bearbeiten-Feld daneben
• falls für den Stammdatensatz ein Wert vorhanden ist, eintragen

MfG
Rouven

[King^Lully]

Aha.   ;)

• Das Hauptformular ist gebunden an die Tabelle Stammdaten

Gut, no prob.

• Das Unterformular ist definiert als gebunden an
  SELECT ... FROM kategorie LEFT JOIN stammdaten_kategorien ON id = id_kategorie

Ich habe jetzt nicht die Zeit darüber nachzudenken, aber warum nicht auf die "n:m" mit geeigneter WHERE-Klausel gehen und dann auf die "Kategorie" JOINen?

• Haupt- und Unterformular sind verbunden über Master=id Child=id_stammdaten

Häh, die Verbindung lautet nicht "Stammdaten.id=Stammdaten_Kategorien.id_stammdaten"? Oder meinst Du dasselbe?

Ziel:

• Alle Kategorien im Unterformular sehen mit einem Bearbeiten-Feld daneben

OK, no prob.

• falls für den Stammdatensatz ein Wert vorhanden ist, eintragen

Also, "Stammdaten_Kategorien.Wert" befüllen in Abhängigkeit eines anderen, bisher nicht näher bezeichneten Werts aus "Stammdaten".

Das deutet dann wohl doch eher auf "Script-Logik" bzw. einer Kombination aus VBA-Logik und SQLs hin.

Weiss jetzt nicht, ob ich helfen konnte. Keine Kritik bitte, unfreundliche Postings hatte ich schon genug heute.   ;)

[Rouven]

Hello,

Ich habe jetzt nicht die Zeit darüber nachzudenken, aber warum nicht auf die "n:m" mit geeigneter WHERE-Klausel gehen und dann auf die "Kategorie" JOINen?

bin da voll bei dir - WENN das nicht Access wäre, das eigentlich für alles eine extrem komfortable Click-and-Go-Lösung hat.
Man kann ein ganzes Formular an eine Tabelle oder eine Abfrage binden. Merke: 1 Formular, 1 Quelle. Access steuert dann automatisch das Formular, d.h. zeigt je nach Ansicht alle Datensätze als Liste an, bietet vor/zurück-Schaltflächen o.ä.

Mein Ansatz, bis vor 5 Minuten war: Lade im Unterformular auf Vorrat alle Sätze die in Frage kommen (das ist der Left Join), und sobald du im Hauptformular weißt zu welchem Stammdatensatz du eigentlich was suchst, filtere. Und das scheitert halt daran, dass dieser Filter NACH dem Join und nicht IN dem Join angewendet wird.
Der Vorteil dieser Lösung wäre, dass das Subformular als solches an beliebiger Stelle genutzt werden könnte.

Das deutet dann wohl doch eher auf "Script-Logik" bzw. einer Kombination aus VBA-Logik und SQLs hin.

Hehe, na ja, hab jetzt einen anderen Ansatz, der allerdings eine fixe Verbindung zwischen Haupt- und Subformular herstellt:
man hänge an den LEFT JOIN einfach die Kriterien mit dran, also etwa
... WHERE id_kategorie IS NULL OR id_kategorie = Forms!Stammdaten!id
Das erzielt somit mal das gewünschte Ergebnis, auch wenn es mal wieder eine Lösung ist, die ich nicht schön finde. Da die Anwendung aber vorrausichtlich niemals Wartung benötigt, kann ich damit leben.

MfG
Rouven

[King^Lully]

Das erzielt somit mal das gewünschte Ergebnis, auch wenn es mal wieder eine Lösung ist, die ich nicht schön finde. Da die Anwendung aber vorrausichtlich niemals Wartung benötigt, kann ich damit leben.

Meine Erfahrungen mit "MS Access only" und "MS Forntpage+MS Access" bzw. "MS Frontpage+MS SQL Server" liegen schon fast acht Jahre zurück, aber die Kombination aus Frontpage und Access bzw. MS SQL Server war gar nicht so uncool. Da konnte man für CRUD Stored Procedures oder SQLs an Grids binden und Einzelansichten recht komfortabel hochkommen lassen, im Hintergrund frickelte sich dann Frontpage ASP zusammen.

Was ich sagen möchte ist, dass Access - richtig angewandt - durchaus das Potential hat (bzw. haben könnte ;) SW-Entwicklung brauchbar zu unterstützen. Vorsichtig wäre ich bei den "Features", und schwierig vermutlich auch die Gewöhnung an die Access-Objekte.

Deine Anforderungslage erzwang mehr oder weniger MS Access, wenn ich mich nicht täusche.

[Rouven]

Hello,

Deine Anforderungslage erzwang mehr oder weniger MS Access, wenn ich mich nicht täusche.

yes, da hast du Recht, auch wenn ich schon bei einer völlig anderen Anwendung bin als das letzte Mal...

MfG
Rouven