Firebird: Datensatz wird nicht gefunden, obwohl er da ist

[MichaelT]

Das Datenmodell sagt dazu klar nein.

Allein wenn du die alte Rechnung rauslöscht während sie auf der GUI angezeigt wird tritt der Fehler auf. Das AutoCommit sorgt dafür.

Offensichtlich wird die Rechnung angelegt ohne ErsetztRgNr. Dann die alte Rechnung löschen und die zu ersetzende Rechnung manuell eintragen? Klingt verwegen. Die werden die ersetzt die Rechnung nicht mit der Hand reinpfrimmeln :-D

Wohl aber kann man über 2 Sessions arbeiten, bspw. das Programm 2 Mal starten, in einem die Verlinkung auf der GUI herstellen und den alten Satz noch kurz vor dem Post rauslöschen. Den hat die Sperre vermutlich mal nicht im Visier. Ein allfälliger Dialog ist zu dem Zeitpunkt schon geschlossen.

Allein für den Fall, dass du den alten Datensatz rauslöscht in einer Session (nicht commitest) und in der zweiten die Verbindung über den Foreign Key versuchst herzustellen kommt die Meldung mit dem Deadlock.

Zitat:

Zitat von hoika (Beitrag 1397484)

Hallo,
ALTER TABLE Rechnungen ADD CONSTRAINT FK_Rechnungen_1 FOREIGN KEY (ErsetztRgNr) REFERENCES Rechnungen (RgNr);

ErsetztRgNr zeigt also auf ein in der Tabelle Rechnungen vorhandene RgNr.
Kann das sein, dass "ersetzt" heißt, dass die alte Rechnung gelöscht wird?

[BlueStarHH]

Zitat:

Zitat von hoika (Beitrag 1397484)

Hallo,
ALTER TABLE Rechnungen ADD CONSTRAINT FK_Rechnungen_1 FOREIGN KEY (ErsetztRgNr) REFERENCES Rechnungen (RgNr);

ErsetztRgNr zeigt also auf ein in der Tabelle Rechnungen vorhandene RgNr.
Kann das sein, dass "ersetzt" heißt, dass die alte Rechnung gelöscht wird?

Die alte Rechnung wird nicht gelöscht und ist auch noch da. Alle Datensätze sind vorhanden. Sie könnten auch nicht gelöscht und wieder angelegt werden, da der Generator dann um eins weiter ist und die Rechnungsnummer sich erhöht hätte.

[BlueStarHH]

Zitat:

Zitat von MichaelT (Beitrag 1397490)

Wohl aber kann man über 2 Sessions arbeiten, bspw. das Programm 2 Mal starten, in einem die Verlinkung auf der GUI herstellen und den alten Satz noch kurz vor dem Post rauslöschen. Den hat die Sperre vermutlich mal nicht im Visier. Ein allfälliger Dialog ist zu dem Zeitpunkt schon geschlossen.

Auf einem PC kann das Programm nur 1x gestartet werden. Eine zweite Session vom selben Anwender auf dem selben PC ist damit nicht möglich.

[BlueStarHH]

Zitat:

Zitat von MichaelT (Beitrag 1397461)

Die Aussage: Das zeigt jetzt die Rechnung 4. Zum Zeitpunkt des Fehlers habe ich das nicht abgefragt. Die Rechnung 4 wurde aber im DB Grid zum Fehlerzeitpunkt angezeigt.

Heißt auch, dass die Rechnung gelöscht gewesen sein könnte.

Gerade nochmal gecheckt: die Rechnung 4 ist momentan da. Sie kann auch nicht gelöscht und wieder angelegt werden, da der Generator dann um eins weiter ist und die Rechnungsnummer sich erhöht hätte. Die wäre dann nicht mehr auf 4 und es gäbe eine Lücke.

[hoika]

Tja,
das zeigt mir wieder,
in etwas aufwändigeren Scenarien sind DB-sensitive GUI-Elemente völlig fehl am Platz.

Du kannst das nur versuchen, anhand der Kunden-Infos den Vorgang nachzuvollziehen.
Nimm zur Not 2 Rechner.

Viel Glück.

Willkommen im Club.

[MichaelT]

Danke.

Dann bleibt mal allein im DB Monitor die statements rauszufahren die zu dem Zeitpunkt abgesetzt werden.

Außer du hättest mal IBDAC upgedated auf genau eine Version in der zumindest ähnliches Verhalten wurde beim Support gemeldet, aber nicht gleich. Das war beim Sprung von 5.4.12 auf 5.4.13 Support Forum Devart

Besonders die Sache mit der Notiz kommt mir seltsam vor. Es wäre gut zu wissen, selbst wenn der Fehler nicht mehr auftritt, was es am Ende war.

