Daraus ergibt sich die Frage, fliegen hier nebenläufig noch andere Anweisungen rum?
Ist das "dynamisch" generierte Statement tatsächlich korrekt? (Werden die ID verwendet (Master), die auch gewünscht sind?
Oder bestehen beim Master oder Detail Tabelle andere Abhängigkeiten in Form von Triggern oder cascading constraints, die zu diesem Problem führen (bspw. Selbstreferenz, ...)
(Quelle
http://www.firebirdfaq.org/faq109/ -hab mir nicht die Mühe gemacht, nach original
IB Doku zu suchen, ist also vielleicht irreführend, was da steht)
P.S.: Der Isolation level sollte m.E. ok sein.
Da multi-user, fliegen einige andere Anweisungen rum. Die sind in anderen Prozessen, im aktuelle Prozess laufen keine Threads o.ä. mit Datenbankzugriff. Als weitere Absicherung prüft das Programm vor dem INSERT, ob der als FK einzutragende Wert tatsächlich in der MASTER Tabelle "sichtbar" ist (existiert).
In 99,9 Prozent aller Fälle funktioniert das INSERT. Einen Fehler im Statement kann ich daher beherzt ausschliessen.
Es gibt nur einen Trigger (BEFORE INSERT) in der Detail-Tabelle. Er sorgt für einen vorhandene Primary Key in der Detail-Tabelle, und füllt ein Feld mit dem aktuellen Usernamen der Connection.
if (new.detail_pk is null) then
new.detail_pk = gen_id(gen_detail, 1);
if (new.DB_USER_NAME is null) then
new.DB_USER_NAME = user;
Da das Problem nur selten auftritt, halte ich es für wahrscheinlich dass Aktionen die in einer anderen Transaktion durchgeführt werden - z.B. der MASTER Datensatz wurde in einer anderen Transaktion geändert, aber noch nicht comitted - verantwortlich sind. Ich schaue mal ob ich etwas reproduzierbares finde.