DBGrid-Feld bearbeiten und Feld mit Daten füllen

[DADAMAN]

Guten Morgen,

ich hab ein, vermutlich kleines, Problem.

Die Sache ist folgende: Ich habe ein DBGrid welches auf eine Tabelle zugreift.
Dieses Grid zeigt zwei Spalten an. Eine ArtikelNr und ein dazugehöriger Text.

Um Artikel hinzuzufügen, soll der Benutzer die ArtikelNr in die erste Spalte eintragen.
Verlässt er die Spalte, soll ein Ereignis ausgelöst werden, welches mittels der ArtikelNr, die zugehörige Bezeichnung aus einer anderen Tabelle ausliest und in die Tabelle, aus der das DBGrid die Daten bezieht, einträgt.
Danach wird die Query geschlossen und geöffnet um die aktuellen Daten anzuzeigen.

Momentan habe ich das über ein ColEnter-Ereignis gelöst. Die Query hinter dem DBGrid steht auf RequestLive und ich habe noch ein TDBNavigator-Element eingesetzt, um das hinzufügen von Datensätzen zu ermöglichen.

Funktionieren tut das ganze auch, aber eben nur einigermassen. Je nachdem in welche Spalte oder Zeile gewechselt wird, werden leere Datensätze in der Datenbank angelegt oder es führt zu Datenbankfehlern. Ausserdem ist es so nicht wirklich möglich bereits angelegte Datensätze zu überarbeiten. Zumindest nicht vernünftig.

Also alles in allem eine ziemlich klapprige Angelegenheit...

Deshalb wollte ich mal fragen ob ihr mir vielleicht weiterhelfen könnt indem ihr mir nen besseren Weg, das ganze zu lösen, aufzeigt.
Bin mir nicht sicher, vielleicht lässt es sich ja über Ereignisse des DataSets lösen, habe aber noch nicht sonderlich viel Erfahrung mit Delphi...

Wäre klasse wenn ihr mir weiterhelfen könntet.

[marabu]

Herzlich willkommen in der Delphi-PRAXiS.

Die BDE und MSSQL - Fisch und Fahrrad - zur Not geht es, aber warum nimmst du nicht die ADO-Komponenten?

Für die Einblendung von Informationen, die nicht zur selben Basistabelle gehören, kannst du auch berechnete Felder oder Lookup-Tabellen verwenden. Wenn du etwas mehr über die Struktur deiner Daten schreibst, dann ist auch konkretere Hilfe möglich.

Freundliche Grüße vom marabu

[DADAMAN]

Hi und danke

Ja, dass BDE und MSSQL nicht wirklich optimal sind, hab ich schon des öfteren gelesen, aber ich muss die beiden Sachen leider benutzen, da alle anderen Projekte hier auch schon auf diese Kombi setzen.

Mmmh, um die Struktur nochmal zu verdeutlichen. Im Prinzip dreht es sich um zwei Tabellen. Die eine enthält Artikelnummern und Bezeichnungen, die andere enthält dasselbe plus eine ID, die den Datensatz einem Protokoll zuordnet.

Die Tabelle in der die ProtokollID gespeichert ist, wird mittels einer Query, wo RequestLive auf true gesetzt ist, im angesprochenen DBGrid angezeigt.

Trägt man jetzt eine Artikelnummer in die erste Spalte ein, dann soll aus der anderen Tabelle die dazugehörige Bezeichnung ausgelesen werden und in die andere Tabelle kopiert werden.

Und das funktioniert mit dem ColEnter-Ereignis momentan eher schlecht als Recht.

Delphi-Quellcode:

if DBGrid_Komponenten.SelectedIndex = 1 then
   begin
      Datenbank.Hole_Bezeichnung.ParamByName('ArtikelNr').AsString := DBGrid_Komponenten.DataSource.DataSet.FieldByName('ArtikelNr').AsString;
      Datenbank.Hole_Bezeichnung.Open;
      DBGrid_Komponenten.SelectedField.Value := Datenbank.Hole_Bezeichnung.FieldByName('Bezeichnung').AsString;
      Datenbank.Insert_Komponente.ParamByName('ID').AsInteger := ID;
      Datenbank.Insert_Komponente.ParamByName('ArtikelNr').AsString := Datenbank.Hole_Bezeichnung.FieldByName('ArtikelNr').AsString;
      Datenbank.Insert_Komponente.ParamByName('Bezeichnung').AsString := Datenbank.Hole_Bezeichnung.FieldByName('Bezeichnung').AsString;
      Datenbank.Insert_Komponente.ExecSQL;
      Datenbank.Hole_Bezeichnung.Close;
      Datenbank.Hole_Komponenten.Close;
      Datenbank.Hole_Komponenten.Open;
   end;

Aber dir Query um das in die Datenbank einzufügen scheint eh überflüssig zu sein wenn ichs mir recht überlege, da es ja auf RequestLive steht... Irgendwie bin ich grad voll verwirrt und komm nicht weiter.

[marabu]

Eine Tabelle ARTIKEL mit den Spalten (NUMMER, BEZEICHNUNG) ist akzeptabel. Eine zweite Tabelle PROART mit den Feldern (NUMMER, BEZEICHNUNG, PROTOKOLL_ID) ist ein Modellierungsfehler, weil das Feld BEZEICHNUNG durch den Wert von NUMMER bereits determiniert ist. Wenn du also eine Tabelle PROTOKOLLE (ID, BEZEICHNUNG) hast, dann hängt es davon ab, ob die Tabellen PROTOKOLLE und ARTIKEL in einer m:n oder einer 1:n Beziehung stehen. Ich tippe auf letzteres - dann müsste deine zweite Tabelle PROART die Felder(NUMMER, PROTOKOLL_ID) aufweisen.

