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