Datensätze fehlen

[Blup]

Schuldzuweisungen helfen nicht wirklich weiter.
Man sollte erst einmal die Ursache eingegrenzen:

- Die Datensätze wurden nie in die Datenbank eingefügt.
- Die Datensätze wurden in die Datenbank eingefügt, die Transaktion wurde aber nicht erfolgreich beendet (kein Commit).
Die Datenbankverbindung wurde getrennt oder im Laufe der weiteren Bearbeitung trat ein Fehler auf.
Beides sind Ursachen für einen Abbruch der Transaktion (Rollback).
- Die Datensätze wurden später überschrieben oder gelöscht.
- Die Datenbankdatei wurde durch eine ältere Version z.B. aus einer Datensicherung überschrieben.
- Die Datenbankdatei ist beschädigt.

Notfalls jede Nutzeraktion und natürlich auch Fehlermeldungen unabhängig von der Datenbank in einer Logdatei protokollieren.

[Delphi.Narium]

Zitat:

Zitat von Blup (Beitrag 1426068)

Schuldzuweisungen helfen nicht wirklich weiter.

Es geht nicht um Schuldzuweisung, sondern einfach darum, sich mal dazu herabzulassen und den Anwender um Hilfe bei der Fehlersuche zu bitten. Der weiß nunmal eher als der Programmierer, wann ihm Daten verloren gegangen sind. Es ist extrem hilfreich, sich diese Information zu beschaffen.

Dann geht dashier alles deutlich einfacher:

Zitat:

Zitat von Blup (Beitrag 1426068)

Man sollte erst einmal die Ursache eingegrenzen:

- Die Datensätze wurden nie in die Datenbank eingefügt.
- Die Datensätze wurden in die Datenbank eingefügt, die Transaktion wurde aber nicht erfolgreich beendet (kein Commit).
Die Datenbankverbindung wurde getrennt oder im Laufe der weiteren Bearbeitung trat ein Fehler auf.
Beides sind Ursachen für einen Abbruch der Transaktion (Rollback).
- Die Datensätze wurden später überschrieben oder gelöscht.
- Die Datenbankdatei wurde durch eine ältere Version z.B. aus einer Datensicherung überschrieben.
- Die Datenbankdatei ist beschädigt.

Notfalls jede Nutzeraktion und natürlich auch Fehlermeldungen unabhängig von der Datenbank in einer Logdatei protokollieren.

Derweil: Anwender können verblüffend oft Hinweise geben, die eben dashier

Zitat:

Zitat von Blup (Beitrag 1426068)

Man sollte erst einmal die Ursache eingegrenzen:

ermöglichen. Da hilft zuweilen mal drei Minuten Frage- und Antwortspiel. Das ist effektiver, als alle möglichen Eventuallitäten erstmal mitzuloggen. Und ja: Es entbindet den Programmierer nicht eine vernünftige und möglichst vollständige Fehlerbehandlung zu implementieren.

Gerade bei sporadischen Fehler beziehe ich die Anwender immer mit in die Fehlersuche ein. Das hat für mich den Vorteil, dass auch "abgefahrene" Fehlersituationen recht schnell erkannt werden können, einfach die Sachen, auf die man von alleine garnicht kommt.

Aber: Es zeigt auch den Anwendern gegenüber eine Wertschätzung, nämlich, dass man sie mit ihren Problemen ernst nimmt und ihnen aktiv bei der Fehlerbehebung hilft.

Das mag aus purer technischer Sicht vielleicht nicht unbedingt "wichtig" sein, aus psychologischer Sicht aber durchaus.

Und ein Anwender, der merkt, dass ich ihn für voll nehme und seine Ideen, Anregungen, Probleme, Fragen ... ernst nehme, ist viel eher bereit mir zu helfen, benötigte Informationen zu geben ...

[Blup]

Das man zuerst mit dem Anwender spricht, sollte eigentlich selbstverständlich sein.
Nur führt das allein in den meisten Fällen nicht zur Fehlerursache.
Der wichtigste Grund:
Der Anwender bemerkt nur die Auswirkungen des Fehlers, nicht aber wenn der Fehler verursacht wird.

[Delphi.Narium]

Zitat:

Zitat von Blup (Beitrag 1426099)

Das man zuerst mit dem Anwender spricht, sollte eigentlich selbstverständlich sein.
Nur führt das allein in den meisten Fällen nicht zur Fehlerursache.
Der wichtigste Grund:
Der Anwender bemerkt nur die Auswirkungen des Fehlers, nicht aber wenn der Fehler verursacht wird.

Ja, natürlich. In solchen Fälle setz' ich mich notfalls auch mal 'ne Stunde zum Anwender und lass mir die Arbeit Schritt für Schritt zeigen und genau erklären (egal, ob ich es schon weiß oder nicht, ob's banal ist oder nicht).

Kann mich an einen ähnlichen Fehler erinnern:

Ab und an wurde ein Satz nicht gespeichert. Nur bei einem Anwender.

Ursache: Banal, einfach, doof und schlecht implementiert.

Nach der Eingabe des letzten Satzes hat dieser Anwender das Programm mit 'nem Klick auf das X oben rechts im Fenster geschlossen. Direkt nach der Eingabe des letzten Zeichens ins Eingabefeld. Ein durchaus möglicher und zulässiger Weg.

Aber: In dieser Situation wurden die Speicherroutinen nicht aufgerufen.

Ohne den Hinweis vom Anwender bin ich halt nicht auf die Idee gekommen, dass das die Fehlerursache sein könnte.

[NoName1]

vielen Dank für Eure ausführlichen Antworten.
Um das Ganze zum Abschluss zu bringen, möchte ich noch folgendes erwähnen.
Da ich mit den Anwendern in sehr engem Kontakt stehe, weiß ich wie die Datenerfassung erfolgt und sie die Fenster schließen.
Es wird wohl nichts anderes Übrigbleiben als eine Logdatei zu erzeugen um alles zu protokollieren.
Nur weiß ich noch nicht, wie ich das zu bewerkstelligen habe. Vielleicht hat ja

Zitat:

Blup
Notfalls jede Nutzeraktion und natürlich auch Fehlermeldungen unabhängig von der Datenbank in einer Logdatei protokollieren.

einen „Workaround“ und / oder kann Hinweise geben?

Wenn das Fenster für die Adressdaten geschlossen wird, dann wird folgender Code ausgeführt:

Delphi-Quellcode:

procedure TMSFmAdressen.FormDestroy(Sender: TObject);
begin
  Adresse.Destroy;
end;

destructor TOAdressen.Destroy;
begin
  SetLength(BRFunktionen, 0);
  dtmdMain.DoStartTransaction;
  dtmdMain.adressen.Edit;
  dtmdMain.adressen.Post;
  dtmdMain.ibtrnsctnVerein.Commit;
  inherited;
end;

// Die Transaction:
procedure TdtmdMain.DoStartTransaction;
begin
  if not ibtrnsctnVerein.InTransaction then ibtrnsctnVerein.StartTransaction;
end;

An diesem Code kann es wohl auch nicht liegen?