Nun wage ich zu folgern (zumindest für InterBase 7.5):
INSERTs in eine Detailtabelle, die per Foreign-Key Constraint mit einer Mastertabelle verknüpft sind, schlagen fehl, wenn am Mastersatz Änderungen gemacht wurden, für die noch kein COMMIT erfolgte
Das muss so sein (ist auch schon immer so),
sonst könntest du dein Detail nicht committen,
da der Master ja mit Rollback wieder verworfen werden könnte.
Das Insert ist im Detail, der Master wird nur in irgendeinem Feld (nicht dem PK) geändert. Daher sollte ein ROLLBACK eines Updates der Mastertabelle kein INSERT im Client blockieren.
Natürlich könnte in der selben Transaktion, die das Update im Master vornimmt, auch ein DELETE des Master-Satzes stattfinden und nach dem COMMIT der Satz für andere Transaktionen unsichtbar werden. Beim Isolationslevel READ COMITTED würde ich aber annehmen, dass erst nach dem COMMIT der Änderungen auf dem Master der Client diese sieht. Also sollte bis zum COMMIT des Masters der Client in der Lage sein ein INSERT auszuführen, da aus seiner Sicht der Master existiert.
Aber immerhin ist nun klar, wie es von InterBase 7 gehandhabt wird.
Der einzige Workaround (ausser dem etwas wackligen "so lange versuchen, bis das INSERT klappt") den ich ausprobieren könnte wäre der Verzicht auf die Foreign Key Constraint in der Detailtabelle. Mich wundert nur, dass dieses Problem nicht öfter beobachtet wird. Vielleicht gibt es zu wenige InterBase Datenbanken, in denen mit Foreign Key Constraint gearbeitet wird. Oder neuere Versionen arbeiten etwas schmerzfreier.