Firebird: Datensatz wird nicht gefunden, obwohl er da ist

[BlueStarHH]

Ich habe u.a. 3 Tabellen

Code:

Kunden
---------------
KdNr
...

Rechnungen
---------------
KdNr    -> FK auf Kunden.KdNr
RgNr    
ErsetztRgNr  -> FK auf Rechnungen.RgNr
...

Notizen
---------------
RgNr        -> FK auf Rechnungen.RgNr
NotizNr
...

Ein Kunde kann x Rechnungen haben. Eine Rechnung kann x Notizen haben. Eine Rechnung kann durch eine andere ersetzt werden, falls Sie z.B. storniert wurde (Feld ErsetztRgNr).

So kommt es nun zum Fehler:
Benutzer A wählt Kunde 17 aus und hat heute eine neue Notiz zur Rechnung 4 angelegt (Notizen.RgNr = 4). Die Notiz kann nicht mit DataSet.Post gespeichert werden, da folgende Meldung erscheint:

Zitat:

violation of FOREIGN KEY constraint "FK_Notizen_1" on table "Notizen". Foreign key reference target does not exist. Problematic key value is ("RgNr" = 4)

Benutzer B wählt auch Kunde 17 aus und hat heute eine neue Rechnung angelegt, die Rechnung 5 ersetzt (Rechnungen.ErsetztRgNr = 5). Die neue Rechnung kann nicht mit DataSet.Post gespeichert werden, da folgende Meldung erscheint:

Zitat:

violation of FOREIGN KEY constraint "FK_Rechnungen_1" on table "Rechnungen". Foreign key reference target does not exist. Problematic key value is ("ErsetztRgNr" = 5)

Der Kundendatensatz existiert schon seit Jahren und wurde laut Aussagen der Benutzer nicht geändert (nicht prüfbar, ob das stimmt). Beide Benutzer nutzen die Software auf Ihrem eigenen PC. Die DB liegt auf dem Server.

Beide Rechnungen (4 und 5) werden im Programm angezeigt. Rechnung 5 habe ich nochmal mit SQL geprüft: Mit select * from Rechnungen where RgNr = 5 wird die Rechnung 5 zurückgegeben. Beide Benutzer können bei anderen Kunden Notizen oder Rechnungen ohne Probleme anlegen. Es betrifft nur den Kunden mit KdNr 17. Komisch ist ja, dass beide Rechnungen 4 und 5 nicht direkt miteinander verknüpft sind, aber beide Probleme bereiten.

Eben hat Benutzer A die Software neu gestartet. Problem immer noch da. Dann haben beide Benutzer die Software beendet und neu gestartet. Nun können beide ihre neuen Datensätze anlegen und posten.

Ich habe mir jeweils eine Kopie mit gbak.exe und mit einfachem Kopieren der DB-Datei gezogen. Nach einspielen der Kopien hier, lässt sich der Fehler nicht reproduzieren. Die Kopien wurden gezogen, nachdem einer von beiden Benutzer die Software neu gestartet hatte.

Wer hat eine Idee, was die Ursache des Fehler ist? Und wie ich ihn ggf. nachstellen und in Zukunft vermeiden könnte.

[bnreimer42]

Bitte DDL hier posten.

Sonst kann man nur raten, was die Ursache sein kann.

Was gibt

Code:

select * from Rechnungen where RgNr = 4

zurück?

[BlueStarHH]

Zitat von bnreimer42:

Bitte DDL hier posten.

Sonst kann man nur raten, was die Ursache sein kann.

SQL-Code:

CREATE TABLE Kunden (
    KdNr                    VARCHAR(15) CHARACTER SET ASCII NOT NULL,
    ...
)
ALTER TABLE Kunden ADD CONSTRAINT PK_Kunden PRIMARY KEY (KdNr);
   
   
CREATE TABLE Rechnungen (
    KdNr                      VARCHAR(15) CHARACTER SET ASCII NOT NULL,
    RgNr                      VARCHAR(25) CHARACTER SET ASCII NOT NULL,
    ErsetztRgNr               VARCHAR(25) CHARACTER SET ASCII,
    ...
)
ALTER TABLE Rechnungen ADD CONSTRAINT PK_Rechnungen PRIMARY KEY (RgNr);
ALTER TABLE Rechnungen ADD CONSTRAINT FK_Rechnungen_1 FOREIGN KEY (ErsetztRgNr) REFERENCES Rechnungen (RgNr);
ALTER TABLE Rechnungen ADD CONSTRAINT FK_Rechnungen_2 FOREIGN KEY (KdNr) REFERENCES Kunden (KdNr) ON DELETE CASCADE ON UPDATE CASCADE;


CREATE TABLE Notizen (
    NotizNr         INTEGER NOT NULL,
    RgNr            VARCHAR(25) CHARACTER SET ASCII,
    NOTIZ           BLOB SUB_TYPE 1 SEGMENT SIZE 80
    ...
);
ALTER TABLE Notizen ADD CONSTRAINT PK_Notizen PRIMARY KEY (NotizNr);
ALTER TABLE Notizen ADD CONSTRAINT FK_Notizen_1 FOREIGN KEY (RgNr) REFERENCES Rechnungen (RgNr) ON DELETE CASCADE ON UPDATE CASCADE;

Zitat von bnreimer42:

Was gibt

Code:

select * from Rechnungen where RgNr = 4

zurück?

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. Auch hier nochmal der Hinweis: Es handelt sich bei dem Fehler um 2 Rechnungen (4 und 5) die nichts miteinander zu tun haben und die auch nicht wechselseitig von den Benutzern bearbeitet wurden. Je der Benutzer hat ausschließlich mit 4 oder 5 gearbeitet.

[Delphi.Narium]

Sie arbeiten mit unterschiedlichen Rechnungen aber mit dem gleichen Kunden.

Wie sehen die Statements aus, mit denen die Datasets gefüllt werden?

[BlueStarHH]

Zitat von Delphi.Narium:

Wie sehen die Statements aus, mit denen die Datasets gefüllt werden?

Für die Rechnung:

Delphi-Quellcode:

if InsertAtBegin then
begin
  Rechnungen.First;
  Rechnungen.Insert;
end
else
  Rechnungen.Append;

Rechnungen.FieldByName('RgNr').asString := GetNewRgNr;
Rechnungen.FieldByName('KdNr').asString := Kunden.FieldByName('KdNr').asString;
Rechnungen.FieldByName('Datum').asDateTime := Date;
...usw für alle Felder

Dann kann der Nutzer noch Daten über DBEdits/Grid ergänzen und drückt dann einen Button mit:
Rechnungen.Post;

Für die Notiz:

Delphi-Quellcode:

Notizen.Insert;
Notizen.FieldByName('NotizNr').asString := GetNewNotizNr;
Notizen.FieldByName('RgNr').asString := Rechnungen.FieldByName('RgNr').asString;
Notizen.FieldByName('Notiz').asString := 'ABC';
Notizen.Post;

GetNewXXXXNr fragen einfach einen Generator ab.

[Neumann]

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.

[mkinzler]

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.

[BlueStarHH]

Zitat von mkinzler:

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.ä.)

[BlueStarHH]

Zitat von Neumann:

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!

[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?