Stringgrid oder dbgrid

[Luckner]

Hallo,
habe eine Form1 "Auftrag" mit einigen Editfeldern, wie Name, Adresse usw. (keine DBEdits). Zugriff auf die Tabelle über ein Dataset. Soweit kein Problem. Im Auftragsformular gibt es ein oder mehrere Positionen. Ebenfalls alles Editfelder. Die Übersicht über die Positionen möchte ich in einem Grid darstellen. Die Positionen haben eine eigene Tabelle mit einem Verweis auf die AuftragsID. Die Editfelder möchte ich haben, weil ich erst beim Speichern des Auftrages ein neue AuftragsID generieren möchte. Probleme habe ich mit den Grids. Der Vorteil von einem Stringgrid ist, dass ich die Zellen füttern kann und erst beim Speichern des Auftrages die Positionen in die Datenbanktabelle schreibe. Leider ist ein Stringgrid, so in Delphi7, blöd mit den verschieden Zellenformatierungen. Alles muß man da selbst Programmieren. Die andere Möglichkeit, die ich ausprobiert habe ist eine JediDBGrid einzusetzen. Da lassen sich schon verschiedene Spaltenformatierungen vornehmen. Da aber dieses Grid mit der Tabelle verbunden ist, müßte ich, so denke ich, mit einer temporären Tabelle und DBGrid arbeiten.
Ich weiß nicht, ob ich das jetzt so verständlich erklärt habe, aber möglicherweise habt Ihr eine Standardweg, wie man in einer Auftragsverwaltung so vorgeht. Über jede Anregung wäre ich dankbar.

Danke, Luckner

[Blup]

Zitat:

Zitat von Luckner (Beitrag 1294060)

Die Editfelder möchte ich haben, weil ich erst beim Speichern des Auftrages ein neue AuftragsID generieren möchte.

Eine ID wird vergeben, sobald man diese benötigt und im normalen Anwendungsverlauf niemals verändert.
Unter keinen Umständen sollte diese jemals für den Anwender sichtbar sein.
Damit ist egal ob man dafür Integer, Int64 oder GOID als Datentyp wählt, sie müssen auch nicht fortlaufend vergeben werden, aber sie müssen eindeutig sein.

Für den Anwender gibts Auftragsnummer, Kundennummer, Belegnummer usw. über die er die Objekte im Programm finden und identifizieren kann.
Damit ist dein Wunsch eigentlich unsinnig.

[Luckner]

Hallo Blub,
es ist nicht so das Problem. Die ID's sind für den Anwender nicht sichtbar und erzeugt werden sie von einem Generator. Möchte jedoch den Generator nicht unnötig hochschaukeln, wenn der Anwender, während des Auftraganlegens, mal eine oder mehrere Positionen wieder löscht. Und das im Netzwerk mit mehreren Anwendern. Möchte mit den ID's und Generatorwerten möglichst sparsam umgehen.

Luckner

[DeddyH]

Wen interessiert denn der Wert eines Generators/einer ID?

[TRomano]

Und wenn der Generator auch noch ein Int64 ist, dann dauert´s bis er "erschöpft" ist ... Ich gehe mal davon aus, dass Du einen Generator in der DB oder eine Sequence in selbiger meinst.
Aber Spaß beiseite. Wenn es wirklich TEdit-Felder sind, dann verstehe ich die Fragestellung nicht so wirklich. Zu dem Zeitpunkt besteht doch noch kein Bezug zur DB !
Erst wenn der User "Speichern" drückt, kann man entweder über ein SQL-Statement ("INSERT INTO ...") einfügen oder man übernimmt die Werte nach einem Dataset.Insert mit
DataSet.FieldByName(..).As.. := TEdit ... mit anschließendem DataSet.Post !

Gruß Thomas

[Perlsau]

@Luckner:

Firebird erzeugt eine Id für einen neuen Record automatisch, wenn man das beim Erstellen der Tabelle angegeben hat: Im IbExpert beim Erstellen des Id-Feldes einfach die CheckBox AI im Feldeditor anklicken, danach erscheint eine Dialogbox, in der du Generator, Procedure und Trigger erstellst. Voreingestellt ist der Trigger auf BeforeInsert, du kannst aber auch AfterInsert wählen, was aber nicht ratsam und auch nicht notwendig ist. Meiner Erfahrung nach wird ein erzeugter Generatorwert wieder gelöscht, wenn auf ein Append ein Cancel folgt, wenn du also den neu erzeugten Record verworfen hast. Beim Löschen von Records stellt der Generator den gelöschten Id-Wert natürlich nicht mehr zur Verfügung, da er einfach nur hochzählt (incrementiert).

Dein Sparsamkeitsgedanke hinsichtlich der Generatorwerte ist völlig sinn- und zwecklos. Du wirst wohl kaum die Anzahl der Aufträge erreichen, um hier auch nur bei Integer (über 4 Milliarden Aufträge) an die Grenze zu kommen, bei BigInt schon gar nicht – es sei denn, deine Lebenserwartung beträgt das Vielfache des Durchschnittsmenschen, so ein paar tausend Jahre würdest du wohl brauchen :lol:

