Fehlerursache bei Datumsverlust

[khh]

hallo zusammen,
ich habe in einem Kunden-Intranet mehrere XP -Rechner.
Auf diesen läuft unsere Kassensoftware.
Nun kommt es bei genau 1 Maschine (von 8, die aber woanders stehen ) ab und zu vor, dass das Bondatum, welches aus dem Rechnerdatum generiert wird auf 0 sprich 30.12.1899 gesetzt ist.
Einen Bon später ist alles wieder in Ordnung.
Meine Recherchen haben ergeben, dass Spannungsspitzen von z.B. Kältemaschinen( beim Ein-Ausschalten derselben) diese kurzfristigen Datumsverluste bewirken können sollen.
Kann hier jemand so was bestätigen und vieleicht technisch erklären?
Der betroffene Kunde kann nämlich nicht glauben, dass seine Kompressoren die Fehlerursache sein können.

Danke Gruss KHH

[Bummi]

Ich würde dazu neigen mich Deinem Kunden anzuschließen, gegf. eine nicht initialisierte Variable?

[himitsu]

Kommt drauf an, wie die Signalwege abgeschrimt sind und wie auf Fehler reagiert wird.

Aber schon sehr eigenartig, daß es dann immer nur einen Wert betrifft und nicht auch Andere. :gruebel:

Kommt auch noch darauf an, wie/ob auf Fehler reagiert wird.
z.B. kann das Datum ( TDateTime? ) nicht gelesen werden, könnte man einen Fehler werfen, die Daten erneut anfragen oder einfach einen Standardwert (0) verwenden.


Wenn es an Spannungsspitzen liegt, dann
- stärker geschrimte Netzwerkleitungen verwenden
- Strom- und Datenleitungen räumlich weit genug voneinander getrennt verlegen
- Entstörfilter verbauen, welche die Spannungsspitzen eliminieren

[p80286]

Du hast nicht zufällig eine USv zur Hand?
Damit könntest Du den Rechner vom Netz abkoppeln, und dem Kunden durch das Ausbleiben des Fehlers davon überzeugen, daß sein Stromnetz "verseucht" ist.

Gruß
K-H

[khh]

Zitat:

Zitat von Bummi (Beitrag 1157735)

Ich würde dazu neigen mich Deinem Kunden anzuschließen, gegf. eine nicht initialisierte Variable?

warum dann nur auf einer der 8 Maschinen und nur immer am gleichen Standort?

[khh]

Zitat:

Zitat von p80286 (Beitrag 1157737)

Du hast nicht zufällig eine USv zur Hand?
Damit könntest Du den Rechner vom Netz abkoppeln, und dem Kunden durch das Ausbleiben des Fehlers davon überzeugen, daß sein Stromnetz "verseucht" ist.

Gruß
K-H

wäre auf jeden Fall ein Versuch wert!

Mir geht ja auch darum ob solche äusserlichen Einwirkungen tatsächlich diese Auswirkungen haben können, oder ob ich da völlig an der falschen Stelle suche.

[khh]

Zitat:

Zitat von himitsu (Beitrag 1157736)

Aber schon sehr eigenartig, daß es dann immer nur einen Wert betrifft und nicht auch Andere. :gruebel:

Ich gehe jetzt mal davon aus, dass die äusseren Einflüsse nur den Zeitgeber des Rechners beeinflussen, und dieser just in dem Moment des Kassiervorganges das aktuelle Datum "verloren" hat.

Dies würde erklären, warum nicht andere Variablen betroffen sind.

[vagtler]

Zitat:

Zitat von khh (Beitrag 1157739)

[...] ob ich da völlig an der falschen Stelle suche.

Ich bin da ganz bei Bummi und sage, dass Du an der völlig falschen Stelle suchst.

Störungen in den Versorgungsleitungen manifestieren sich garantiert nicht ausschließlich in einem auf 0 gesetzten Datumswert eines Delphi-Programms.

Zitat:

Ich gehe jetzt mal davon aus, dass die äusseren Einflüsse nur den Zeitgeber des Rechners beeinflussen, und dieser just in dem Moment des Kassiervorganges das aktuelle Datum "verloren" hat. [...]

