STProcedure und deadlock

[hanspeter]

Hallo,

ich habe ab und an einen unerklärlichen Deadlock in einer FB Datenbank und vermute, das sich hier eine
Stored Procedure "selbst überholt".

Die Datenbank ist im Sport eingesetzt.
Hier wird z.B. nach dem Ende einer Prüfung Gewinngeld zugeordnet und alle Teilnehmer mit einem Startgeld
belastet.

Ein Trigger veranlasst, das bei Betragsänderungen auf einem dieser Posten, eine Stored Procedure den Saldo ermittelt und dem Teilnehmer zuordnet.

Wenn ich beispielsweise den Gewinn einer Prüfung löschen will, dann reicht dazu ein

UPDATE tbl_START SET GEWINN=0 WHERE PRUEFUNG=1 Jetzt wird die SP n mal aktiviert (z.B. 50 mal).

Mir ist nicht ganz klar, wann der Trigger aktiv wird und ob eine Updateanweisung auf das Ende der Stored Procedure/Trigger
wartet. Sofort bei Update oder bei Commit)

Sonst kann es jetzt wohl vorkommen , das ein Commit erfolgt, wärend in der DB die Berechnung noch läuft.

Hier scheint es ab und an zu einem Fehler zu kommen.

Ist der Weg der getriggerten Berechnung in diesem Fall richtig
oder sollte hier lieber eine rein programmtechnische Lösung gewählt werde?

Gruß
Peter

[Union]

Mir fällt hier nur auf, dass die Bedingung durch das SQL nicht zurückgesetzt wird:
UPDATE tbl_START SET GEWINN=0 WHERE PRUEFUNG=1 Wäre es nicht besser so:
UPDATE tbl_START SET GEWINN=0, PRUEFUNG=0 WHERE PRUEFUNG=1

[hanspeter]

Zitat von Union:

Mir fällt hier nur auf, dass die Bedingung durch das SQL nicht zurückgesetzt wird:
UPDATE tbl_START SET GEWINN=0 WHERE PRUEFUNG=1 Wäre es nicht besser so:
UPDATE tbl_START SET GEWINN=0, PRUEFUNG=0 WHERE PRUEFUNG=1

Nein Pruefung ist die Nummer der Pruefung und Primary key.

[Union]

Aha, es war nicht erkennbar dass es sich hierbei um einen Parameter handelt, sah mir aus wie eine Konstante.