Firebird: Datensatz wird nicht gefunden, obwohl er da ist

[BlueStarHH]

Zitat:

Zitat von Neumann (Beitrag 1397437)

Es sind Varchar-Felder, über die die Tabellen verknüpft werden. Ist zwar möglich, aber auch gefährlich, da man z.B. am Bildschirm Leerzeichen nicht sieht. Besser alles über Int-Werte verknüpfen und sicherstellen, das diese nicht mehrfach vergeben werden können, z.B. mit Generatorwerten.

Der Benutzer kann in die Schlüssel-Varchar-Felder nichts eingeben. Die Werte kommen aus einem Generator. Ob das gut ist oder nicht und warum das so ist, sollte nichts mit meinem Problem zu tun haben. Bitte den Thread aufgrund der Lesbarkeit nicht mit einer Diskussion darüber "aufblasen". Danke!

[BlueStarHH]

Zitat:

Zitat von mkinzler (Beitrag 1397438)

Künstliche Schlüssel (Schlüsselfeld nicht Teil der Daten) sind m.E. immer zu bevorzugen. Zudem sollte man die Erzeugung der Werte dem Server überlassen, er kann so sicherstellen, dass diese immer eindeutig sind.

Ja klar, künstliche Schlüssel wären besseres DB-Design. Aber wo ist da der Zusammenhang mit meinem Problem? Der Kunde wird in beiden Fällen gefunden. Er ist schon ewig in der DB ist, wurde nicht geändert und wird von der Software mit den Rechnungen verknüft (keine Eingabefehler durch Anwender o.ä.)

[MichaelT]

Arbeitest du mit IBCTable(s) in der Anwendung? 5 ist nicht zufällig die Ersatzrechnung von 4 oder so ähnlich in die Richtung?

[BlueStarHH]

Zitat:

Zitat von MichaelT (Beitrag 1397443)

Arbeitest du mit IBCTable(s) in der Anwendung?

Kunden und Rechnungen sind je eine TIBCQuery
Notizen ist eine IBCTable

[BlueStarHH]

Zitat:

Zitat von MichaelT (Beitrag 1397443)

5 ist nicht zufällig die Ersatzrechnung von 4 oder so ähnlich in die Richtung?

Nein, 5 und 4 haben nichts miteinander zu tun.

[MichaelT]

Danke. Das habe ich überlesen.

Jetzt funktioniert vermutlich wieder alles auch bei den Benutzern?

Zitat:

Zitat von BlueStarHH (Beitrag 1397446)

Zitat:

Zitat von MichaelT (Beitrag 1397443)

5 ist nicht zufällig die Ersatzrechnung von 4 oder so ähnlich in die Richtung?

Nein, 5 und 4 haben nichts miteinander zu tun.

[MichaelT]

Ich habe grad durchprobiert:

Zur Vorsicht, einfach nachgefragt:
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.

---

Also verbleibt der Fall (in dem einem Punkt) dass der Benutzer die alte Rechnung hätte gelöscht, was an sich sobald die Ersatzrechnung richtig eingetragen ist nicht gehen könnte.

Frage: Ist die zu ersetzende Rechnung noch da?

[jobo]

Zitat:

Zitat von MichaelT (Beitrag 1397457)

Frage: Ist die zu ersetzende Rechnung noch da?

Und: Im Code ist die Bestimmung von ErsatzRGnr gar nicht angegeben, aus einem Generator kommt sie ja sicher nicht.

[MichaelT]

Stimmt. Sagt aber noch lange nicht, dass der Code hier der Punkt wäre an dem das Problem auftritt.

Wenn es bei anderen Rechnungen einwandfrei geht und bei der nicht, dann bleibt nicht viel. Eine Ersatzrechnung auf sich selbst geht durch.

Wenn es auf der Ebene der Statements an sich mal nichts hat, bleibt bestenfalls eine Änderung in den Komponenten selbst oder in der Programmlogik.

Wenn eine Rechnung angelegt wird. Die zu ersetzende Rechnung gelöscht wird und nachher ein Update wird versucht ist das Vorgehen dasselbe.


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.

Zitat:

Zitat von jobo (Beitrag 1397458)

Zitat:

Zitat von MichaelT (Beitrag 1397457)

Frage: Ist die zu ersetzende Rechnung noch da?

Und: Im Code ist die Bestimmung von ErsatzRGnr gar nicht angegeben, aus einem Generator kommt sie ja sicher nicht.

[hoika]

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?