Domino 9 und frühere Versionen > ND6: Administration & Userprobleme

Time is too far in the future...

<< < (2/2)

Thomas Schulte:
Ja zum Beispiel mit Agenten die gelaufen sind. Die Agentenprotokolle müssen auch alle gelöscht werden und dann kommen noch so Prozesse wie der AdminP dazu die sich nämlich auch mit einem Timestamp verewigen.

Nicht zu vergessen, das während dieser Aktion sämtlicher Verkehr zwischen den einzelnen Server und nach außenn eingefroren werden muss. Nein, auch kein Mail. Sämtliche Tasks die irgendwas an Datenbanken machen müssen stillgelegt werden.

Das ist wenn du es rückgängig machen willst ein absolutes Sch....Spiel.

Thomas

Thomator:
Hallo noch mal,

die Geschichte mit den Protokollen könnte ich auch umgehen, indem ich eine Schablone auf lokal ziehe, denke ich.
Aber dem Server kann ich offensichtlich nicht verklickern, dass die Zeit wieder geändert wurde. In die Konsole werden mir die Meldungen mit dem richtigen Datum geprinted, aber wenn ich im Designer neue Elemente erstelle, dann sind die alle per 2010 ertellt.

Sch...... ade  aber auch!
Da werde ich den wohl mal neu installieren müssen.

Thomas

MartinG:
Kann dem gesagten nur zustimmen, die Zeitumstellung hängt sich in so viele Bereiche (Design und Dokumente rein), die ich zumindest nicht mehr überblicken konnte.

Wir hatten das Problem bei 5x Maildatenbanken und haben nach div Reparaturversuchen das ganze mit dem IBM Support scheinbar in den Griff bekommen. User konnten normal arbeiten und auch keine Fehlermeldungen kamen mehr in der log.nsf

Als wir dann aber auf Notes6 migriert sind hat es genau bei diesen Datenbanken wieder geknallt mit sehr sehr seltsamen Effekten. Die "alten" Dokumente kann man aber IMHO schon rüberkopieren, allerdings sollte man darauf achten das keines von diesen im Feld $UpdatedBy ein Datum in der Zukunft hat....

In der KB gibts auch noch einiges zu dem Thema - meine Erfahrungen beruhen auch auf R5, wobei ich nicht denke das sich hier gross was geändert hat...

Thomator:
Hi,
ich habe jetzt mal folgendes probiert:


* Lokale Kopie der DB gezogen (ntf) mit Dokumenten,
* OriginalDB gelöscht,
* von der Lokalen Schablone neue DB auf dem Server abgelegt,
* neue DB mit der ID des Servers signiert (alle Elemente),
Und siehe da,  :o die Zeiten stimmen wieder! Auch wenn ich neue Gestaltungselemente anlege oder alte speichere.

Also scheint es doch in den Datenbanken selbst verankert zu sein.
Mal sehen, ob es sonst noch Spätwirkungen gibt, aber der Server hat für diese DB auch nach Neustart nicht gemeckert.
Und die Hoffnung stirbt zuletzt! ;D

Thomas

Thomator:
Nachtrag:

nachdem ich bei allen Datenbanken, die von dem "Time is too far ..." betroffen waren, so vorgegangen bin, ist das Problem gelöst.

Anfangs war ich noch skeptisch, aber nachdem der Server, alle Task's und die DB's jetzt 2 Wochen stabil laufen, gehe ich davon aus, dass es wirklich ohne Neuinstallation funktioniert hat.

Neben den Entwicklungs-Datenbanken habe ich die Prozedur auch mit der admin4.nsf, dbdirman.nsf, log.nsf und statrep.nsf durchgezogen.

Und nun ist alles wieder heil! :)

Thomas

Navigation

[0] Themen-Index

[*] Vorherige Sete