Datensätze fehlen

[NoName1]

Guten Tag,
meine kleine, spezielle Vereinssoftware wird auf einen Server
betrieben. Der Server ist ein Windows-Server 2012R2.
Zugegriffen wird über Firebird-Server-Embedded.
Nun passiert es, dass ab und zu bei einigen Vereinen Datensätze fehlen.
Und dies nur in einer Tabelle der gesamten Anwendung.
Ich kann mir nicht erklären warum dies so ist.
Ist dies bei Euch auch schon passiert und wenn ja, was habt Ihr dagegen unternommen?
Vielen Dank für Eure Hilfen

[peterbelow]

Zitat:

Guten Tag,
meine kleine, spezielle Vereinssoftware wird auf einen Server
betrieben. Der Server ist ein Windows-Server 2012R2.
Zugegriffen wird über Firebird-Server-Embedded.
Nun passiert es, dass ab und zu bei einigen Vereinen Datensätze fehlen.
Und dies nur in einer Tabelle der gesamten Anwendung.
Ich kann mir nicht erklären warum dies so ist.
Ist dies bei Euch auch schon passiert und wenn ja, was habt Ihr dagegen unternommen?

Irgendwie hört sich das nicht OK an von der Konfiguration her. Firebird embedded ist, soweit ich das verstehe, gedacht für Anwendungen, bei denen nur *ein* Benutzer zur Zeit auf die Datenbank zugreift und diese dann auch auf dem gleichen Rechner installiert ist, wie das Programm selbst. Für Anwendungen, bei denen mehrere Benutzer parallel mit der Datenbank arbeiten müssen, wird die Datenbank und der Firebird server auf einem Serverrechner im Netz installiert (der Server läuft dann als Windows service unter einem eigenen Account mit den notwendigen Rechten) und die Benutzer arbeiten dann auf anderen Rechnern, wo das entsprechende Clientprogramm dann per TCP/IP mit dem Server kommuniziert (Aufgabe der verwendeten data access package, FireDAC oder IBX).

Wenn Du mit einem in der Clientsoftware integrierten Server arbeitest und die Datenbank selbst auf einem Server liegt ist die Konfiguration nicht multi-user sicher, da bekommt man die gleichen Probleme wie mit der alten BDE.

[NoName1]

Vielen Dank für Deine Antwort,
vielleicht habe ich mich ein klein Wenig unglücklich ausgedückt.
Also, der Firebird-Embeded-Server ist auf dem Server eingerichtet.
Die User greifen über ein VPN-Tunnel und RDP auf Ihr jeweiliges Verzeichnis zu.
Ich habe gedacht der Firebird-Embeded-Server ist für den Serverbetrieb und es
können mehrere Nutzer gleichzeitig auf Ihre Daten zugreifen.
Ist es nun sinnvoller Interbase zu kaufen? Eine 10ner Lizenz kostet ca. 1.400,00€.
Und wird mit der "Kaufversion" kein Datenverlust mehr geben?

[mkinzler]

Embedded ist für Single-User. Aber als Alternative geht ja uach Firebird-Server. Dieser wird auf dem Server installiert. Von den Clients (bzw. dem RD-Server) wird dann auf diesen zugegriffen.

[hoika]

Hallo,
zuerst mal die grundsätzliche Frage, welches Firebird-version benutzt du?
Welches Windows-Version (Terminalserver).

Für Version <3

Zitat:

Also, der Firebird-Embeded-Server ist auf dem Server eingerichtet.

Ich nehme an, die hast die entsprechenden Dlls/Verzeichnisse "irgendwohin" kopiert.

Zitat:

Die User greifen über ein VPN-Tunnel und RDP auf Ihr jeweiliges Verzeichnis zu.

1 User = 1 Verein = 1 separates Verzeichnis pro User?
Wenn ja, ist alles OK, bisher.

Zitat:

Ich habe gedacht der Firebird-Embeded-Server ist für den Serverbetrieb

Nein, embedded heißt, Firebird wird nicht installiert,
sondern in das Verzeichnis der Anwendung kopiert, meistens gleich zusammen mit der Datenbank.
Die Datenbank wird exclusiv geöffnet, es ist kein Mehrbenutzerbetrieb erlaubt (FB-Version <3)

