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

SQL-Code:

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?

[Delphi.Narium]

Wenn die beiden zufällig gleichzeitig die Änderungen durchgeführt haben, könnte es bei einem ungeschickten Transaktionshandling zu einer derartigen Situation kommen.

Der eine kann schon das Neue sehen, der andere noch nicht, aber beim Alten ist es genau umgekehrt.

Mein erster Ansatz wäre hier den Quelltext der Stellen, an denen diese Änderungen durchgeführt werden, dahingehend zu prüfen, ob das Transaktionshandling dort korrekt ist.

Etwas Literatur zum Thema: IBPhoenix - Understanding Firebird Transactions

[BlueStarHH]

Zitat:

Zitat von Delphi.Narium (Beitrag 1397431)

Der eine kann schon das Neue sehen, der andere noch nicht, aber beim Alten ist es genau umgekehrt.

Beide Benutzer arbeiten mit unterschiedlichen Rechnungen (4 und 5). Wie sollte das alt vs. neu also hier hereinspielen?

[BlueStarHH]

Zitat:

Zitat von Delphi.Narium (Beitrag 1397431)

Mein erster Ansatz wäre hier den Quelltext der Stellen, an denen diese Änderungen durchgeführt werden, dahingehend zu prüfen, ob das Transaktionshandling dort korrekt ist.

Ein Transaktionshandling gibt es im Quellcode nicht. Der Code ist ein simples DataSet.Insert und dann eine DataSet.Post nachdem der Benutzer die Felder in der GUI gefüllt hat. Das Transaktionshandling ist in den IBDAC-Komponenten eingestellt:

Lockmode = lmLockImmediate
AutoCommit = true
IsolationLevel = iblReadCommitted

[BlueStarHH]

Zitat:

Zitat von bnreimer42 (Beitrag 1397430)

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:

Zitat von bnreimer42 (Beitrag 1397430)

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?

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

Zitat von Delphi.Narium (Beitrag 1397436)

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:

Delphi-Quellcode:

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.

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

