Tabellenfelder automatisch füllen durch zweite Tabelle

[stOrM]

Moin,
ich hab da mal ein Verständnisproblem bezüglich automatisches Ausfüllen von Feldern einer Tabelle.

Gegeben sind folgendes Tabellen (Angebot, Artikel)

Artikel
Pk, ArtikelNr, ArtikelBezeichnung, ArtikelEK, ArtikelFaktor

Angebot
PK, KD, AngebotBezeichnung, AngebotNr, AngebotMenge, AngebotFaktor, AngebotMwST, AngebotVK


Grid (cxGrid mit der Angebot Tabelle verbunden)

Jetzt würde ich gerne folgendes erreichen, sagen wir der Benutzer will einen neuen Datensatz in der Tabelle Angebote anlegen.
Nun steht er im Feld Bezeichnung (im cxGrid als Combobox definiert) die Werte der Combobox sollen aus der Artikel Tabelle stammen. Wenn nun ein Artikel ausgewählt wurde, soll das Feld “AngebotNr“ in der Angebot Tabelle, automatisch mit der ArtikelNr aus der Artikel Tabelle befüllt werden, anhand des ausgewählten Artikels.

Im umgekehrten Fall der Benutzer kennt die ArtikelNr, wählt diese aus, jetzt soll das Feld AngebotBezeichnung automatisch mit der Bezeichnung gefüllt werden die zur Nr in der Artikel Tabelle steht.
Etwas chaotisch erklärt, ich hoffe man kann mir trotzdem folgen.

Wie baut man denn so etwas auf falls das überhaupt so machbar ist?

[p80286]

Machbar ist alles....
aber was Du da treibst/treiben willst ist mir schleierhaft.
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.

Gruß
K-H

[stOrM]

Zitat:

Zitat von p80286 (Beitrag 1371031)

Machbar ist alles....
aber was Du da treibst/treiben willst ist mir schleierhaft.
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.

Gruß
K-H

Der Sinn oder der Gedanke dahinter war halt, da das Grid quasi Inplace Editoren besitzt ob ich das Grid so wie es ist direkt als Eingabemaske verwenden kann oder ob ich eine eigene Maske bauen muss. Denn Wenn jemand die Artikel Nr auswählt müsste das Grid bzw dessen Feld ArtikelBezeichnung ja anhand des selektierten Wertes der combobox updaten.
Meine Frage dazu ist halt wie machen, ich kann natürlich eine eigene Eingabemaske bauen und alles per SQL direkt lösen. Nur das wollte ich mir ersparen, da es so über das Grid direkt schneller ginge eventuell.

[p80286]

Als Datenbank affiner Mensch antworte ich
Mach was in der DB und zeige es an (Vorteil, was Du hast hast Du)
Wenn Du die Daten erst in Deiner Oberfläche zusammensetzt und dann als ganzes oder in Stückchen Deiner Datenbank vorwirfst, kann (ist aber selten) dieser Update verloren gehen (und ob das schneller ist, bezweifele ich, aber wie gesagt....)

Gruß
K-H

[hoika]

Hallo,
Ich denke nicht, dass das so einfach geht.
Aber ich verstehe, was du vorhast.

Du willst Master-Detail grafisch machen, also wie eine Lookup-Table.

Aber (2):
Die Artikel in einer ComboBox auswählen ...
Wenn ich 1.000 Artikel habe, wird das eine lustige Blätterei.


Ich würde das zu Fuss machen, bei Doppelklick auf Artikel-Spalte kommt neues Form "Artikel-Suche"
mit anständiger Suchhilfe usw.

[stOrM]

Zitat:

Zitat von hoika (Beitrag 1371036)

Hallo,
Ich denke nicht, dass das so einfach geht.
Aber ich verstehe, was du vorhast.

Du willst Master-Detail grafisch machen, also wie eine Lookup-Table.

Aber (2):
Die Artikel in einer ComboBox auswählen ...
Wenn ich 1.000 Artikel habe, wird das eine lustige Blätterei.


