Dokumente mit Änderungsdatum 5.7.1976

[CarstenB]

Hallo zusammen,
wir hatten heute ein Problem, daß in einer Datenbank mehr als 5000 Dokumente doppelt waren. Gleiche Anwendungs-ID, aber unterschiedliche UniqueID, also keine Konflikte. Bei genauerer Betrachtung hat sich herausgestellt, daß diese Dokumente alle heute zur Serverreplik hinzugefügt wurden und ein Änderungsdatum vom 5.7.1976 hatten.

Über die Logs konnte ich den User ausfindig machen und anhand seiner lokalen Logs sehen, daß er die Daten hochrepliziert hat.

Nachdem ich jetzt die Serverreplik wieder aufgeräumt habe, will ich mich jetzt auf die Fehlersuche machen, komme aber noch nicht so richtig weiter

* Der User sagt, er hat seine Datumseinstellungen nicht verändert
* Er hat die Daten auch nicht per copy/paste eingefügt
* Die Tage zuvor wurde nur pull repliziert, heute pull/push
* Checke ich den effektiven Zugriff für seine ID, bekomm ich "Kein Zugriff", obwohl er Editorrechte hat

Hat noch jemand Tipps, wonach ich noch Ausschau halten kann?


Wünsche ein schönes Wochenende,

[smokyly]

Hallo,

hat dieser User ein Laptop?

Gruss

[CarstenB]

Ja, ist ein Laptop

Neue Info: Effektiver Zugriff scheint nur ein temporäres Problem gewesen zu sein, nach Notes-Neustart wird es wieder richtig angezeigt

[smokyly]

Dachte ich mir doch. Denn so etwas in der Art ist mir auch schon oft unter gekommen, wenn der Akku von dem Teil leer war (oder gezogen und wieder eingesetzt wurde) und sich dann das Datum auf Default wieder zurück gestellt hat. Die Benutzer haben das leider erst einmal gar nicht mit bekommen.

[CarstenB]

mmmh, ein guter Hinweis, aber er sagt, er hat nur mit Netzteil, also Docking Station, gearbeitet.

Und es würde meiner Meinung auch nicht die über 5000 neuen Dokumente erklären

[smokyly]

Wie gesagt, ich kenne solche seltsamen Effekte bei unseren Aussendienstmitarbeitern und es hat sich immer auf den "stromlosen" Laptop eingrenzen lassen. Was dann genau weiter passierte konnte ich nie klären / nachvollziehen.

Tut mir leid, mit mehr Info kann ich nicht dienen.

Gruss

[CarstenB]

Hattet ihr dann auch das Verhalten mit neuen (also doppelten) Dokumenten oder waren nur bestehende Dokumente mit einem alten Timestamp versehen?

[smokyly]

Nicht in dem Umfang und in der Art, wie Du es beschrieben hast, aber es wurden zum Teil alte und gelöschte Dokumente wieder "sichtbar".

Schlimmer war eigentlich, dass neu erfasste Auftragsdaten mit diesem alten Datum rein kamen und das war dann ein übles Durcheinander. Aber das ist jetzt OT.

Du könntest aber, um es zu verifizieren, die Geschichte nachstellen. Also Replik erzeugen und dann..... und dann Datum am Rechner zurückstellen und dann wieder replizieren. Wenn Dir der Aufwand das wert ist. Mir war er es damals nicht.

[m3]

Na wenn die BIOS-Batterie am Laptop leer wird, startet er mit einer Default-Uhrzeit (5.7.1976?). Und bis dann das Windows die Uhrzeit über einen Timeserver wieder richtet ....

[koehlerbv]

Geri, wenn Ihr aber bereits gelöschte Dokumente wieder auf den Server repliziert bekommen habt, hat das dann nicht (nur) zwingend was mit dem falschen Datum auf der Client-Box zu tun - dann ist da mit der Replizierung noch was ganz anderes schief gelaufen: Dort wurde lange nicht oder unvollständig repliziert und der Client hat keine Deletion Stubs mehr empfangen. Dadurch blieben die gelöschten Dokumente auf dem Client erhalten, auf dem Server aber nach der eingestellten Frist entfernt. Und ann wurde "richtig" repliziert und die auf dem Server gelöschten Dokumente, die auf dem Client ja noch vorhanden waren,a ls neue Dokumente erkannt. Bumm ...

Bernhard

[smokyly]

Bernhard, das mag sein. Ist aber alles schon lange her und mit Repliken arbeiten wir eh so gut wie nicht mehr.