[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

[jobo]

Zitat:

Zitat von BlueStarHH (Beitrag 1397519)

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.

.. wird die neue Rechnung angelegt..
ist das ein spezieller Vorgang (meinetwegen Button "ersatzrechnung") oder identisch mit Standardrechnungen? Geschieht das gleich mit Kundenzuordnung?
.. und die gemerkte Nummer in deren Feld ERSETZ..
Ist das Bestandteil des Vorgangs neue Rechnung oder eine separate Opteration / Button oder Handarbeit?

So wie es beschrieben ist, finde ich vor allem die "Merken"Stelle kritisch.
Irgendwann drückt der MA "merken" und irgendwann später wird das gemerkte wieder ausgespukt. Ist das für den MA transparent (also wird die Merkung visualisiert)? Ist das wasserdicht? Kann auch eine Nummer 2x "ausgespukt" werden bzw. solange, bis der Mitarbeiter mal wieder daran denkt, die richtige Nummer merken zu lassen?

Ach und das noch: Loggen ist immer gut, sollte bei einer firmeninternen Anwendung auch kein Problem sein. Am besten gleich auf einem Server, bei nicht Erreichbarkeit lokal, gerne auch etwas flexibel, zu/ab- schaltbar, .... Und nicht nur die Stelle, die gerade interessant ist. Der nächste Fehler wird ja vermutlich woanders auftauchen.

[BlueStarHH]

Zitat:

Zitat von jobo (Beitrag 1397533)

Zitat:

Zitat von BlueStarHH (Beitrag 1397519)

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.

.. wird die neue Rechnung angelegt..
ist das ein spezieller Vorgang (meinetwegen Button "ersatzrechnung") oder identisch mit Standardrechnungen? Geschieht das gleich mit Kundenzuordnung?
.. und die gemerkte Nummer in deren Feld ERSETZ..
Ist das Bestandteil des Vorgangs neue Rechnung oder eine separate Opteration / Button oder Handarbeit?

So wie es beschrieben ist, finde ich vor allem die "Merken"Stelle kritisch.
Irgendwann drückt der MA "merken" und irgendwann später wird das gemerkte wieder ausgespukt. Ist das für den MA transparent (also wird die Merkung visualisiert)? Ist das wasserdicht? Kann auch eine Nummer 2x "ausgespukt" werden bzw. solange, bis der Mitarbeiter mal wieder daran denkt, die richtige Nummer merken zu lassen?

Das passiert alles unterbrechungsfrei in einem Vorgang. (Es gibt ja das selbe Problem mit den Notizen und da wird sich nichts "gemerkt"). Statt gemerkt hätte ich schreiben sollen: Wird in einer Variable zwischengespeichert. Hier nochmal der Code auszug von weiter oben mit der Ergängung wo die ERSETZTRGNR her kommt:

Delphi-Quellcode:

procedure AktuelleRechnungErsetzen;
var
  ErsetztRgNr: String;

begin
  ErsetztRgNr := Rechnungen.FieldByName('RgNr').asString; //<-- hier steht das DBGrid auf der Rechung, die ersetzt werden soll

  //hier wird eine neue Rechnung eingefügt und auch schon im Grid angezeigt und selektiert.
  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;
  Rechnungen.FieldByName('RgNr').asString := ErsetztRgNr //<-- hier die RgNr, von der Rg, die ersetzt werden soll, in die neue Rg einfügen

...usw für alle Felder

Die Rechnung die ersetzt werden sollte, war die ganze Zeit im Grid sichtbar. Und ist momentan auch da. Wie gesagt: Wenn sie irgendwie gelöscht worden wäre und dann irgendwie wieder neu ins System gelangt sein sollte, hätte sie jetzt eine andere RgNr und ich würde sie nicht mehr sehen (durch den Generator). Order irre ich mich da? Und

SQL-Code:

select * from Rechnungen where RgNr = 5

hat sie mir auch zum Zeitpunkt des Fehler auf dem betroffenen Client angezeigt.

[Delphi.Narium]

Wichtig wäre zu wissen, wo das Rechnungen.Post stattfindet, denn dort wird (höchstwahrscheinlich) der Fehler geschmissen. In dem Moment werden die Daten in die Datenbank geschrieben und die kann dann alle Constraints ... prüfen.

Das Problem scheint wohl grundlegend im Umfeld der zeitgleichen Änderung / Ergänzung ... der Daten eines Kundes von mehreren Usern zu liegen. Daher tritt der Fehler nach dem Beenden der Clientsoftware und deren Neustart nicht mehr auf.

Hast Du die Möglichkeit mal folgendes Zenario zu erstellen:

zwei Clients
zwei User
beide rufen Kunde Nr. 17 auf
beide ändern Daten des Kunden

Nun speichert ein User die Daten. Hat er Erfolg?
Nun speichert der andere User die Daten. Hat er Erfolg?

Naja: Und hier müsstest Du nun alle Kombinationsmöglichkeiten durchprobieren.

Also beide ändern zeitgleich 'ne Rechnung, ändern Notizen, legen sie an ...

Jeweils protokollieren, wo welche Fehlermeldung auftritt, bzw. was erfolgreich funktioniert.

Damit müsste dann herauszufinden sein, welche Konstellation nicht recht funktioniert und dort müsste man dann die Programmlogik anpassen.

[mkinzler]

Interessant wären auch DML-Skripte.

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1397567)

Interessant wären auch DML-Skripte.

Die gibt es auszugsweise in #6

[mkinzler]

Das sind die DDL-Skripte. Ich meinte die Skripte für Insert, Update, Delete in den TDataSet-Nachfahren (IBCQuery, IBCTable).

[Delphi.Narium]

Mich interessiert (seit Post #7), mit welchem Select Rechnungen befüllt wird und welche weiteren Selects es da so gibt.
Sind's einfach nur Select * from irgendeinertabelle oder sind's Joins oder haben sie 'ne Wherebedingung und wenn ja welche ...?

Wir arbeiten hier mit ReadCommited.

Was sieht denn jetzt (aufgrund der bisher unbekannten DML's) der einzelne Client, wenn mehrere Clients zeitgleich an einem Kunden "rumdaddeln"?

Für mich persönlich ist die Informationslage noch eindeutig "zu knapp", um sinnvolle Hinweise auf mögliche Fehlerstellen geben zu können.

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1397578)

Das sind die DDL-Skripte...

Sorry

[MichaelT]

Das macht wohl Sinn. Wir brauchen die DML Statements um mal zu entscheiden was überhaupt passieren kann. Die Komponenten selbst setzen generierte SQL Statements ab. Wir müssen quasi reverse in die Anwendung reinschauen.

Dann bekommen wir einen besseren Einblick welche Statements die Komponenten absetzen und erst dann geht man her und schaut wo das Verhalten in der Anwendung auftritt. Von jeder Technologie losgelöst macht das Sinn.

Solche Fehler kommen immer wieder und können zunehmen. Wie du sagt, so etwas soll nicht passieren.

Kann sein, dass proaktiv zu Handeln zwar nur mögliche Szenarien hervorbringt, wohl aber ist mal Erkenntnis zu haben ein Schritt in Richtung Lösung.

Zitat:

Zitat von BlueStarHH (Beitrag 1397520)

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.