Skip to main content
Skip table of contents

DigaReplicator / ReplicatorClient: Autoreplication and Timesync

Why aren't my entries not auto-replicated?

Possible issue: The time of your workstations is not synchronised with the DigaReplicator Server!

To perform a autoreplication, the time of the server and client must be the same. This can be done with a synchronisation tool or the Windows-embedded NTP function.
If the workstation time differences from the server too much, the entry will not be replicated.
The indicating flag for a replication is "Changedate/Changetime". If the Changetime differs too much from the Replicator time, the entry will be ignored.

-----------------------------
English
-----------------------------

Problem:
-----------------------------
Sometimes database entries are not successfully replicated from auto-replicated databases. We have determined that when one checks the ReplIdent field on the In/Out tab of the entry mask, no Replicator ID appears.

Cause:
-----------------------------
- If the client system time is ahead, then the auto-replication will always function, because in this case the 'modified time' of the entry is always later than that found saved in the DigaRepl "last auto-replication time" or "LART". At the same time, it's also possible that an entry could be replicated more than once (of course only the Metadata then after the first replication) because the 'modified time' is quite possibly later than the LART when analyzed by the AutoRepl process that may well have been triggered by another modification.

- If the client system time is behind, the auto-replication will function when (and only when) the time period since the LART is longer than system time offset of the client, because in that case the entry's 'modified time' is still "late enough". An example: when there is no activity in a table for 5 minutes and then a client whose system time is 3 minutes behind, saves an entry, then this entry's 'modified time' will still be 3 minutes behind the LART => replication works! But if the client is running 6 minutes behind in this situation, then the 'modified time will then actually be set 1 minute before the LART => therefore NO replication!

- A tolerance of 2 seconds is to be expected here because the DigaRepl compares the 'modified time' not with the LART directly, but with LART minus 2 seconds.

Solution:
-----------------------------
You must be sure to synchronize the Replicator Server and all clients system time (NetTime, NTPTime etc.)!


-----------------------------
German
-----------------------------

Problem:
-----------------------------
Manchmal werden Beiträge nicht erfolgreich aus autoreplizierten Datenbanken repliziert. Kontrolliert man in der Beitragsmaske im Reiter "Ein-/Ausgabe" die Replikator-ID, stellen wir fest, dass dort keine Replikator-ID vergeben ist.

Ursache:
-----------------------------
- Wenn der Client vor geht, dann wird die Autoreplikation immer funktionieren, da dann die Änderungszeit des Beitrags immer später als die im DigaRepl gespeicherte "letzte Autoreplikationszeit (LARZ)" liegt. Dabei kann es dann aber sein, dass ein Beitrag mehrmals repliziert wird (ab dem 2. Mal natürlich nur noch die Metadaten), da die Änderungszeit bei einem späteren AutoRepl-Durchgang (angestoßen durch irgendeine andere Änderung) evtl. immer noch nach der LARZ liegt.

- Wenn der Client nach geht, funktioniert die Autoreplikation dann und nur dann, wenn die Zeitspanne seit der LARZ länger ist als der Zeitverzug des Clients, da in dem Fall die Änderungszeit des Beitrags immer noch "spät genug" liegt. Ein Beispiel: Passiert auf einer Tabelle 5 Minuten nix, und dann legt ein Client, dessen Uhr um 3 Min. nachgeht, einen Beitrag an, so wird die Änderungszeit dieses Beitrags immer noch 3 Minuten nach der LARZ liegen => Replikation klappt! Hat der Client aber 6 Min. Zeitverzug, so liegt die Änderungszeit des Beitrags 1 Min. vor der LARZ => keine Re


More Replicator Routes in my Client?

In the new versions of the ReplicatorClient, I can configure more than one Replicator - but how do I configure this?

Solution: This configuration differs from the standard installation in that now multiple replicators can be entered under "Configuration\Replicator".
Although there is still an entry for the standard receiver list under "Configuration\Filepath", this is only entered as a 'dummy' (the "new" receiver lists inherit a portion of their filenames from this entry). Depending on how you have named your replicator targets, the assigned RCV Lists (RcvList-ReplA.RCV, RcvList-Repl.RCV etc.) will then be automatically created in the appropriate directory.

Finally, choose the desired target replicator in ReplClient's main screen and enter the receiver as usual. The entry in the correct RCVList functions automatically, this need not be attended.

=================================================================

Die Konfiguration weicht nicht von einer Standardinstallation ab, nur mit dem Unterschied dass nun unter "Konfiguration\Replikator" mehrere Replikatoren eingetragen werden können. Es gibt zwar noch unter "Konfiguration\Dateipfade" einen Eintrag für die Standard-Empfängerliste, diese wird aber nur noch als "Dummy" eingetragen (Die "neuen" Empfängerlisten beziehen einen Teil ihres Dateinamens aus dieser Angabe). Je nachdem, wie Sie Ihre Replikatorziele genannt haben werden dann im entsprechendem Verzeichnis automatisch die zugeordneten RCVListen angelegt (RcvList-ReplA.RCV, RcvList-Repl.RCV etc.).

Jetzt im ReplClient Hauptschirm den gewünschten Zielreplikator auswählen und die Empfänger wie gewohnt eintragen. Der Eintrag in die richtige RCVList funktioniert automatisch, darum muss man sich nicht kümmern.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.