Und wie durch ein Wunder hat er sich das aktuelle Datum aber gemerkt, so dass er es kurze Zeit (einen Bon) später wieder korrekt setzen kann? Aber sicher...

[khh]

Zitat:

Zitat von vagtler (Beitrag 1157743)

Zitat:

Zitat von khh (Beitrag 1157739)

[...] ob ich da völlig an der falschen Stelle suche.

Ich bin da ganz bei Bummi und sage, dass Du an der völlig falschen Stelle suchst.

Störungen in den Versorgungsleitungen manifestieren sich garantiert nicht ausschließlich in einem auf 0 gesetzten Datumswert eines Delphi-Programms.

Zitat:

Ich gehe jetzt mal davon aus, dass die äusseren Einflüsse nur den Zeitgeber des Rechners beeinflussen, und dieser just in dem Moment des Kassiervorganges das aktuelle Datum "verloren" hat. [...]

Und wie durch ein Wunder hat er sich das aktuelle Datum aber gemerkt, so dass er es kurze Zeit (einen Bon) später wieder korrekt setzen kann? Aber sicher...

ich suche hier ja keine Wunder sondern suche die Ursache des Fehlers.
Wenn eine Variable schuld ist, warum dann nur auf dieser einen Maschine an diesem Standort?
Auf den anderen Rechnern läuft doch die gleiche Software.
Vieleicht auch ein Hardwarefehler?
Oder doch ein Wunder ? ;-)

[vagtler]

Dann tausch doch einfach mal den betroffenen Rechner aus. Dann zeigt sich ja, ob das Problem immobil ist.

[PMM]

Mein Ansatz wäre folgender:
Die Netzstörungen erzeugen in der Tat irgendeinen Datenmüll. Darauf reagiert das Programm mit einer Excpetion die aber abgefangen ist und in die Datumsvariable die den Bon speisst eine 0.0 schreibt.
Ich würde also nach except-Blocks suchen in denen, direkt oder indirekt, diese Datumsvariable vorkommt.
PMM

[khh]

Zitat:

Zitat von vagtler (Beitrag 1157749)

Dann tausch doch einfach mal den betroffenen Rechner aus. Dann zeigt sich ja, ob das Problem immobil ist.

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

[khh]

Zitat:

Zitat von PMM (Beitrag 1157763)

Mein Ansatz wäre folgender:
Die Netzstörungen erzeugen in der Tat irgendeinen Datenmüll. Darauf reagiert das Programm mit einer Excpetion die aber abgefangen ist und in die Datumsvariable die den Bon speisst eine 0.0 schreibt.
Ich würde also nach except-Blocks suchen in denen, direkt oder indirekt, diese Datumsvariable vorkommt.
PMM

danke für deine Idee.

[s.h.a.r.k]

Ich finde auch, dass es mit sehr hoher Wahrscheinlichkeit ein Softwarefehler ist. Denn wie wahrscheinlich ist es denn, dass es immer nur die Datumsabfrage und echt nichts anderes betreffen sollte? Da glaube ich vorher an noch sehr viel andere Dinge... Alleine weile Protokolle und Hardware auf Störungen/Fehler reagieren können.

Wie generierst du denn das Datum? Und wie oft tritt denn das Problem auf?

[khh]

ich schreibe das Datum mit :
kopf.LIEFERDATUM:= now;
in die Datenbank und verwende dann das dort gespeicherte Datum.
Habe jetzt gerade mal die DB durchforstet.
in 20.000 Sätzen kommt der Fehler genau 9 mal vor.
Und tatsächlich nur die Datumsvariable ist betroffen, da steht 0 in der DB :-(

alle andern Werte stehen richtig in der DB

[s.h.a.r.k]

Was ists für eine DB? Wie greifst du darauf zu? Erzähl einfach mal ein bisschen mehr drum herum. Und sonst sind keinerlei Daten "defekt"?

PS: Bau doch mal einen Log ein... Du schreibst ja den Wert von Now in die DB und holst dir dann wieder den Datumswert. Da kann ja zwischendrin sehr viel schief laufen. Mache danach einfach mal eine Prüfung i.S.v.:

Delphi-Quellcode:

var
  CurrentTimestamp : TDateTime;
begin
  // ...
  CurrentTimestamp := Now();
  kopf.LIEFERDATUM:= CurrentTimestamp;
  // Schreibe Datensatz in DB
  // Hole Datum aus DB

  if (Math.Abs(kopf. LIEFERDATUM - CurrentTimestamp) > 1) Then
  begin
    Log('Es lief ziemlich was schief');
  end;
end;

Ich denke, die Idee ist klar?!

[p80286]

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.)

