Dokumente aus der Zukunft

[FrankLU]

Hallo!

Ist es ein Omen, dass ich heute an einem Freitag, den 13. folgendes Phänomen habe?

Nach dem Compact einer Datenbank über die Erstellung einer neuen Replik tritt das Phänomen auf, dass neue Dokumente ein Erstellungs- und Änderungsdatum haben, das 26 Stunden und ein paar Minuten in der Zukunft liegt.

Bild 1 zeigt ein Dokument nach seiner Erstellung und Speicherung in der Datenbank, Bild 2 zeigt das Änderungsdatum von zwei Agenten , die ich am Nachmittag des 12. Mai geändert habe. Merkwürdigerweise stimmen die Zeiten bis auf die Sekunde überein, obwohl zwischen beiden Speicherungen 5 min liegen!

Das Phänomen tritt auch nur in dieser einen Datenbank auf. Auf dem Server stimmen Datum und Uhrzeit. Werden Dokumente in anderen Datenbanken auf diesem Server erstellt, so stimmen die Zeiten auch.

Was ist da faul? Und wie bekomme ich das weg?

Schönes Wochenende!
Frank

[Tode]

Works as designed.... Wie Du vielleicht weisst, ist die Document Unique ID tatsächlich nur ein Zeitstempel. Und dieser Zeitstempel enthält die Erstellzeit des Dokuments. Die Dialoge lesen also den Erstell- Zeitpunkt aus der Document Unique ID ab.

Jetzt hat dieser Zeitstempel nur eine maximal mögliche Granularität von ... ich müsste Lügen ... irgendwas zwischen 1/1000 und 1 Sekunde.

Wenn Du also programmatisch mehr Dokumente in sehr kurzer Zeit erstellst, als "Unique Timeslots" in der selben Zeit vorhanden sind, dann wandern die Document Unique IDs und damit auch die Erstell- Zeitstempel in die Zukunft.
Diese "Zukunfts- Zeitstempel" sind dann gültige Werte, die natürlich auch bei  einer Replikation berücksichtigt werden.

Unique IDs / bzw. Dokumente in der Gegenwart können dann erst wieder erstellt werden, wenn die "Realzeit" den maximal vergebenen Zeitstempel aus den UNIDs eingeholt hat...

[FrankLU]

Hallo Tode,

Danke für die Erklärung! Das leuchtet mir erst mal ein. Aber:

Wenn sich die Document Unique IDs der einzelnen Dokumente bei der Replik-Erstellung während des Compacts ändern würden, würde doch aber nichts mehr zusammenpassen, nicht mal die Repliken der Dokumente untereinander, wenn eine Datenbank auf mehreren Servern als Replik vorhanden ist, ganz zu schweigen von den Abhängigkeiten (vorgegebenen ($Ref) und programmierten).

Und was ist dann mit dem Umgang von "Zukunftsdokumenten" bei Abfragen und Weiterverarbeitung? Eine Abfrage, die das Erststellungsdatum abfragt (@Created), würde nach dem Compact falsche Ergebnisse liefern. Das wäre sehr beunruhigend...

Ich muss also nach einem Replica-Compact eventuell mehrere Tage warten, ehe ich mit der Datenbank wieder arbeiten kann? Auch unbefriedigend, erst recht, wenn ich vielleicht keine weitere Replik dieser Datenbank auf einem anderen Server habe.

Oder habe ich es nicht verstanden?

[CarstenH]

Torsten hat vermutlich nicht genau auf deinen Screenshot geschaut - die UNID ändert sich natürlich nicht beim Compact, das wäre tödlich.

Um zum Thema zurück zu kommen - in allen Fällen, die ich bisher näher untersucht habe war tatsächlich eine falsche Server- (oder Client-) Zeit die Ursache, initial verursacht in allen (mir bekannten) Fällen durch einen Zeitsprung eines Zeitservers und in zwei Fällen außerdem durch eine anschließende Aktion eines Admins, die Zeit händisch zu "korrigieren".

Da die Zeit nicht rückwärts laufen kann gibt es keine (mir ad hoc einfallende) Methode das in den DB's/Dok's zu "korrigieren" außer durch neu Anlegen (oder Warten bis die falsche Zeit überschritten wurde). Bei 1 Tag Differenz würde ich das hier tatsächlich bis morgen aussitzen - alles andere hat hier kein vernünftiges Aufwand/Nutzen-Verhältnis.

HTH
Carsten

[Ralf_B]

Hallo Frank

ich habe hier Datenbanken bei denen ich täglich mehrere Tausend Dokumente per Agent erstelle/ändere und diese zeigen dann auch oft ein Zukunftsdatum in den Eigenschaften.
Grund: https://support.hcltechsw.com/csm?id=community_question&sys_id=784a65811bca8d50a67e9759bc4bcb5a&view_source=searchResult

Ich muss also nach einem Replica-Compact eventuell mehrere Tage warten, ehe ich mit der Datenbank wieder arbeiten kann?