Ich würde das zu Fuss machen, bei Doppelklick auf Artikel-Spalte kommt neues Form "Artikel-Suche"
mit anständiger Suchhilfe usw.

Ja an so etwas hab ich gedacht. Das mit 1.000 Artikeln wäre kein Problem dank Incremental Search im Grid geht eigentlich ziemlich flott.
Ich hab nur im Moment keine Ahnung wie man das macht mit dem Grid.

[nahpets]

Prinzipiell lässt sich das mit 'ner TDBLookupComboBox lösen.

Bei Delphi 7 gibt es die, ob man sie in 'nem Grid platzieren kann, weiß ich nicht.

[stOrM]

Zitat:

Zitat von nahpets (Beitrag 1371038)

Prinzipiell lässt sich das mit 'ner TDBLookupComboBox lösen.

Bei Delphi 7 gibt es die, ob man sie in 'nem Grid platzieren kann, weiß ich nicht.

Das Grid selber hat ja sogenannte Properties in diesem können Komponenten zugewisen werden also auch eine LockupCombobox ist dort vorhanden,
dann gibt es die Felder: KeyFieldnames, ListFieldNames und ListSoruce sowie ListFieldIndex da kann ich zwar alles an eine zweite Tabelle knüpfen nur sehe ich da nicht wie ich das Feld Bezeichnung aus der ersten Tabelle damit verknüpfen soll also zusätzlich

ListFieldSource ist bei mir Tabelle2
ListFieldnames: ArtikelID

Jetzt wenn ich die Anwendung starte kann ich im Grid zwar mittels der Combobox die ArtikelID aus der Artikel Tabelle auswählen nur wird dadurch ja nicht die Bezeichnung ermittelt zu der ArtikelID. Genau das ist da wo es grad hakt.

[jobo]

Ich denke, "das Problem" liegt nicht in der Handhabung der GUI, sondern in Deinem Datenmodel.
Wenn es so ist wie im Eröffnungspost, dann verstößt es gegen die Normalisierungsregelungen. Was Du anschließend grafisch lösen möchtest (musst), ist die durch das Datenmodell erzwungene Redundanz nachzubauen. Also auf Deutsch:
"Nimm die gewählte artikelnummer und schauen in den Artikeln nach der zugehörigen Bezeichnung und trage sie neben der Artikelnummer ein (obwohl die allein schon reichen würde) oder wenn Du User lieber über den Weg der Bezeichnung geht, mache alles genauso, aber mit vertauschten Feldern, ..." uff.

Deine "schräge" Idee zur Umsetzung wäre tatsächlich so oder ähnlich zu bewerkstelligen, ist aber nur "ein Folgefehler" des unsauberen Designs der DB.

Lösung.
Du verwendest nur eines der beiden Felder, naheliegend die (Artikel)Nummer, besser noch einen echten PK dazu und baust 2 LookupComboboxen zum Suchen (eine für Nummer, eine für bezeichnung), die beide als Schlüsselfeld die Artikelnummer nutzen. Damit wäre alles erledigt.
Feinheiten kann man sicher noch klären.

Der Benefit sollte klar sein, normalisiertes Datenmodell mit allen Vorteilen, die das so mit sich bringt, inkl. fehlender "Verrenkungen" im Clientprogramm.

[jobo]

Zitat:

Zitat von stOrM (Beitrag 1371039)

Jetzt wenn ich die Anwendung starte kann ich im Grid zwar mittels der Combobox die ArtikelID aus der Artikel Tabelle auswählen nur wird dadurch ja nicht die Bezeichnung ermittelt zu der ArtikelID. Genau das ist da wo es grad hakt.

Ja, genau, siehe mein Vorschlag oben dazu.

[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 :thumb:

[jobo]

Zitat:

Zitat von nahpets (Beitrag 1371044)

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:

Zitat von p80286 (Beitrag 1371031)

[...]
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:

Zitat von Aviator (Beitrag 1371103)

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