Mehrere Datensätze zwischenspeichern

[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

[Frickler]

Zitat von haentschman:

Die Löschung eines Auftragen erfolgt über die Objektliste.

Was enthält denn diese famose Objektliste? Alle Aufträge? Nur die von mit neu erfassten und/oder geänderten? Alle, die ich (in dieser Sitzung) mal angeschaut habe? Wie wird die Liste synchronisiert, wenn jemand anders einen Datensatz ändert?

[Jumpy]

Zitat von Frickler:

Zitat von haentschman:

Die Löschung eines Auftragen erfolgt über die Objektliste.

Was enthält denn diese famose Objektliste? Alle Aufträge? Nur die von mit neu erfassten und/oder geänderten? Alle, die ich (in dieser Sitzung) mal angeschaut habe? Wie wird die Liste synchronisiert, wenn jemand anders einen Datensatz ändert?

Ist doch egal! Ob nun Objektliste oder ClientDataset oder sonstwas. Wenn du die Daten einmal geholt hast kriegst du nicht mit wenn jemand anderes daran rumwerkelt... Es sei denn du kümmerst dich da auf irgendeine Art drum. Da ist die Objektliste nicht schlechter und nicht besser als anderes.