Stringgrid oder dbgrid

[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 von Sir Rufo:

... 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?

[Luckner]

Hallo Perlsau, Sir Rufo,

ich lege neuen Auftrag an und habe erstmal keine neue ID. Die erzeuge ich erst beim Speichern. Sir Rufo, die neue ID=0 ist klar, aber was passiert wenn 2 oder mehr Anwender gleichzeitig neue Aufträge anlegen?
Luckner

[mkinzler]

Beim Speichern wird dann ein eindeutiger Schlüssel generiert

[Perlsau]

Zitat von Luckner:

... aber was passiert wenn 2 oder mehr Anwender gleichzeitig neue Aufträge anlegen?

So gleichzeitig, also auf die Millisekunde genau wird das aller Wahrscheinlichkeit nicht passieren. Wichtig ist, daß vor dem Speichern der Positionen in der DB bereits der entsprechende Auftrag mit seiner eindeutigen Id in der DB existiert, damit die Foreign-Keys der Positionen-Tabelle nicht ins Nirwana zeigen und somit die Daten-Integrität gewahrt bleibt.

[Sir Rufo]

Zitat von Perlsau:

Zitat von Sir Rufo:

... 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?

Damit die AuftragsID erst dann erzeugt wird, wenn der komplette Auftrag gespeichert wird - also so wie gefordert.

Zitat von Perlsau:

Zitat von Luckner:

... aber was passiert wenn 2 oder mehr Anwender gleichzeitig neue Aufträge anlegen?

So gleichzeitig, also auf die Millisekunde genau wird das aller Wahrscheinlichkeit nicht passieren. Wichtig ist, daß vor dem Speichern der Positionen in der DB bereits der entsprechende Auftrag mit seiner eindeutigen Id in der DB existiert, damit die Foreign-Keys der Positionen-Tabelle nicht ins Nirwana zeigen und somit die Daten-Integrität gewahrt bleibt.

Immer wenn du denkst, das ist unwahrscheinlich, hast du nach spätestens einem Tag die Erkenntnis, dass es doch wahrscheinlich ist.

Und weil dem so ist, haben die Datenbank-System-Hersteller darauf geachtet, dass eine ID gesichert nur einmal vergeben wird. Darum braucht man sich eben keine Sorgen machen, da kann man auch eine Million Datensätze im exakt gleichen Zeitpunkt in der gleichen Tabelle der gleichen Datenbank erzeugen - aber nicht wundern, dass es etwas dauert, denn der Server verarbeitet diese gleichzeitigen Anfragen nacheinander

[Perlsau]

Zitat von Sir Rufo:

Zitat von Perlsau:

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

Damit die AuftragsID erst dann erzeugt wird, wenn der komplette Auftrag gespeichert wird - also so wie gefordert.

Inwieweit ist das wichtig und wer fordert das? Meintest du etwa das:

Luckner: "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."

Wenn ja, worin besteht dieser Vorteil? Ob du jetzt als erstes die Auftragsdaten eingibst (Kunde, Datum, Verkäufer etc.) und den Auftrag anlegst, bevor du die Positionen abspeicherst, oder ob du das alles erst virtuell machst, um es dann als Ganzes zu speichern, bleibt sich doch gleich. Wenn du natürlich Hunderte oder mehr Fakturisten hast, die den ganzen Tag nichts anderes machen als Aufträge einzugeben, und das auch noch auf einem entfernten Server, wäre es natürlich, um Übertragungs-Ressourcen zu schonen, schon von Vorteil, nicht mehrere Transaktionen pro Auftrag ausführen zu müssen oder sogar mehrere Aufträge in einer Transaktion unterzubringen.

Zitat von Sir Rufo:

Zitat von Perlsau:

So gleichzeitig, also auf die Millisekunde genau wird das aller Wahrscheinlichkeit nicht passieren. Wichtig ist, daß vor dem Speichern der Positionen in der DB bereits der entsprechende Auftrag mit seiner eindeutigen Id in der DB existiert, damit die Foreign-Keys der Positionen-Tabelle nicht ins Nirwana zeigen und somit die Daten-Integrität gewahrt bleibt.

Immer wenn du denkst, das ist unwahrscheinlich, hast du nach spätestens einem Tag die Erkenntnis, dass es doch wahrscheinlich ist.

Also das kann ich mir nun beim besten Willen nicht vorstellen, daß ständig Leute zur selben Millisekunde ein und denselben Generator dazu auffordern, eine neue Id zu erzeugen.

Zitat von Sir Rufo:

Und weil dem so ist, haben die Datenbank-System-Hersteller darauf geachtet, dass eine ID gesichert nur einmal vergeben wird. Darum braucht man sich eben keine Sorgen machen, da kann man auch eine Million Datensätze im exakt gleichen Zeitpunkt in der gleichen Tabelle der gleichen Datenbank erzeugen - aber nicht wundern, dass es etwas dauert, denn der Server verarbeitet diese gleichzeitigen Anfragen nacheinander

Genau: Sogar wenn es tatsächlich einmal vorkommen sollte, daß zwei Fakturisten absolut gleichzeitig die Entertaste drücken, um einen neuen Auftrag anzulegen, und die beiden Transaktionen dann auch noch gleichzeitig auf die Millisekunde genau beim Server eintreffen, wird sich der Server für einen von beiden entscheiden, um ihn als erstes zu bearbeiten bzw. einzutragen. Ansonsten wäre das DBMS Mist.

[Sir Rufo]

Was würde mir ein Auftrag auf dem Server bringen, wo nur der Kopf besteht aber noch keine Positionen?
Oder willst du die Transaktion so lange offen halten, bis alle Positionen drin sind?

Und dann wird der Auftrag abgebrochen und der Datensatz muss gelöscht werden (oder storniert, was aber irgendwie nicht der Wahrheit ganz entspricht, denn der Auftrag ist nie zustande gekommen).

Oder die Anwendung stürtzt ab, Strom fällt aus, etc.

Dann doch lieber alles in einem Rutsch (eine Transaktion) wenn fertig in die Datenbank schreiben. Dann braucht man auch nicht aufräumen, weil man es niemals durcheinander gebracht hat.

Das ist auch der Weg um den Auftrag wieder zu bearbeiten. Alles einlesen, bearbeiten und dann alle Änderungen in einem Rutsch wieder zurück in die Datenbank. Und so ein ClientDataSet bringt dafür schon alles von Haus aus mit.

[Perlsau]

Danke

Das hab ich jetzt verstanden