"geändert von" Zeit liegt in der Zukunft

[hen]

Hallo,

ich hab mehrere Dokumente die nach einer Änderung in den Dokumenten Eigenschaften ein Datum anzeigen das in der am heutigen Tag in der Zukunft liegt. Es dreht sich immer um Zeiten zwischen 18:30 - 18:55. Ich hab zwei Dokumente innerhalb von 5 Minuten geändert und beide haben die gleiche Zeit unter "geändert" stehen.

Meines Wissen ist der Wert in den Dokumenteneigenschaften der Wert von der Properties lastmodified. Hierbei nimmt Notes die aktuelle Serverzeit. Die Serverzeit hab ich überprüft. Falls ich mich irre. Meine Clientzeit ist auch richtig.

Es gibt keinen Agenten der die Zeit ändert. Ich habe mir mit einem Tool mehrere Dokumente genommen und Werte geändert. Selber effekt.


Gruß
Hen

[m3]

Wenn Du in der Server-Konsole nachschaust, ist dort die Zeit auch OK?

[hen]

ja.

[Jag_rip]

dasselbe Problem hab ich auch seit heute... 

und zwar auf dem gesamten Server, sobald ich etwas anfasse und speichere, ist das last modified in der Zukunft..

hat einen unangenehmen Einfluss auf Agenten, denn die triggern sich bei keinem neuen Dokument mehr.

Das Attachment zeigt ein Mail, welches in eine mail-in auf dem Server geschickt wurde...

Die Windoofs Zeit stimmt auf dem Server, die Console zeigt auch dieselbe Zeit an. Lustig wirds wenn ich ein neues Dokument erstelle. Creationdate steht die Aktuelle zeit, aber das Dok wurde schon modifiziert vom Server mit einem Timestamp der Zukunft 

Auch ein intressanter Hinweis: es ist bis auf die Sekunde IMMER dieselbe Zeit... 

[cubetoon]

Das kommt mir doch alles sehr bekannt vor. Kann bei euch eine ganz andere Ursache haben, muss es aber nicht:

http://atnotes.de/index.php?topic=33961.msg214868

Mit einer kleinen Zusammenfassung am Ende des threads.

Mit welcher Version des Domino Server arbeitet Ihr?

[Jag_rip]

hallo cubetoon

nach durchlesen deines Freds, getrau ich mir gar nicht mehr zu sagen, welche version wir einsetzen..  6.5.1


hab auch im Console-Window des öfteren die Meldung:

"Database XXXX time is too far in the future."

bin jetzt gerade dran, gemäss den tips hier vorzugehen, aber mit mässigem Erfolg...

mässig im sinn von: es ist immernoch in der Zukunft nach neuanlegen einer Replik und ersetzen derselben.
Erfolg im Sinn von: nun sind es nicht mehr Tage sondern nur noch Minuten in der Zukunft. 

[cubetoon]

Habt Ihr den sogenannten 'Serverclient' also den Notes Client auf dem Server laufen?

Gib an der console mal 'dbcache show' ein - ich vermute einmal, dass die betroffenen datenbanken im cache gelistet sind.

Unsicher ob das geholfen hatte oder zumindest die Zukunft etwas gebremst hat : dbcache disable - deaktivierte den datenbank cache, kann natuerlich nachteilig in terms of performance sein.

Ansonsten: finde den User, der seine Systemzeit hin- und her stellt waehrend er eine datenbank geoeffnet hat.

[Jag_rip]

das mit dem Dbcache disable werde ich austesten, danke für den Tip! Es sind zum glück nur eine Handvoll Datenbanken (<50) auf dem Server sodass druch dieses Setting die Performance nicht merklich ausgebremst wird, denk ich mal.

Der Server ist unter anderem Fax-Gateway sowie POP/SMTP Gateway und hat keine User direkt auf dem Server. Auch arbeiten die Admins meines Wissens nicht mit dem Serverclient sondern mit ihrem Adminclient auf den eigenen Maschinen, werde das aber zur Sicherheit nochmals auf den Tisch bringen am nächsten Meeting.


Momentan zählen wir noch auf das Fachwissen eines Externen Profis (m3 wird das sicher freuen ;-) ) und haben auf seinen Rat hin testweise alle Agenten, die zeitgesteuert laufen deaktiviert und den Server gestoppt und neu gestartet. Soweit haben wir den Timecreep temporär gestoppt, nun wird jeder einzelne Agent gestartet und beobachtet ob das Creeping wieder losgeht. So hoffen wir den "Täter" zu identifizieren.

Die bittere Pille daran ist, dass mein Wochenende so eher zuhaus über die Bühne gehen wird.. zum glück verpass ich da wettertechnisch nix schlimmes. 

So long.. Wenns ghilft oder alles zerschossen hat, werde ich Euch wieder berichten.   

[Jag_rip]

aaaalso, wir haben den Bock gefunden..  es war ein Agent den ein Notes-Designer ein wenig unbedacht verändert hat und (ich kenn mich da nicht aus) irgendwelche Selectionformeln verhauen hat. Mehr Infos WAS genau der Agent WIE gemacht hat, und was daran nicht gut war, hab ich selber auch nicht..  Fakt ist, nachdem alle Agenten auf dem Server gestoppt waren, trat das Time-Creeping nicht mehr auf. Wir haben dann DB für DB, Agent für Agent gestartet und beobachtet, bis wir (natürlich bei der zweitletzten) dann den Verursacher gefunden haben.

Ein Neuanlegen aller Repliken brachte dann die Modified-Dates auch wieder ins HierUndJetzt, soweit stimmte der Tip von IBM zwar schon, war aber nicht die ganze Wahrheit.. 


Merci für die Unterstützung hier und ich sags nun auch nochmals, holt euch einen Externen Notes-Spezi, wenn ihr auf ein grösseres Problem stosst, bei uns war er 2 Stunden vor Ort und gab Tips wie wir es selber lösen konnten. Damit bekommen uns auch keine Unbezahlbaren Rechnungen auf den Tisch.

Gruss aus der Schweiz, Shägy