Für die 'normale' Repliierung macht das keine Probleme. Neue und geänderte Dokumente werden aktialisiert.
Für die selektive Replizierung sollten diese Werte eigenlich nicht benutzt werden.
Platz für ein Feld wie "Erstelldatum" und "Änderungsdaum" ......   sollte in der Maske doch vorhanden sein.
Diese werden auch korrekt gefüllt.
PS: Das ist schon seit Jahren (immer ??) so.


Ich sehe nur den Nachteil dass, zum Beispiel, ein Löschagent diese Werte benutzt.
Dann bleibt das Dok halt etwas länger in der DB.
Bishe hat das noch keine Probleme bereitet und für Abfragen oder Agenten nutze ich diese Werte nicht. 

Gruss
Ralf

[FrankLU]

@CarstenH

Wenns am Server liegen würde, müssten ja auch in anderen Datenbanken neue Dokumente mit einem falschen Erstellungs- und Änderungsdatum gespeichert werden. Tun sie aber nicht.

Auffällig ist eben, dass das Phänomen nach einem Compact mit Replica-Erstellung auftritt und daher nur auf die eine DB beschränkt ist. Insofern hat die Erklärung von Tode schon was für sich. Aber für's Arbeiten mit zeitkritischen Dokumenten bezüglich Erstellungs- und Änderungsdatum ist das doch Mist! 

[FrankLU]

@Ralf_B

Hallo Ralf,

danke für Deinen Hinweis. Das in Deinem Link wieder auf Links verwiesen wird, muss ich das alles erst noch durcharbeiten. 

Aber ich bin doch sehr erstaunt, dass ein Dokumentenverwaltungssystem wie Domino keine eigenen Felder für Erstellung und Änderung hat, sondern da was errechnet wird oder ich etwas programmieren soll.

Und es ist eben schon sehr verwirrend, wenn aus einer Anwendung heraus Memos und E-Mails verschickt werden und der Empfänger zurückfragt, warum das Erstellungsdatum seiner erhaltenen E-Mail in der Zukunft liegt? Da nützt mir auch kein selbst programmiertes Feld etwas. Das untergräbt doch die Seriosität und das Vertrauen in die EDV-Anlage meiner Firma. Und das ist ganz schlecht!

Das Beste: In einem der Links heißt es zum Schluss (etwas verkürzt und abgewandelt): It's not a bug, is's a feature. 

[FrankLU]

Ich wollte mich bei allen bedanken, die etwas zu meiner Frage beigesteuert haben!

Nun weiß ich, dass es neben der DocUID und der Notes-ID noch eine OID gibt.

Um es einfacher zu machen, ist hier der kleine Text aus dem Link https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0079290

It is simple to assume that if documents are being updated through some agent, then the last document in the collection should have the last modified date similar to the date-time when the agent gets completed.
However, it is not so and there is an explanation for the same.
"Modified date" present in "Document Properties" is displayed based on the value obtained from OID (Originator ID-the red frame below) [Anm. d.Red: Dokumenteneigenschaften, letzter Reiter (mit Propellerkappe)].
 
OID is an identifier that represents the version information of a document.
The same document on the replica will have the same OID, but the OID will be updated when the document is modified and saved.
The OID is generated based on the date and time when it was updated. The way Notes/Domino works, it is designed to always retain a unique value in the database.

When a large number of documents are updated in a short period by the agent's processing, the unique value will be required at almost the same time.
In that case, the workflow is something like below.
1) Stagger the date and time to keep unique values.
2) Generate OIDs.
3) Assign OIDs to each document.
As a result, if documents are updated in large numbers, the "Modified Date" value (displayed based on the OID) becomes a future date.

Ich wünsche Euch allen ein schönes Wochenende!

Grüße
Frank

[Ralf_B]

Hallo Frank

das sehe ich etwas anders.
Diese Werte sind Systemintern und nur für Interne Zwecke bestimmt.
Keine (Standard) Mailbox zeigt den Wert @Created irgendow an, sondern nutzt andere Felder.
Wobei das Thema Mail nochmal ein anderes ist.

Aber ich bin doch sehr erstaunt, dass ein Dokumentenverwaltungssystem wie Domino keine eigenen Felder für Erstellung und Änderung hat, sondern da was errechnet wird oder ich etwas programmieren soll.

Wenn Du eine neue Maske erstellst ist genau das der Fall, dann sollte man auch wissen was man macht braucht.
Sonst bleibt nur die "Low Code" Programmierung.

Das ist wie wenn ich mich darüber beschwere, dass im §Updatedby auch die Server stehen, weil ich will nur die User sehen ....  dann programmiere es halt.
Dafür ist Domino "frei programmierbar"

PS: Das erinnert mich an Web Programmierer (hab ich erlebt) die Dokumente in Domino anhand der Unique ID auf Webseiten referenzieren.
Der Link ist also hin wenn sich die ID ändert ......  also sollte man eigene Felder benutzen.


Gruss
Ralf