Firebird 3.0 in einer SP (Multiuser-Umfeld) ein Wert ändern

[Kostas]

Vielen Dank für die Antworten,

das klingt alles richtig kompliziert.
Eigentlich habe ich nach einer Konstruktion gehofft, die vor dem Update prüfen kann ob der Record, beschreibbar ist. Wenn nicht, selbständig warten bis er beschreibbar ist und fertig. In diesem speziellen Fall ist der einzige Initiator der die ChargenNr schreibt diese eine einzige SP. Das Problem ist nur, diese SP kann von zwei Client gleichzeitig aufgerufen werden und so den deadlock produzieren. In meiner SP mit dem auslesen, upadten, wieder auslesen und vergleichen ist eigentlich alles Mist. Ist nur aus Verzweiflung entstanden.

@Holger: Es sind mehrere tausend Artikel die jeweils eine eigene ChargenNr die NUR fortlaufend ist, haben. Die Tabelle Chargen ist absichtlich 1:1 über den PK und ohne FK des Artikels und beinhaltet NUR die ChargenNr sonst nichts, damit der Record mit der ChargenNr beschrieben werden kann unabhängig vom Artikel möglichst ohne deadlock. Sobald ein Artikel angelegt wird, wird der Record in Chargen angelegt mir ChargenNr = null.
Dein Vorschlag mit der zusätzlichen Tabelle die für jeden Artikel mehrere Chargennummer vorhalten soll habe ich nicht verstanden. Vermutlich passt das auch nicht zu meinem Fall. Leider habe ich das nicht gleich erwähnt und habe dich möglicherweise in die Irre geführt, sorry dafür. Ich dachte so eine "Warten" Konstruktion gibt es, nur ich kenne sie nicht.

Wichtig ist, ich habe keine Möglichkeit im Client irgend etwas zu verändern da es fremde Maschinensteuerungen sind. Ich kann also keine Exception im Client abfangen. Es muss alles in der SP passieren und die SP muss durchlaufen und die nächste gespeicherte ChargenNr ausgeben. Das beste währe gewesen, ich hätte für jeden Artikel einen Generator angelegt. Da es viele tausend Artikel sind wollte ich dafür die Generatoren nicht missbrauchen.

Gruß Kostas

[IBExpert]

du kannst mit einer wait transaction auch warten, hängt von den DB Komponenten ab, wo du das wie einstellst.
das blockt aber nur so lange bis klar ist ob die konkurrierende deadlock transaction committed ist, weil du in dem
fall erst dann die exception bekommst, die du auch bei nowait direkt bekommen hättest. nur bei rollback der konkurrierenden
deadlock transaction ginge es bei dir ohne exception weiter. Wenn die andere Transaktion aber warum auch immer stundenlang
dauert, dann wird es bei wait auch stundelang nicht weitergehen, daher eignet sich der ansatz nur selten.

Das Verfahren das ich dir geschildert hat ist 100% deadlock sicher und sorgt für eindeutigkeit schon in der db, du kannst das
aus einem trigger heraus machen oder vom client oder wo aus immer.

Im Rahmen unserer Hotlinepaket kann man so was auch mit meiner Hilfe per remote Session direkt in die db einbauen lassen
und sich dabei erklären lassen, das das überhaupt nicht kompliziert ist und das nachher auch selber so sieht