Zitat:

und es können mehrere Nutzer gleichzeitig auf Ihre Daten zugreifen.

Solange "ihre Daten" separat in einer eigenen Firebird-Datenbank liegen, dann ja, wenn nicht, nein.

Zitat:

Ist es nun sinnvoller Interbase zu kaufen

Warum Interbase, Firebird gibt es auch als "richtigen" Server, embedded ist doch eher ein Nische.

Also, definiere:
jeweiliges Verzeichnis
ihre Daten
gleichzeitig zugreifen

[NoName1]

Auf dem Server ist nicht Firebird-Embeded installiert, sondern der Firebird-Server.
Da habe ich mich vertan.
Unter Dienste auf dem Server finde ich folgendes:
Firebird Guardian: Startet automatisch
Firebird Server: Startet automatisch.
Siehe dazu auch den Anhang.

Zitat:

Ich nehme an, die hast die entsprechenden Dlls/Verzeichnisse "irgendwohin" kopiert.

Auf dem Server unter c:\Program Files (x86)\Firebird\
ist Firebird installiert.

Zitat:

1 User = 1 Verein = 1 separates Verzeichnis pro User?
Wenn ja, ist alles OK, bisher.

Genauso ist es alles auf dem Server organisiert.

Meiner Meinung nach ist alles korrekt installiert, deshalb kann ich mir den Datenverlust nicht erklären.

[jobo]

Hab ich ein deja vu? Das Thema hatten wir schon oder?

Und "nur in einer Tabelle" ..
Es reicht eine Constraintverletzung mit unpassendem Try Finally/Except und der Datensatz wird geräuschlos verschluckt.
Wenn es ein Mehrbenutzerproblem wäre, würde ja ein Satz überleben oder?

Und die Frage wäre auch, wie man das Fehlen überhaupt feststellt. Sind das Behauptungen von Anwendern oder nachvollziehbare Fakten?

[p80286]

Zitat:

Zitat von NoName1 (Beitrag 1425844)

Nun passiert es, dass ab und zu bei einigen Vereinen Datensätze fehlen.
Und dies nur in einer Tabelle der gesamten Anwendung.

Gibt es eine Relationzwischen Verein und fehlendem Datensatz?
Der Datenerfasser ist in allen Fällen älter als 45 Jahre und nicht weiblich?

Zitat:

Zitat von NoName1 (Beitrag 1425844)

Ich kann mir nicht erklären warum dies so ist.

Dann frag den, der das Design der Datenbank erstellt hat.

Zitat:

Zitat von NoName1 (Beitrag 1425844)

Ist dies bei Euch auch schon passiert und wenn ja, was habt Ihr dagegen unternommen?

a) Nein, ich schreibe keine Vereinssoftware
b) Ja, angeblich erfasste Daten waren nicht in der Datenbank zu finden, dann
werden zunächst die Datenüberprüft ob sie gegen irgendwelche Definitionen der Datenbank verstoßen,z.B.ungültiges Datum (31 April) oder fehlendes Datum.
Sollte es da keine Unstimmigkeiten geben,dann wird überprüft, ob der Benutzer alles so macht, wie er versichert. Es soll schon vorgekommen sein, daß erfasste Daten nicht gespeichert wurden.

Merke, in 99,5% aller Fälle sitzt/saß der Fehler vor der Tastatur.

Gruß
K-H

[hoika]

Hallo,
hm, Datenverlust ist immer "doof".

Wir reden also von einem richtigen Server -> gut ;)

1 User = 1 Verein = 1 Datenbank

OK
Gehen 2 Anwender mit dem gleichen Vereinsuser-Account ins Programm, überschreibt
Anwender2 die Daten von Anwender1.
Das bekommst du nur mit Logging innerhalb der DB selbst mit.

[NoName1]

Zitat:

OK
Gehen 2 Anwender mit dem gleichen Vereinsuser-Account ins Programm, überschreibt
Anwender2 die Daten von Anwender1.
Das bekommst du nur mit Logging innerhalb der DB selbst mit.

Jeder Nutzer hat einen eigenen Account mit Name und Passwort zum Server.
Im Programm ist dann auch nocheinmal eine Anmeldung mit jeweils eigenen Zugangsdaten nötig.