Zitat:

Zitat von BlueStarHH (Beitrag 1397494)

Zitat:

Zitat von MichaelT (Beitrag 1397461)

Die Aussage: Das zeigt jetzt die Rechnung 4. Zum Zeitpunkt des Fehlers habe ich das nicht abgefragt. Die Rechnung 4 wurde aber im DB Grid zum Fehlerzeitpunkt angezeigt.

Heißt auch, dass die Rechnung gelöscht gewesen sein könnte.

Gerade nochmal gecheckt: die Rechnung 4 ist momentan da. Sie kann auch nicht gelöscht und wieder angelegt werden, da der Generator dann um eins weiter ist und die Rechnungsnummer sich erhöht hätte. Die wäre dann nicht mehr auf 4 und es gäbe eine Lücke.

[BlueStarHH]

Zitat:

Zitat von MichaelT (Beitrag 1397457)

Hat die Applikation in der Meldung vor der jener die du anführtest deadlock angegeben?

Engine Code : 335544336
Engine Message :
deadlock
violation of FOREIGN KEY constraint "FK_RECHNUNGEN_1" on table "RECHNUNGEN"
Foreign key reference target does not exist
Problematic key value is ("ERSETZTRGNR" = '11')

nicht ausgegeben. Das wäre der Fall dass eine Benutzer die Rechnung löscht und in einer zweiten Transaktion versucht die Rechnung in ERSETZRGNR einzutragen. Das dürft ob des AutoCommits nicht passieren.

Ob da noch deadlock am Anfang der Meldung stand oder nicht kann ich nicht mit Sicherheit sagen. Ich werde dazu mal ein Log-Mechanismus einbauen, der diese Meldungen in eine Log-Datei schreibt. Dann geht man nicht in Gefahr, dass die Anwender einen Teil der Meldung unterschlagen.

Kann es den wirklich vorkommen, dass der Meldungstext "deadlock" noch um weitere Details ergänzt wird? In der Doku steht, dass bei Fehler 335544336 nur der Text "deadlock" ausgegeben wird. Mehr Text habe ich bei deadlocks bei anderen Fällen in der Vergangenheit auch noch nie gesehen.

[BlueStarHH]

Zitat:

Zitat von MichaelT (Beitrag 1397490)

Offensichtlich wird die Rechnung angelegt ohne ErsetztRgNr. Dann die alte Rechnung löschen und die zu ersetzende Rechnung manuell eintragen? Klingt verwegen. Die werden die ersetzt die Rechnung nicht mit der Hand reinpfrimmeln :-D

Im ersten Schritt wird die Rechnung, die ersetzt werden soll, im DB Grid ausgewählt. Dann wird ein Button geklickt. Dort wird sich die ausgewählte Rechnungsnummer gemerkt. Anschließend wird die neue Rechnung angelegt und die gemerkte Rechnungsnummer in deren Feld ERSETZTRGNR geschrieben.

[BlueStarHH]

Zitat:

Zitat von MichaelT (Beitrag 1397516)

Dann bleibt mal allein im DB Monitor die statements rauszufahren die zu dem Zeitpunkt abgesetzt werden.

Da jetzt ja nach dem Neustart alles wieder funktioniert, mach es wenig Sinn es sich jetzt anzuschauen? Ich müsste dann wohl nochmal auf den Fehler warten? Hast Du einen Link zum Thema "DB Monitor"? Denn das sagt mir leider gar nichts.

Zitat:

Zitat von MichaelT (Beitrag 1397516)

Außer du hättest mal IBDAC upgedated auf genau eine Version in der zumindest ähnliches Verhalten wurde beim Support gemeldet, aber nicht gleich. Das war beim Sprung von 5.4.12 auf 5.4.13 Support Forum Devart

Ich werde demnächst das Updat auf die aktuelle Version kaufen. Dann sehen wir mal weiter.

Zitat:

Zitat von MichaelT (Beitrag 1397516)

Besonders die Sache mit der Notiz kommt mir seltsam vor. Es wäre gut zu wissen, selbst wenn der Fehler nicht mehr auftritt, was es am Ende war.

Wenn das nochmal auftritt oder ich Erkenntnisse habe, werde ich das auf jeden Fall hier berichten. Denn sowas ist schon komisch und darf nicht passieren.

[IBExpert]

Monitoring der eigenen Statements sollte IBDAC können, viel effektiver wäre es aber zum Beispiel, den weg zum Fehler serverseitig zu finden, wenn
mehr als ein Client beteiligt ist. Trace geht auch mit dem Lieferumfang von firebird >=2.5, aber ist evtl. komfortabler in anderen Tools, z.B.
http://www.ibexpert.net/IBE/INDEX.PH....TraceAndAudit