|
1. Abfolge von Bestandsexport und Änderungsabgleich |
|
Haben Sie ein Änderungsprotokoll exportiert, ist es nicht unbedingt erforderlich, dass Sie auf dem externen Rechner anschließend einen aktuellen Bestandsexport aus dem Zentralsystem einspielen. Es ist also durchaus möglich, dass von einem externen Rechner aus täglich ein Änderungsprotokoll in das zentrale Büro geschickt wird, dieser Rechner aber nur wöchentlich einen neuen Bestandsexport erhält.
Ein regelmäßiger Bestandsexport ist nur dann erforderlich, wenn es als wichtig erachtet wird, dass die im Zentralsystem vorgenommenen Neuanlagen und Änderungen zeitnah auch auf den externen Rechnern verfügbar sind.
Zumindest dann, wenn der Abgleich über USB-Stick oder das Netzwerk erfolgt, empfehlen wir, immer in beide Richtungen abzugleichen, weil sich der zusätzliche Aufwand in Grenzen hält.
Dann wäre der reguläre Ablauf eines "Austauschtermins" per USB-Stick folgender:
- USB-Stick in externen Rechner stecken
- Änderungsprotokoll auf USB-Stick speichern
- USB-Stick entfernen
--------------------- (Ortsveränderung) -----------------------
- USB-Stick in einen der zentralen Arbeitsplatzrechner stecken
- Änderungsprotokoll einlesen
- Bestandsexport auf USB-Stick
- USB-Stick entfernen
--------------------- (Ortsveränderung) -----------------------
- USB-Stick in externen Rechner stecken
- Datenbank einspielen
Kann ein Laptop zum Datenaustausch direkt an das Netzwerk gehängt werden, geht es natürlich einfacher und schneller:
- Laptop ans Netzwerk hängen
- Änderungsprotokoll in den zentralen Replikationsordner speichern
- Änderungsprotokoll von einem der zentralen Arbeitsplatzrechner aus einspielen
- Bestandsexport direkt auf den Laptop |
zurück zu den Fragen |
2. Datensicherung und Bestandsexport |
|
Beim Bestandsexport wird eine komplette POLARIS-Datenbank angelegt, d.h. die Dateien POLRS_1.MDB bis POLRS_7.MDB. Damit entspricht der (vollständige) Bestandsexport im Prinzip einer Datensicherung. Allerdings gibt es Detail einige Unterschiede, weswegen eine über die Datensicherung entstandene Kopie der Zentraldatenbank nicht für die Replikation geeignet ist.
Umgekehrt kann aber eine Replikationsdatenbank notfalls in eine Zentraldatenbank umgewandelt werden, falls nach einem Datenverlust keine „richtige“ Datensicherung verfügbar ist, was natürlich nur dann hilfreich ist, wenn sie nicht nur den Bestand eines Vermittlers enthält. Wenden Sie sich in so einem Fall bitte an den Support der Firma Gallwitz!
Unabhängig davon sollten Sie auch und gerade bei der Verwendung der Replikation regelmäßig ihre Zentraldatenbank sichern! Wie anfangs beschrieben kann eine Fehlbedienung oder auch eine Fehlfunktion, die bei Software nie hundertprozentig ausgeschlossen werden kann, in ungünstigen Fällen ein erhebliches Datenchaos verursachen.
Bedenken Sie auch, dass bei einem Verlust der Zentraldatenbank u.U. auch die in den externen Datenbanken erfolgten Änderungen unbrauchbar werden, d.h. nicht zurückgespielt werden können, nämlich immer dann, wenn der den externen Datenbanken zugrundeliegende Bestandsexport erst nach der letzten verfügbaren Datensicherung erfolgt ist.
|
zurück zu den Fragen |
|
Jeder Datensatz, egal ob es sich nun um einen Kunden, einen Vertrag, eine Telefonnummer, ein Zusatzrisiko oder einen Vorgang handelt enthält eine fortlaufend vergebene, eindeutige Nummer. Im Falle der Vorgangsverwaltung entspricht diese der Vorgangsnummer, bei den Dokumenten der Dokumentennummer und bei den Kunden der Kundennummer (letzteres allerdings nur, wenn eine automatische Vergabe der Kundennummer eingestellt ist). In den anderen Fällen ist diese Datensatznummer für den Anwender unsichtbar und nicht direkt von Bedeutung.
Intern werden die Datensätze (Kunden, Telefonnummern, Bankverbindungen, Personen, Verträge etc.) über diese Nummern miteinander verknüpft. Außerdem bezieht sich jeder Änderungs- oder Löschbefehl auf einen Datensatz mit einer bestimmten Nummer („Ändere beim Datensatz Nummer 1234 das Feld ‚Ort’ in ‚Hamburg’“ oder „Lösche den Datensatz mit der Nummer 3456“).
Das Grundproblem bei der Datenreplikation besteht nun darin, dass die auf einem externen Rechner neu angelegten Datensätze Nummern erhalten können, die auf dem Zentralsystem bereits anderweitig vergeben wurden. Das bedeutet, dass diese Nummern beim Zurückspielen der Änderungen neu vergeben werden müssen, was sich auch auf sämtliche verknüpften Datensätze auswirkt.
Dies ist auch der Grund dafür, daß POLARIS sich strikt weigert, Änderungsprotokolle einzuspielen, die aus einer „fremden“ Datenbank generiert wurden oder aus anderen Gründen nicht „passen“: Wird eine Änderung an einem auf dem externen neu angelegten Kunden vorgenommen, obwohl der Protokolleintrag zur Anlage des neuen Kunden fehlt, wird diese Änderung an einem falschen Kunden vorgenommen, der nur zufälligerweise die gleiche Datensatznummer hat, die der neue Kunde auf dem externen Rechner vorläufig erhalten hat.
Aus der Problematik der sich ändernden Datensatznummern folgt, dass Kunden-, Dokumenten- und Vorgangs- bzw. Archivnummern auf den externen Rechnern immer als vorläufig zu betrachten sind! Ist eine automatische Vergabe der Kundennummer eingestellt, wird deshalb statt dieser Nummer „-99999“ vergeben, um den Anwender an diesen Zustand zu erinnern.
Die endgültigen Nummern ergeben sich erst beim Importieren der Änderungen in die Zentraldatenbank. Sie sollten es deshalb vermeiden, diese Nummern schon vorher schriftlich festzuhalten oder ihren Kunden mitzuteilen! |
zurück zu den Fragen |
4. Wichtig – unbedingt beachten! |
|
Wie bereits zu Beginn angemerkt, erfordert die Anwendung der Replikation Sorgfalt von allen Beteiligten und außerdem gewisse Grundkenntnisse im Umgang mit USB-Sticks bzw. Netzwerklaufwerken, Ordnern, Dateien etc.
Anders als bei den meisten anderen Funktionen in POLARIS kann beim „Herumprobieren“ mit der Replikation erheblicher Schaden (Datenverluste von externen Rechnern, Datenchaos in der Zentraldatenbank) angerichtet werden. Bitte beachten Sie deshalb unbedingt folgende Punkte:
- Geben Sie, falls dies nicht ohnehin schon der Fall ist, möglichst vor der Aktivierung der Replikation jedem beteiligten Rechner einen eindeutigen und möglichst sinnvollen Netzwerknamen. Die spätere Umbenennung externer Rechner ist zwar möglich, kann in bestimmten Phasen der Replikation aber zu Problemen führen.
- Nennen Sie niemals von der Replikation erzeugte Dateien (*.RPL) um und schon gar nicht auf den Namen eines anderen Rechners (der Dateiname enthält den Rechnernamen). POLARIS würde die Daten beider Rechner vermischen und damit ein unauflösbares Datenchaos verursachen.
- Löschen Sie niemals RPL-Dateien, außer wenn Sie genau wissen, was sie tun. Im Zweifelsfalle sollten Sie diese Dateien in einem separaten Ordner archivieren. Lieber eine Datei zuviel aufheben als eine zuwenig!
- Löschen oder überschreiben Sie niemals eine Datenbank auf einem externen Rechner, bevor Sie sicher sind, dass das Änderungsprotokoll exportiert wurde oder – noch sicherer! – die Änderungen in das Zentralsystem übernommen wurden.
- Kopieren Sie niemals Datenbankdateien "von Hand" in einen POLARIS-Datenordner. Dabei kann nämlich keine Überprüfung erfolgen, ob die überschriebene Datenbank noch unverarbeitete Änderungen enthält; es droht ein Datenverlust!
- Verwechseln oder vermischen Sie bitte nicht Zentraldatenbank, Replikat-Datenbanken und Datensicherungen! Eine Datensicherung kann nicht ohne Weiteres als Replikat verwendet werden oder umgekehrt.
- Verändern Sie niemals das Rechnerdatum, wenn Sie mit Replikationsfunktionen arbeiten! Achten Sie darauf, daß die Datums- und Zeiteinstellungen auf Zentralsystem und auf den externen Rechnern einigermaßen übereinstimmen (auf ein paar Minuten Unterschied kommt es aber nicht an). Datenchaos kann durch eine Zeitabweichung zwar nicht entstehen, aber es könnte zu „seltsamen“ Abfolgen in Protokollen kommen.
- Achten Sie auf neue Updates! Wenn Sie die Replikation verwenden, empfehlen wir aus Sicherheitsgründen dringend, alle Update möglichst zeitnah sowohl auf dem Zentralsystem als auch auf den Laptops einzuspielen.
- Sollten beim Verwenden der Replikation Fehlermeldungen auftauchen, die Sie sich nicht erklären können, nehmen Sie bitte Kontakt mit dem Support auf! Das Ignorieren oder Mißverstehen von Fehlermeldungen könnte unerwünschte Folgen bis hin zu Datenverlusten haben.
|
zurück zu den Fragen |
|
|