Wie hast Du denn die Procudure aufgebaut?
Die Procedure hat den Sinn, die Trigger (weitgehend) zu ersetzen, also eine dedizierte Insert Proc, die alles regelt, alles bis auf meinetwegen Erzeugung der ID des PK. Jedenfalls würde die Proc naturgemäß eine Aufgabe erledigen, hier insert. Deine Trigger bedienen aber mehrere Aufgaben...
Wie ist das umgesetzt?
Hab mir die Trigger noch mal angeschaut. Diesmal sind mir die POSITION Angaben aufgefallen, die mehrmals mehrdeutig sind. Wie sich
fb verhält, wenn POSITION mehrdeutig ist, aber für unterschiedliche Mutation Types, weiß ich nicht. Das bedeutet aber vielleicht, das Feuern der Trigger ist in der Reihenfolge mehr oder weniger undefiniert, also zufällig. In der Praxis wäre das ein möglicher Grenzwertfall. Zufällig bedeutet ja nicht, dass es jedesmal anders läuft, bunt durcheinander (und Du schon nach wenigen Inserts über falsche Ergebnisse gestolpert wärst, weil die innere Abhängigkeit der Insert Logik verletzt wird), sondern immer nach dem gleichen, undefinierten Schema (das sich durch interne Algorithmen ergibt) bis ein Kipppunkt (wegen Laufzeit, ..) erreicht ist und die Trigger in anderer Reihenfolge zünden.
Ggf. könntest du in einem funktionierenden (kleinen) System die Trigger so erweitern, dass sie alle ihren Namen und einen fortlaufenden Sequenzwert in eine separate Tabelle eintragen. Diese (funktionierende) Reihenfolge dann über die POSITION Angabe richtig festnageln und auf das große System übertragen (oder wenigstens vergleichen, wie es sich im großen System verhält).
Vielleicht kann man das aber auch einfacher per Trace
API feststellen.
Oder mal die SP zeigen (mit den übrig gebliebenen Triggern)
Den Hinweis zur (expliziten) Start/End Transaction finde ich auch wichtig, bei einem einzelnen Insert oder bei einem Einzelnen Aufruf einer Insert Proc ist das nicht notwendig (und meistens kontraproduktiv), da es implizit
DB-seitig erfolgt.