Mehrere Datensätze zwischenspeichern

[Luckner]

Hallo,
programmiere eine kleine Auftragsverwaltung. Habe eine Tabelle mit Artikeln(Artikelstamm), eine Tabelle mit Hauptauftragsdaten (ID, Auftragsnr, Datum, Kunde usw.) und eine Tabelle mit mehreren Positionen in die die Artikel aus dem Artikelstamm, ggf. mit Änderungen gespeichert werden sollen. Diese Positionstabelle ist mit der Auftrags_ID bzw. Auftragsnr. mit den Hauptauftragsdaten verknüpft. Da ich nicht mit DBFeldern auf die entsprechenden Tabellen zugreife, sondern mit den Standard-Komponenten (TEdit usw.) erzeuge ich einen neuen Datensatz erst beim Speichern des Auftrages. Da ich jedoch die einzelnen Positionen des Auftrages irgendwo zwischenspeichern muss, fehlt mir jedesmal die AuftragsID, die erst nach dem Speichern des Gesamtauftrages generiert wird. Es sollen natürlich mehrere Anwender gleichzeitg Aufträge anlegen. Gibt es eine Möglichkeit eine Temporäre Tabelle(Komponente) zu erstellen und die Positionen bis dahin zwischenspeichern und nach dem Speichern des Autrages, zu leeren? Ich hoffe, dass ich mich irgendwie verständlich machen konnte.

Danke und Gruß,
Luckner

[Olli73]

Du könntest alles in eine Transaktion packen und dann direkt eintragen und posten (ohne Commit!). Beim speichern machst du dann Commit, sonst Rollback.

[p80286]

Wofür soll das gut sein?
Du willst einen Auftrag erstellen --> der Autragsdatensatz wird angelegt (Status:Entwurf)
Du erfasst die notwendigen Daten, hast noch ein paar Rückfragen, nach 2 Stunden werden die Auftragsdaten weggeschrieben --> (Status: Bereit)
Am nächsten Morgen kommt noch eine Ergänzung dazu (Status:Bereit) und dann schickst Du den Auftrag los (Status:Erteilt) oder aber Du löschst ihn, weil sich jemand einen Scherz mit Dir erlaubt hat (Status:Storniert)

Gruß
K-H

[mkinzler]

Einfach AuftragsNr von PK trennen. Beim Anlegen wird Masterdatensatz ohne AuftragsNr erzeugt und die Positionen nicht mit der AuftragsNr sondern über dem (synthetischen) Primärschlüssel verknüpfen.

[Blup]

Verknüpft werden Tabellen untereinander mit einer für den Anwender unsichtbaren ID. Die Reihenfolge IDs müssen deshalb nicht fortlaufend sein, nur eindeutig. Die ID kann man sofort erzeugen und die Auftragsdaten als Entwurf abspeichern.

Die Auftragsnummer wird erst erzeugt, wenn aus dem Entwurf ein Auftrag wird.

[himitsu]

Oder CachedUpdate bei den Positionsdaten aktivieren, wenn der Hauptdatensatz noch nicht existiert.

Dann erst den Hauptdatensatz speichern,
nochmal alle Positionen durchgehen die PK eintragen
und zum Schluß das Commit der Positionen und CachedUpdate abschalten.


Alternativ:
Wir holen im AfterInsert die DefaultWerte von der DB und füllen damit das DataSet auf.
Der Benutzer sieht sofort was die DB nach dem POST als DEFAULT überall eingetratragen hätte und du hast auch sofort eine PK, auch bei mehreren Nutzern.
(nur beim Cancel bleibt dann natürlich eine Lücke in den PKs und anderen AutoInc-Feldern)

[p80286]

@mkinzler @Blup
saubere Lösung, nur müßte dann irgendwann mal jemand die Auftragszombies (IDs ohne Nummer) entsorgen

Gruß
K-H

[haentschman]

Moin...
Die Lösung sind Objekte. Die Auftragsklasse enthällt die kompletten Daten. Der Auftrag wird in einer Objektliste gehalten. Wenn der Auftrag gespeichert werden soll, werden die Daten auf die verschiedenen Tabellen aufgeteilt (in der procedure "SaveOrder") und in der DB gespeichert. Die Löschung eines Auftragen erfolgt über die Objektliste. Die ID wird nur generiert wenn du die Order wirklich abschickst.

Nachteil: Du mußt dich von dem üblichen Datenbankzugriff (DB Controls) und der Datenhaltung in Querys trennen.

Pseudocode:

Delphi-Quellcode:

TArticle = class
  ...
end;
.
TOrder = class
private
  FArticleList: TObjectlist; // besser mit Generics: TObjectlist<TArticle>
...
public
  procedure AddArticle; // oder direkt in die Liste schreiben
end;
.
procedure SaveOrder;
begin
  // TOrder auf die Tabellen aufteilen mit mehreren SQL -> in einer Transaktion abschicken
end;

[Jasocul]

Zitat von haentschman:

Die Lösung sind Objekte.

Theoretisch ja, praktisch Nein. (Natürlich ist es richtig, GUI und Daten zu trennen, aber darum geht es hier ja nicht.)
Auftrags-Positionen erfordern oft, dass Bestände reserviert werden müssen, damit andere Erfasser den Bestand nicht ins Minus fahren.
Das kann man sicher auch lösen, aber wozu? Es sind in jedem Fall DB-Zugriffe notwendig. Dann kann man auch gleich den Auftrag speichern und bastelt sich keinen Zwitter.
Abgesehen davon möchte ich nicht das Geschrei eines Anwenders sehen, der einen großen Auftrag bereits 2 Stunden erfasst und dann das Programm oder Rechner abschmiert. Alles nochmal Erfassen? Scheiß Programm

Fortlaufende Auftragsnummern sind doch kein Problem. Stornierte Aufträge sind auch wichtige Infos (z.B. für das Qualitätsmanagement). Ansonsten kann man einen Auftrag auch einfach inhaltlich komplett wieder ändern/leeren. Dann steht die Nummer wieder zur Verfügung. Oder man lässt eine manuelle Korrektur der Auftragsnummer zu. Die Prüfung im Programm ist doch Kleinkram. Rechtlich sind fortlaufende Nummern nur für Rechnungen und Gutschriften relevant.

[Hobbycoder]

Ich mache das immer so:

Da die Vorgansnummern immer fortlaufend sein soll (bei Aufträgen nicht zwangsläufig, bei Rechnungen aber definitiv) lege ich mir also eine Tabelle für die Nummernkreise an (vonNr, bisNr, istNr).
Aber eben nicht die Nummern für Rechnung, Auftrag, etc. sondern auch für Rechnungsentwurf, Auftragsentwurf, usw.
Bei erstellen eines Auftrags/Rechnung erhält dieser also erst einmal die nächste Nummer aus dem jeweiligen Entwurfsnummernkreis und erhöht dessen istNr.
Erst bei Fakturierung/Auftragerteilung wird für diesen Vorgang dann eine Nummer auf dem eigentlichen Nummernkreis gezogen und ausgetauscht.

Da die Nummernkreise aber in meinen Fällen umlaufend sind, werden die eigentlichen Datensätze / Positionen