Fehlerursache bei Datumsverlust

[Sir Rufo]

Wenn 1/8 der Installation so einen Fehler produziert, dann würde ich an 3 Stellen ansetzen.

1. Die USV - aber bitte eine Online

Meine/Kunden- Erfahrungen mit/ohne USV:
- 1. Server mit 8 Platten im RAID, kompletter Blattschuss
- 2. Server mit 7 Platten im RAID zickte immer wieder rum
Online-USV -> kein Zicken und Murren mehr (seit ca. 3 Jahren)

- Kassensystem in einer Filiale mit seltsamen Ausfallerscheinungen, aber der Kunde wollte auch nicht glauben, dass es am Strom liegt (aber bei 1 von 80 ...)
Mein Vorschlag, er bekommt die USV erstmal für 6 Monate so hingestellt, wenn dann kein Fehler mehr auftaucht, dann bezahlt er die komplett. Somit ist er jetzt stolzer Besitzer einer USV - klar hat er die bezahlt ;)

Das das Datum plötzlivh wieder korrekt ist finde ich nicht ganz so verwunderlich, denn schließlich gibt es ja Zeitdienste auf dem Rechner, die die Uhrzeit auf dem Rechner setzen können.
Allerdings sollte dann ein Eintrag im EventLog vorhanden sein.

2. Rechner prüfen -> EventLog

3. Software prüfen, spezielle Debug-Version, lieber langsam und richtig und den Fehler finden

[hathor]

Versuch:
Windows.GetSystemTime //Retrieves the current system date and time in UTC format.
Diese Zeit speichern in einer globalen Variablen.
Plausibilitätsprüfung:
Eine nachfolgende Zeitabfrage darf nicht kleiner sein als die Variable.

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
.
Ausserdem:
All Microsoft Windows versions since Windows 2000 include the Windows Time Service,[5] which has the ability to sync the computer clock to an NTP server.
http://en.wikipedia.org/wiki/Network_Time_Protocol

[jobo]

Ich kann den letzten beiden Posts nur zustimmen. Anhand der Angaben zur Anzahl der Rechnungen / Bons, scheint es eher ein Krautladen zu sein. Da kann man wirklich ohne sich weit aus dem Fenster zu lehnen die Vermutung haben, dass die Verkabelung teilweise etwas hand made ist, bzw. schlicht einfach auch die Leistung einzelner Vrkabelungen an der Absicherungsgrenze schrammen. Wenn dann die Klimaanlage anspringt..
Ob das dann zu den geschilderten Effekten führt ist erstmal pure Spekulation. Und das ist der entscheidende Punkt. Ich würde 2 Dinge an meiner Anwendung dringend ändern. Die Plausi-prüfung ala hathor und Logging!
Nur so kannst Du systematisch Ursachen ausschließen und der Sache auf den Grund gehen.

[vagtler]

Zitat:

Zitat von Sir Rufo (Beitrag 1157858)

[...] Das das Datum plötzlivh wieder korrekt ist finde ich nicht ganz so verwunderlich, denn schließlich gibt es ja Zeitdienste auf dem Rechner, die die Uhrzeit auf dem Rechner setzen können. [...]

Die immer genau zwischen zwei Bons korrigierend eingreifen? Aber sicher...

[jobo]

Es ist ja nicht so, dass das System Millionen Bons pro Tag generiert. Ich finde es auch unwahrscheinlich, aber wenn alle 5 Minuten ein Bon rausgeht, kann doch dazwischen irgendwann korrigiert werden.

[Sir Rufo]

Zitat:

Zitat von vagtler (Beitrag 1157883)

Zitat:

Zitat von Sir Rufo (Beitrag 1157858)

[...] Das das Datum plötzlivh wieder korrekt ist finde ich nicht ganz so verwunderlich, denn schließlich gibt es ja Zeitdienste auf dem Rechner, die die Uhrzeit auf dem Rechner setzen können. [...]

Die immer genau zwischen zwei Bons korrigierend eingreifen? Aber sicher...

Das kategorische Ausschließen hilft nicht weiter, sondern die Analyse des EventLogs.

[Laser]

Hallo,

zur Eingrenzung würde ich auch Debug-Code einfügen und in ein Logfile schreiben.

An der Stelle, wo der Bon mit 0-Datum rauskommt und dann immer weiter nach vorne hangeln.
Das ganze jeweils mit Zeitstempeln versehen und zwar alle Formate, die Du im Programm verwendest.


Eine Alternative wäre, ein Programm zu schreiben, dass sich in Int $1A einhängt und jede neue Sekunde zunächst in den Speicher schreibt und dann in ein Logfile ausgibt. Das ganze als CSV so strutkurieren, dass man es gut in EXCEL importieren kann.

Vielleicht ergibt sich ja wirklich eine Unregelmäßigkeit der Uhr. Die könnte z.B. durch andere Programme verursacht sein, die auch am Timer-Interrupt "rumbiegen".

[vagtler]

Sehr verwunderlich finde ich übrigens, dass hier niemand auf den einzig vernünftigen Vorschlag eingeht:

Zitat:

Zitat von p80286 (Beitrag 1157782)

Wenn du schon mit einer Datenbank arbeitest, warum läßt Du nicht von ihr das Datum generieren?
(Im allg. denken DBs auch an Zeitzonen, Sommemer und Winterzeit usw.) [...]

Darüber hinaus stimmt mich

Zitat:

Zitat von khh (Beitrag 1157767)

Zitat:

Zitat von vagtler (Beitrag 1157749)

[Vorschlag des Rechnertauschs]

das ist nicht so einfach, da der Datenbestand auf den verschiedenen Maschinen unterschiedlich ist.

sehr bedenklich im Hinblick auf die zugrunde liegenden Architektur. Und genau da vermute ich unter besonderer Berücksichtigung der Beitragshistorie die eigentliche Crux.

[Sir Rufo]

Zitat:

Zitat von vagtler (Beitrag 1157907)

Sehr verwunderlich finde ich übrigens, dass hier niemand auf den einzig vernünftigen Vorschlag eingeht:

Zitat:

Zitat von p80286 (Beitrag 1157782)

Wenn du schon mit einer Datenbank arbeitest, warum läßt Du nicht von ihr das Datum generieren?
(Im allg. denken DBs auch an Zeitzonen, Sommemer und Winterzeit usw.) [...]

Auch zu Debug-Zwecken (in diesem speziellen Fall) wäre es interessant bei jedem Datensatz zusätzlich einen TimeStamp durch die DB erzeugen zu lassen (DB scheint ja lokal auf dem Rechner zu liegen).
Wenn beide Werte dann auf 0 stehen (bzw. nicht die korrekte Uhrzeit widerspiegeln) ist es ein Problem ausserhalb der eigenen Software - die Verantwortlichkeit ist man aber trotzdem nicht los ;)

[khh]

Zitat:

Zitat von vagtler (Beitrag 1157883)

Zitat:

Zitat von Sir Rufo (Beitrag 1157858)

[...] Das das Datum plötzlivh wieder korrekt ist finde ich nicht ganz so verwunderlich, denn schließlich gibt es ja Zeitdienste auf dem Rechner, die die Uhrzeit auf dem Rechner setzen können. [...]

Die immer genau zwischen zwei Bons korrigierend eingreifen? Aber sicher...

die Bons werden ja auch in unregelmässigen Abständen gedruckt.
Nicht jeder Kassiervorgang endet mit Bondruck, weil viele Kunden auf den Bon verzichten.