[jobo]

Zitat:

Zitat von NoName1 (Beitrag 1425923)

Jeder Nutzer hat einen eigenen Account mit Name und Passwort zum Server.
Im Programm ist dann auch nocheinmal eine Anmeldung mit jeweils eigenen Zugangsdaten nötig.

Bitte genauer, welcher Server
Windows?
Firebird auf Windows?
Welche Anmeldung?
Mit einem Firebird DB User?
Gegen welche DB?
Oder mit einer selbstgeschriebenen Nutzerverwaltung?
...

Was ist mit dem Thema: Woher stammt der Fakt, dass Datensätze fehlen? Logging? ...

[hoika]

Hallo,
aber jeder Verein hat eine eigene Datenbank oder ist es eine Datenbank?
Welche Endung hat die jeweilige Datenbank? (Stichwort System Restore von Windows)

Zitat:

Ist dies bei Euch auch schon passiert und wenn ja, was habt Ihr dagegen unternommen?

Nein nie! *Finger hinterm Rücken kreuz*

Erst mal musst du herausbekommen, wie es dazu gekommen ist, also versuchen nachstellen.
Selber testen, Nutzer interviewen.
Vor allem der Zeitpunkt der Eingabe und des Erkennens, dass was fehlt ist wichtig.
Und wie genau der Nutzer die Daten eingegeben hat.
Dann schau im Eventlog des Servers nach.

Ich gehe mal von einer täglichen Sicherung aus, die nicht den gleichen Namen hat?
Dann könnte man das Abend-Backup des Tages der Eingabe ansehen, ob die Daten wirklich drinsind.

Logging der Eingaben in der Datenbank hatte ich ja schon geschrieben.
Das hilft dann aber nur der Fehlersuche bei neuen Problemen,
nicht bei dem, was schon aufgetreten ist.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1425928)

Was ist mit dem Thema: Woher stammt der Fakt, dass Datensätze fehlen? Logging? ...

Oder anders herum,woran merkt man, daß Datensätze fehlen? Und dann nur in einer Tabelle?
Was ist das für eine Tabelle, wie ist sie aufgebaut?


Gruß
K-H

[TigerLilly]

Zitat:

Zitat von p80286 (Beitrag 1425915)

Der Datenerfasser ist in allen Fällen älter als 45 Jahre und nicht weiblich?

Ein Satz, der uns zeigt, dass der Autor ein Mensch mit hoher Intelligenz ist, der professionelles Verhalten schätzt und Kraft seiner Lebenserfahrung verstanden hat, was Respekt und erwachsenes Verhalten sind.

[jobo]

ot
ich glaube, hier gibt es ein Missverständnis.
Der Datenerfasser ist vielleicht ein > Alter Mann, Verein Taubenzüchter, Hühner, what ever. geringer Technikaffinität, kein Genderthema.
Es geht einfach um ein Fehlerszenario, das einem in den Sinn kommt.
Genauer noch, der Fehler tritt immer auf, wenn diese Merkmale vorliegen, also eine bestimmte Person, aber letztlich eine beliebige, also eine Person macht Eingabefehler, hier im Beispiel ein "alter Mann"

[MichaelT]

Die Datensätze werden nicht committed sein. Das liegt nahe.

Waren die Datensätze zuvor schon mal da? Gibt es Listen resp. Berichte in denen sie vorkamen und in deren Rahmen sie bspw. in gebildete Summen einflossen?

Gibt es einen zeitlichen Zusammenhang.

Such einfach mal nach Rollbacks oder was passiert wenn eine Anwendung über die Nacht geöffnet bleibt und nächsten Tag die Applikation zugemacht wird oder der Rechner abgeschossen.

Zitat:

Zitat von NoName1 (Beitrag 1425844)

Vielen Dank für Eure Hilfen

[Delphi.Narium]

[OT]

Zitat:

Zitat von TigerLilly (Beitrag 1425940)

Zitat:

Zitat von p80286 (Beitrag 1425915)

Der Datenerfasser ist in allen Fällen älter als 45 Jahre und nicht weiblich?

