Tabellenfelder automatisch füllen durch zweite Tabelle

[nahpets]

Und was hast Du bei KeyFieldNames eingetragen?

List... ist für die anzuzeigenden Daten.

Wenn Du so 'nen LookupComboBox auf ein Grid setzt, dann müsste das eigentlich so funktionieren:

ListField ist die Spalte der Tabelle, aus der ausgewählt werden soll, und zwar der verbale Inhalt.

KeyField ist die Spalte der Tabelle, aus der ausgewählt werden soll, und zwar der Wert, der übernommen werden soll.

Wenn es um die Übernahme von Daten in die Tabelle Angebot geht, müsste LookupComboBox bei Dir dann auf dem Feld AngebotNr stehen.
ListSource müsste auf die Tabelle Artikel verweisen.
ListField wäre ArtikelBezeichnung.
KeyField sollte dann ArtikelNr sein.

PS:

Das hat nichts einem unglücklich gewählten Datenmodell zu tuen, es ist lediglich eine Hilfe, um die entsprechenden Fremdschlüssel in einem normalisierten Datenmodel auswählen zu können.

Es wird hier der Fremdschlüssel, der auf die andere Tabelle verweist, übernommen und nicht ein redundanter Wert.

Die Auswahl erfolgt über eine Sicht auf die Schlüsseltabelle, angezeigt wird die verbale Beschreibung.

Übernommen wird der Fremdschlüssel.

[stOrM]

Danke nahpets so funktioniert es jetzt endlich

[jobo]

Zitat von nahpets:

Das hat nichts einem unglücklich gewählten Datenmodell zu tuen, es ist lediglich eine Hilfe, um die entsprechenden Fremdschlüssel in einem normalisierten Datenmodel auswählen zu können.

Ich habe es so verstanden, dass in Angebot die Felder Bezeichnung und Nummer beide das gleiche beschreiben bzw. zum Nachschlagen nutzen, eben ein und den selben Artikel.
Daher bleibe ich bei meinen Gedanken.
Wenn das Datenmodell so in der Welt ist, okay. Dann muss man halt diese Bastelei machen, ansonsten (Entwicklungsphase) würde ich noch mal durchatmen und mir das ansehen.

[nahpets]

Die Benutzung eine TBDlookupComboBox ist nur in einem normalisierten Datenmodel zum Nachschlagen von Fremdschlüsseln sinnvoll. In der Anzeige steht halt ein Text zum Fremdschlüssel, übernommen wird der Fremdschlüssel.

Wer es anders benutzt (z. B. zum Pflegen von Redundanzen) gehört geohrfeigt
Und wer beide Werte übernimmt erst recht.

Natürlich ist Dein Gedankengang grundsätzlich erstmal richtig.

Ausnahmen davon müssen sehr genau begründet werden, derweil: Sie tendieren in der Verwendung leicht bis mittelstark in Richtung unpflegsame Systeme

[Aviator]

Zitat von p80286:

[...]
Angenommen Du hast eine Tabelle "Artikel" und Du willst ein Angebot erstellen, dann packst Du in die Angebotstabelle den Schlüssel des Artikels und gut ist
Das ist ja der Vorteil einer relationalen Datenbank, daß jedes Datum nur einmal vorgehalten wird.

Das sollte man aber mit Vorsicht genießen.

Was passiert, wenn mal die Bezeichnung des Artikels geändert wird und vorher schon diverse Rechnungen über diesen Artikel geschrieben wurden? Dann passt die Bezeichnung des Artikels nicht mehr zur ursprünglichen Rechnung/Lieferschein/Whatever wenn man sie erneut drucken wollte.

Das kann unter Umständen böse ins Auge gehen.

[nahpets]

Nein, man ändert nicht nachträglich irgendwelche Werte und will trotz Änderung noch die ursprüngliche Ausgabe bekommen.

Entweder man arbeitet mit Historien, d. h. dass man z. B. ein Datum mit abspeichert, das besagt:

Bis zum Datum A galt der Text B.
Ab Datum C gilt Text C.

Sinnvollerweise arbeitet man hier dann mit Von-Bis-Werten.

Hat man die nicht, ändert man nicht nachträglich eine Artikelbezeichnung.
Man legt dann einen neuen Artikel mit eigener ArtikelNr. ... an.

Alternativ speichert man die Inhalte von Rechnungen ab und erstellt neue Ausdrucke ... aus den abgespiecherten Daten.
Man geht aber sicherlich dann nicht her und versucht aus dem aktuellen Datenbestand historische Ausgaben zu reproduzieren.

Das wäre ja so, als müsste im heutigen Duden alle Schreibweisen der deutschen Sprache enthalten sein, um daraus auch noch Texte aus dem 19. Jahrhundert in der damals korrekten Schreibweise reproduzieren zu können. (Ok: Beispiel ist etwas überspitzt, dürfte sinngemäß aber schon (annähernd) passen).

[Aviator]

Das musst du mir nicht sagen. Unsere Software macht das so, dass die einzelnen Positionen einer Rechnung mit den zu dem Zeitpunkt gültigen Werten abspeichert. Wir haben die nicht selbst programmiert sondern greifen nur lesend auf die Datenbank zu. Deshalb kenne ich die Strukturen der Tabelle.

Mein Post war lediglich als Hinweis für den TE gedacht, dass er sich nicht unbedingt nur auf die PKs der Artikeltabelle verlassen soll.

[p80286]

Zitat von Aviator:

Was passiert, wenn mal die Bezeichnung des Artikels geändert wird und vorher schon diverse Rechnungen über diesen Artikel geschrieben wurden? Dann passt die Bezeichnung des Artikels nicht mehr zur ursprünglichen Rechnung/Lieferschein/Whatever wenn man sie erneut drucken wollte.

Das kann unter Umständen böse ins Auge gehen.

vollständig richtig!
Darum sollte dann auch gleich ein neuer Artikel angelegt werden.
Viele Konsumgüterhersteller stehen ja vor dem Problem, daß es für das gleiche Produkt(Rezeptur) mehrere Packungsgrößen und Namen gibt. Dann gibt es eben auch unterschiedliche Artikelnummern und EAN und ...
Oder aber, falls Namensänderungen öfters durchgeführt werden, dann benötigst du eben eine Namenstabelle.

Gruß
K-H