Firebird: Datensatz wird nicht gefunden, obwohl er da ist

[jobo]

Zitat von BlueStarHH:

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 von jobo:

Zitat von BlueStarHH:

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 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 von mkinzler:

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 von mkinzler:

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 von BlueStarHH:

Zitat von MichaelT:

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 von MichaelT:

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 von MichaelT:

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.