Firebird-Datentypen

Dein Problem mit dem DBGrid und der angeblich notwendigen temporären Tabelle habe ich nicht wirklich verstanden. Aber ich versuch's mal:

Wenn du via DBGrid eine Tabelle anzeigen läßt, du aber die einzelnen Felder in Edits bearbeiten willst, mußt du selbst dafür sorgen, daß der Anwender eben nur in den Edits arbeiten kann. Dazu versetzt du das DBGrid vor dem Bearbeiten in den Disabled-Mode (MyDBGrid.Enabled := False), nach Post oder Cancel wieder Enabled := True. Die Editfelder setzt du für gewöhnlich auf ReadOnly := True, das Grid ebenfalls. Im Edit-Modus setzt du die Editfelder auf ReadOnly := False.

Sollte das DBGrid die Änderungen nicht automatisch übernehmen, kannst du mit einem MyQuery.Refresh nachhelfen. Befinden sich in deiner Tabelle ForeignKeys, die auf Einträge in Subtabellen verweisen, verwendest du für das DBGrid ein View und stellst in dessen AfterScroll-Behandlung sicher, daß ein Scrollen im View stets den jeweiligen Record in der Ursprungstabelle selektiert.

[Luckner]

Habe mich etwas falsch ausgedrückt. Die Editfelder werden aus der Tabelle direckt gefüttert. Das Grid ist nur für die Anzeige der Positionen. Erst ein Doppelklick auf das Grid (Zeile) öffnet ein Panel mit den Edit's. In dieser Zeit ist das Grid ausgeblendet. Meine Vorstellung ist, die Neuanlage eines Auftrages, wird einen temporäre Tabelle erstellt (Zugriff über ein Dataset), die Positionen dieses Auftrages werden eingetragen bzw. gelöscht und in diesem Auftrag auch dargestellt (im Grid als Tabelle) und dann beim Speichern des Auftrages in die tatsächliche Tabelle übernommen. Aschliessend TempTabelle in der Datenbank gelöscht. Weil ich beim Erstellen eines neuen Auftrages keinen neuen Generatorwert erzeuge (erst beim Speichern), habe ich das Problem nach dem Posten und Open auf die Orginal-Positionstabelle, alle bereits eingetragenen Positionen zu sehen, weil mein select * where auftragsid = ? nicht funktioniert.
Ist das schwer zu erklären, aber ich hoffe, das es jetzt einigermassen geklappt hat.

Luckner

[Perlsau]

Also du hast einen Auftrag mit diversen Positionen (Waren, Dienstleistungen etc.). Du legst einen Auftrag neu an und erhältst dadurch eine Auftrags-Id. Danach legst du zu diesem Auftrag die benötigten Positionen an. Wozu du da eine temporäre Tabelle benötigst, erschließt sich mir nicht.

Ich würde das Konzept, das du da umzusetzen im Begriff stehst, noch einmal überdenken. Wenn du einen Auftrag in einer temporären Tabelle anlegst, weißt du die Id, die dieser Auftrag dann in der regulären Tabelle haben wird, immer noch nicht. Deshalb legst du den Auftrag gleich in der regulären Tabelle an und merkst dir die vergebene Id. Erst wenn der Auftrag angelegt ist, erstellst du dessen Positionen mit der gemerkten Auftrags-Id.

Deine Positionen-Tabelle beinhaltet im günstigsten Fall einen PK, der eine AutoInc-Id beherbergt, und ein Feld AuftragsId, das die Position dem jeweiligen Auftrag zuordnet. Beim Scrollen der Autrags-Tabelle setzt du dann immer gleich einen Filter auf die Positionen-Tabelle, um so nur die Positionen des aktuellen Auftrags anzuzeigen. So macht man das gewöhnlich.

Ich verstehe dein Problem nur insoweit, als du ein etwas merkwürdiges Datenbank- und Anwendungs-Konzept beschreibst :?

[Sir Rufo]

Man nehme ein ClientDataSet für die Kopfdaten und eine ClientDataSet für die Positionsdaten (jede beliebige InMemory-Tabelle geht natürlich auch).

Die Auftrags-ID ist bei einem neuen Auftrag erstmal 0.

Man füllt den Kopf und die Positionen und beim Speichern schreibt man erst den Kopf, bekommt die ID und speichert alle Positionen mit der eben erhaltenen AuftragsID.

Alles natürlich innerhalb einer Transaktion.

[Perlsau]

Zitat:

Zitat von Sir Rufo (Beitrag 1294104)

... beim Speichern schreibt man erst den Kopf, bekommt die ID und speichert alle Positionen mit der eben erhaltenen AuftragsID.

Wozu aber dann aber erst die temporären Tabellen in ClientDatasets? Damit man alles mit einer Transaktion übertragen kann?