Mir ist das mit dem seltsamen Datum nur so bekannt vor gekommen...

Beste Grüsse

[Tode]

Das Datum ist höchstwahrscheinlich der Geburtstag des Mitarbeiters oder eines seiner Bekannten / seiner Eherfrau, etc....

Ich denke, das ganze ist so abgelaufen: Der Benutzer wollte -aus welchem Grund auch immer- herausfinden, auf welchen Tag besagtes Datum gefallen ist...

Er geht also rechts unten auf die Systemuhr und dreht die bis zum besagten Datum zurück.

Das fiese an Windows XP ist aber, dass diese Änderung SOFORT zieht (oder zumindest nach einer kurzen Verzögerung), auch wenn man NICHT OK drückt. Wenn während dieser Zeit Notes gestartet war, dann lief das für ne kurze Weile mit diesem alten Datum, selbst wenn Der Benutzer das relativ Zeitnah wieder zurückgestellt hat...

Und so kommt es dann zu einem "unvorhergesehene" Effekt bei der nächsten Replikation.

Ich stimme aber mit meinen Vorrednern überein, dass der Fehler schon lange vorher passiert ist und latent vorhanden war (keine korrekte Replikation mit der lokalen Replik seit geraumer Zeit) und nur durch das Uhrzeitproblem quasi "ausgelöst" wurde...

Du könntest mal die log.nsf am Client öffnen, ich bin mir sicher, dass Du da Logs vom besagten Datum finden wirst...

Gruss
Tode

[smokyly]

Das Datum ist höchstwahrscheinlich der Geburtstag des Mitarbeiters oder eines seiner Bekannten / seiner Eherfrau, etc....

Die Idee hat was.
Aber warum zum Henker macht jemand das über das BS und nicht über - was könnte das wohl sein?

[CarstenB]

Hallo Torsten,
nein, im lokalen Log sehe ich, daß dort am 15.4.2011 etwas mehr als 5000 Dokumente auf den Server geschoben wurde. An den Tagen zuvor wurde immer korrekte repliziert

[CarstenB]

Tach nochmal,
wir haben jetzt wieder das Problem. Anderer User, andere Datenbank, heut morgen wurden über 800 Dokumente mit Datum 5.7.76 reinrepliziert. Dokumente sind jetzt doppelt vorhanden.
Ist das evtl. ein Bug in 8.5.2?

[Micha B]

Dann wärst Du, glaube ich, nicht der einzige hier mit dem Problem 

[FriFra]

Tach nochmal,
wir haben jetzt wieder das Problem. Anderer User, andere Datenbank, heut morgen wurden über 800 Dokumente mit Datum 5.7.76 reinrepliziert. Dokumente sind jetzt doppelt vorhanden.
Ist das evtl. ein Bug in 8.5.2?

Dieser MA könnte z.B. in der Zwischenzeit die falschen/korrupten Dokumente zu sich repliziert haben... und nun hast du sie eben mit der nächsten Replizierung zurück bekommen

[CarstenB]

die Dokumente waren nicht auf der Serverreplik vorhanden. Sie sind erst heute morgen dort hinzugefügt worden. Er kann sich sich also nicht lokal repliziert haben

[Peter Klett]

Kann es sein, dass diese Dokumente vor langer Zeit in der Serverreplik existiert hatten? Der User hat vielleicht im April die Dokumente lokal repliziert, dann habt Ihr die im Mai gelöscht, und nun, 3 Monate später, nachdem die Deletion-Stubs aus der Serverreplik entfernt wurden, hat er die Dokumente wieder zurückrepliziert. Wenn er dazwischen nie repliziert hat, kommt sowas gerne vor, ist kein Bug, sondern ein Feature.

Wieso sind die Dokumente doppelt, wenn Sie vorher nicht in der Datenbank gewesen sein sollten? Vielleicht gab es mal irgendeine Reparaturaktion, mit der diese Dokumente neu (korrigiert) in die Datenbank kopiert und die alten gelöscht wurden? Da sind dann zwar optisch die gleichen Dokumente in der Datenbank, technisch sind das aber ganz andere (andere UniversalID).

[CarstenB]

Hallo Peter, nein,  das Problem lässt sich nicht mit den Deletion Stubs erklären. Das bei längerer Nicht-Replizierung Dokumente zurückkommen können ist schon klar. Der User hat aber die letzten Tage auch repliziert, ein paar Dokumente gezogen, ein paar geschrieben, alles sieht laut seinem Log gut aus.
Das alles erklärt auch nicht das Datum "5.7.76".