FIBPlus, Master/Detail und ForeignKeys

[nachti1505]

Hallo liebe Community,

folgende zwei Tabellen zum Rechnungshandling.

Code:

Rechnung
  id INT64
  datum TIMESTAMP

Rechnungsposition
  id INT64
  rechnung INT64
  bezeichnung VARCHAR(30)

Im DataFormular habe ich nun zwei TpFIBDataset, welche per Master-Detail-Beziehung verbunden sind. Das Anlegen einer Rechnung geschieht nun folgendermaßen:

1. TRechnungDataset.Insert;
( das TDataset ist so konfiguriert, dass bei Ausführen von Insert eine neue ID aus einer Sequence geholt wird und intern schon dem keyfield id zugewiesen wird)
2a. Positionen hinzufügen mit TRechnungPositonDataset.Insert
2b. Durch die MasterDetail-Beziehung wird das Feld rechnung in der Position jetzt mit der ID aus dem Master befüllt
2c. TRechnungPositionDataset.Post
3. TRechnungDataset.Post

Hierbei kann man Schritt (2) beliebig oft wiederholen.

Das ganze funktioniert auch wunderbar - BIS man in der Datenbank eine referentielle Integrität zwischen dem Feld Rechnungsposition.Rechnung und dem Feld Rechnung.Id herstellen möchte. Dann knallt es im Punkt 2c - da die Mastertabelle noch gar nicht gepostet wurde.

Wie würde man den workflow oben designen müssen, um referentielle Integrität nutzen zu können?

[mkinzler]

Befinden sich die beiden DataSets im selben Transaktionskontext?

[nachti1505]

Ja. Das ist es ja, was mich wundert. Anscheinend findet die Integritätsprüfung beim Post statt und nicht erst beim Commit.

[jobo]

Das ist eigentlich normal. Anderes Verhalten wird über die Art des Ref.Constraint definiert, hängt von den Möglichkeiten der DB ab.

Du muss eigentlich nur dafür sorgen, dass der Masterrecord auch gepostet wird, bevor der 1. Detaildatensatz angelegt (oder spätestens gepostet) wird.

Das ist sowieso sinnvoll, da bei der Be/Ver-arbeitung der Detaildatensätze u.U. weitere Constraints oder Regeln greifen können, die mit dem Masterrecord in Zusammenhang stehen.
Es wäre ohne weiteres denkbar, dass der aktuelle, nicht gepostete DS einen DB Constraint verletzt. Würde man das System dazu bringen, auf Basis des ungeposteten Satzes einen, mehrere oder viele Detaildatensätze anzulegen, die am Ende beim Commit dann alle hinfällig sind, weil der Masterrecord nicht eingetragen werden kann, wäre das ärgerlich.

Ein Commit macht, kontrolliert, steuert oder prüft gar nichts. Es schreibt die transaktionalen Änderungen einfach nur fest.