Wenn du genau diese zweite Tabelle in einem Grid bearbeiten möchtest, dann solltest du dem Grid einfach eine passende Query unterlegen - zweckmäßigerweise:

select * from PROART where ID = :protokoll_id Über eine Auswahlliste kannst du den Benutzer die Sicht auf ein bestimmtes Protokoll einschränken lassen, so dass nur noch die Artikel zugeordnet werden müssen (geht auch über Table mit MasterSource). Für eine visuelle Kontrolle bei manuell erfassten Artikelnummern kannst du dann noch ein lookup field definieren, welches dir die Artikel-Bezeichnung beisteuert, sobald eine Artikel-Nummer eingetragen wurde.

marabu

[DADAMAN]

Ich hoffe ich hab dich jetzt richtig verstanden.

Das mit der "Dopplung" der Daten hat einen Sinn. Und zwar soll der Benutzer, wenn er, sei es absichtlich oder zufällig, die Bezeichnung des Artikels editiert damit nicht auch die Bezeichnung in der Tabelle der anderen Datenbank editiert, sondern nur lokal, so, dass dies keine Auswirkungen auf andere Programme hat.

Für die Bearbeitung bereits eingetragener Artikelnummern habe ich jetzt zumindest schon scheinbar eine Lösung gefunden. Dies müsste über das AfterEdit Event des DataSets in Verbindung mit einer UPDATE-Anweisung ganz gut zu machen sein.

Mmmh, das AfterEdit Event müsste sich ja dann eigentlich auch für die Eingabe der Artikelnummer und auslesen der zugehörigen Bezeichnung nutzen lassen, wenn ich vorher überprüfe, ob die Bezeichnung schon "gesetzt" ist, oder?!

Ich glaub damit sollte jetzt auch mein Problem relativ deutlich geworden sein.

Kleine Zusatzfrage dazu... Kann ich einzelne Spalten auf readonly schalten? Eher nicht, oder?!

Kann im Moment leider nur nicht testen, da ein Kollege heute morgen aus Versehen meine Datenbank gelöscht hat...


EDIT: Wenn ich jeweils nach eintreten des AfterEdit Events entweder ein INSERT oder UPDATE ausführe, bringt das in Kombination mit dem RequestLive und dem TDBNavigator Probleme mit sich? Hab keinen anderen Weg gefunden automatisch neue Datensätze zu generieren, ohne den TDBNavigator.

[marabu]

Zitat von DADAMAN:

Und zwar soll der Benutzer, wenn er, sei es absichtlich oder zufällig, die Bezeichnung des Artikels editiert damit nicht auch die Bezeichnung in der Tabelle der anderen Datenbank editiert, sondern nur lokal, so, dass dies keine Auswirkungen auf andere Programme hat.

Wenn du die Bezeichnung nicht redundant speicherst, dann hast du dieses Problem überhaupt nicht.

marabu

[DADAMAN]

Zitat von marabu:

Wenn du die Bezeichnung nicht redundant speicherst, dann hast du dieses Problem überhaupt nicht.

Habe ich nicht?

Dachte eigentlich, wenn die Query hinter dem DBGrid die Komponenten ausliest und dann anhand der Artikelnummer die Bezeichnung sucht, dann kann der Benutzer doch auch, da es RequestLive ist, die Bezeichnung bearbeiten. Oder bin ich jetzt absolut auf dem Holzweg?!

Möchte das ganze eigentlich so optimal wie möglich machen also bin ich für jeden Tipp dankbar.

Achja, wäre nett, wenn du mein Edit in dem Beitrag vor dir vielleicht noch kommentieren könntest. Das würde mir enorm weiterhelfen.

[DADAMAN]

So, habe jetzt mal das AfterEdit-Event ausprobiert, aber das bringt leider auch nicht die gewünschten Resultate...

[marabu]

Eines vorweg - für jedes Feld eines Dataset kannst du die Eigenschaft ReadOnly setzen, wenn du willst. Aber ich denke das führt in die falsche Richtung.

Zitat von DADAMAN:

Dachte eigentlich, wenn die Query hinter dem DBGrid die Komponenten ausliest und dann anhand der Artikelnummer die Bezeichnung sucht, dann kann der Benutzer doch auch, da es RequestLive ist, die Bezeichnung bearbeiten.

Es fällt mir schwer hier richtig oder falsch zu antworten, da ich das E/R-Modell nicht kenne, welches deiner Datenbank zugrunde liegt. Hast du überhaupt eines erstellt?

Ich kenne aus deinen Beiträgen hier zwei Entitäten (Artikel, Protokoll). Daraus leitest du auf jedenfall zwei Basistabellen (Artikel, Protokolle) ab. Wenn jetzt jedem Artikel mehrere Protokolle zugeordnet werden können und umgekehrt, dann brauchst du eine weitere Tabelle für diesen Beziehungsdatentyp, der die Primärschlüssel der beiden Basistabellen aufnimmt und eventuell zusätzliche Attribute. Ist es aber nur so, dass einem Protokoll mehrere Artikel zugeordnet werden können, dann brauchst du keine zusätzliche Tabelle und die Tabelle Artikel wird einfach um einen Verweis auf das Protokoll (Fremdschlüssel) erweitert.

Hier musst du jetzt mal erläutern, welchen Weg wir weiter gehen wollen, damit ich nicht zu viele Fallunterscheidungen machen muss.

marabu

[DADAMAN]

Klar, ein ER-Modell existiert, ist zuhause aber leider nicht verfügbar.
Habe jetzt der Einfachheit halber mal ein kleines Bild gemalt.

Danke für deine Hilfe.