Ein Satz, der uns zeigt, dass der Autor ein Mensch mit hoher Intelligenz ist, der professionelles Verhalten schätzt und Kraft seiner Lebenserfahrung verstanden hat, was Respekt und erwachsenes Verhalten sind.

Denke mal, das p80286 mit seiner Aussage sinngemäß recht hat, Frauen verhalten sich einfach nicht so trottelig, wie die Kerle "gehobenen Alters". Fehlersuche bei Softwareproblemen, die ggfls. nicht direkt in der Software, sondern eher bei der Bedienung liegen (oder ursächlich mit der Art der Bedienung zusammenhängen können), ist mit Frauen deutlich einfacher, da sie fachlich oft deutlich kompetenter sind. Und das sagt ein "alter Knacker", der sich ein paar Jahrzehnte mit solchen Problemen rumgeschlagen hat.

Und ja: Bei derartigen Fehlern ist es oft sinnvoll, nach bestimmten "Kriterien vor dem Bildschirm" zu suchen, um hier eine bestimmte Fehlerquelle zu finden. Es mag ein Softwareproblem vorliegen, das sich aber nur bei einer bestimmten Art der Bedienung manifestiert.

Und hier kann die Suche nach bestimmten Personengruppen durchaus sinnvoll sein, da sie im Umgang mit Software eventuell nicht so fit sind, wie man erwartet. Das heißt aber nicht, dass man sie direkt als "minderbemittelt" oder sonstwie herabstufend einordnet. Sondern es geht um Fähigkeiten, die mal vorhanden sind, mal nicht (völlig normal), aber bei der Softwarebedienung eventuell hinderlich sein können, und sei es nur, dass die Beschriftung der Eingabefelder missverstanden wird, anders gedeutet, oder einfach (bedingt durch nachlassende Sehkraft) nicht mehr richtig erkannt werden.

Gerade bei sporadischen Fehlern, die nicht mal überall auftreten, ist eine Suche in diesem Umfeld durchaus sinnvoll und anzuraten, um ersteinmal die genaue Konstellation, die zum Auftreten des Fehlers führt, zu ermitteln. Ist die bekannt, kann man gezielt in der Software nach Problemen suchen, die in eben dieser Konstellation auftreten können und dann für eine Behebung sorgen. Auch wenn diese Fehlerbehebung in einer Umgestaltung der Oberfläche oder zusätzlichen Hinweisen und / oder Fehlermeldungen mündet.

Und ja: Die von p80286 genannte Personengruppe, nicht mehr so jung und nicht weiblich (zu der übrigens u. a. p80286 und ich gehören) ist da besonders prädestiniert. Wenn es hier also gerade um Diskriminierung gehen sollte, so diskriminieren wir uns selbst. Das dürfen wir doch, oder? ;-)
[/OT]

[hoika]

Hallo,
hm, bevor man dem Bug vor dem Bildschirm die Schuld gibt,
sollte man doch erst mal die offensichtlichen Bugs hinter dem Bildschirm,
also im Programm beheben.

Ah so: </Ironie>

[Delphi.Narium]

Zitat:

Zitat von hoika (Beitrag 1425983)

Hallo,
hm, bevor man dem Bug vor dem Bildschirm die Schuld gibt,
sollte man doch erst mal die offensichtlichen Bugs hinter dem Bildschirm,
also im Programm beheben.

Ah so: </Ironie>

Prinzipiell ja und natürlich ist das auch die erste Wahl. Erst wenn die scheitert, man also (wie hier einen sporadischen) Fehler nicht lokalisiert bekommt, dann muss man eben auch mal vor dem Bildschirm nachfragen, wann genau das passiert. Dass die Angabe zu diesem "Genau" durchaus sehr unpräzise sein kann, ist nunmal halt Programmiererleben. Da muss man durch ;-)

[p80286]

@Delphi.Natrium
Danke für die ausführliche Ausführung.

@Hoika
Ich lege auch Wert darauf, daß der ProgrammiererBug sich hinterfragt. Der sitzt ja schließlich auch vor der Tastatur. Oft genug hatte ich und andere Programmierkollegen andere Vorstellungen von einem logischen Ablauf als die Benutzer.

Gruß
K-H

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