Wenn Du ein Problem mit einem Datum hast, und gleichzeitig ein Problem mit der Datenübernahme/gabe, Wunder gibt es nicht, aber da scheint doch irgendwo gewaltig der Wurm drin zu sein.

Gruß
K-H

[s.h.a.r.k]

Da fällt mir auch ein: prüfe mal die Versionen der Treiber, über welche du auf die DB zugreifst. Kann es sein, dass diese eine Maschine evtl. ein andere Version nutzt?

[khh]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1157781)

Was ists für eine DB? Wie greifst du darauf zu? Erzähl einfach mal ein bisschen mehr drum herum. Und sonst sind keinerlei Daten "defekt"?

PS: Bau doch mal einen Log ein... Du schreibst ja den Wert von Now in die DB und holst dir dann wieder den Datumswert. Da kann ja zwischendrin sehr viel schief laufen. Mache danach einfach mal eine Prüfung i.S.v.:

Delphi-Quellcode:

var
  CurrentTimestamp : TDateTime;
begin
  // ...
  CurrentTimestamp := Now();
  kopf.LIEFERDATUM:= CurrentTimestamp;
  // Schreibe Datensatz in DB
  // Hole Datum aus DB

  if (Math.Abs(kopf. LIEFERDATUM - CurrentTimestamp) > 1) Then
  begin
    Log('Es lief ziemlich was schief');
  end;
end;

Ich denke, die Idee ist klar?!

ja, das werd ich wohl mal einbauen, ich danke euch

[khh]

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.)

Wenn Du ein Problem mit einem Datum hast, und gleichzeitig ein Problem mit der Datenübernahme/gabe, Wunder gibt es nicht, aber da scheint doch irgendwo gewaltig der Wurm drin zu sein.

Gruß
K-H

ja den Wurm suche ich ja;-)
wobeii ich mich immer noch daran festbeisse, dass der Fehler nur auf 1 von 8 Maschinen auftritt.

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

[khh]

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.) [...]

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.

was hat der Datenbestand mit der Architektur zu tun.
Ist in der Praxis einfach so, dass verschiedene Filialen verschiedene Artikelbestände haben.
Und um unnötigen Netzverkehr zu vermeiden wurde jeder Kasse einen eigenen DB gespendet ;-)

[vagtler]

q.e.d.

[jobo]

Datenreplikation bzw. die spezifische lokale Architektur müsste einen aber nicht davon abhalten, den fraglichen Rechner mit einem anderen zu tauschen, evtl. reicht ein Festplattentausch oder eben ein Backup/Restore von den 2 Datenbanken der getauschten Systeme.

[khh]

Zitat:

Zitat von jobo (Beitrag 1158091)

Datenreplikation bzw. die spezifische lokale Architektur müsste einen aber nicht davon abhalten, den fraglichen Rechner mit einem anderen zu tauschen, evtl. reicht ein Festplattentausch oder eben ein Backup/Restore von den 2 Datenbanken der getauschten Systeme.

klar ist das machbar,
bedeutet halt nur ne zusätzliche Nachtschicht ;-)

[jobo]

Das wäre es mir wert, wenn ich daduch Spekulation durch Fakten ersätzen könnte.
:)

[Valle]

Äh... nochmal so zur Wiederholung: Einige von euch glauben, dass durch Störeinflüsse im Stromnetz das Datum eines Computers gelegentlich verloren geht und anschließend durch NTP direkt wieder gespeichert wird? Das ist doch nicht euer Ernst? :wall:

Liebe Grüße,
Valentin

[p80286]

seeing is believing
I've seen such things

gruß
K-H

[khh]

Zitat:

Zitat von p80286 (Beitrag 1158196)

seeing is believing
I've seen such things

gruß
K-H

zu was die Praxiserfahrung doch gut ist, gell ;-)