Replizierung der Datenbank Fehler - Datei nicht vorhanden??

  • Mahlzeit,


    habe folgende Fehlermeldung bei der Replizierung von einem R5 Client:


    Replizierung der Datenbank Fehler - Datei nicht vorhanden??


    Es sind noch weitere lokale Repliken anderer DB vorhanden und die funktionieren über den Hintergrundreplikator auch problemlos.


    1. Datei ist vorhanden und läßt sich sogar lokal auf dem Client öffnen.
    2. Habe zur Behebung von mögl. Cache Problem


    - Kachel + alle Repliken vom Desktop gelöscht
    - Desktop komprimiert
    - Notes beendet
    - Cache gelöscht
    - Neustart
    -> nix geändert


    3. Desktop5.dsk und bookmark.nsf geöscht und wieder nix


    Habe die DB in ein anders R5-System kopiert und dort lief es.
    Kann vielleicht jemand etwas zur Funktionsweise und Aufbau des Replikators etwas sagen, vielleicht würde dies ja einen schon weiterbringen.


    Kann jemand helfen??


    Gruß


    ---===gorden.s===---

  • Der Replikator nimmt sich den Dateinamen der Quelldatenbank, öffnet diese (sofern er kann) und holt sich aus den DB-Eigenschaften die Replik-ID.


    Mit dieser Replik-ID bewaffnet fragt er das Replizierungsziel, ob sich dort vielleicht eine Datenbank mit dieser ID finden läßt:


    - Gibt es 1 Replik auf dem Zielsystem, wird mit dieser repliziert.


    - Gibt es >1 Repliken auf dem Zielsystem, so wird die erste benutzt, die das Ziel zurückliefert.


    - Gibt es keine...dann wird nix repliziert.


    Bei Zielen mit mehreren Repliken die mit einer Quelle mit genau 1 Replik replizieren sollen kann man simple Quelle und Ziel austauschen um so die Replikation mit einer bestimmten Replik durchzuführen.

  • Danke für die schnelle Info,
    Also...
    "Der Replikator nimmt sich den Dateinamen der Quelldatenbank, öffnet diese (sofern er kann) und holt sich aus den DB-Eigenschaften die Replik-ID."


    Mit Quelle meinst Du sicherlich die DB lokal.
    Nur wann kann er nicht? Also das Betriebssystem ist mal außen vor, denn bei FAT 32 werden keine Rechte gesetzt, höchstens Attribute.
    Und hier sind keine definiert. Und auf der DB hat sich nix geändert. Der User wurde in eine Gruppe gepackt und darf auf die DB.


    Die Frage ist, ob er diese Schritte noch macht oder schon bockt?


    Kann man die einzelnen Schritte nicht Protokollieren lassen?


    Gruß


    ---===gorden.s===---

  • Zitat

    Mit Quelle meinst Du sicherlich die DB lokal.


    Nein. Wenn ich lokal gemeint hätte, dann hätte ich auch lokal geschrieben. Aber im Falle der Client-Hintergrund Replizierung hast du schon Recht, dass die Quelle die lokale Replik ist.


    Zitat

    Also das Betriebssystem ist mal außen vor, denn bei FAT 32 werden keine Rechte gesetzt, höchstens Attribute.


    Das ist so nicht ganz korrekt. Mit der tollen "Erfindung" der langen Dateinamen gibt es gerade bei FAT32 auch ein paar Nebeneffekte.


    Fakt ist z.B., dass eine Datei zwar einen langen Namen haben kann, aber intern dennoch einen 8.3-Namen behält. Was zu lustigen Effekten führen kann. Diesen Namen behält eine Datei selbst dann, wenn man sie nachträglich ändert oder - noch viel besser - wenn man eine solche Datei kopiert ändert sich der 8.3-Name obwohl der sichtbare Name scheinbar unverändert bleibt.


    Beispiel:


    meinedatenbank.nsf hat z.B. nach dem Anlegen noch den 8.3-Namen
    meined~1.nsf


    Kopiere ich die Datei jetzt mal im gleichen Verzeichnis per Copy & Paste erhält sie die Namen:


    kopie von meinedatenbank.nsf (super samt leerzeichen) und den 8.3-Namen
    meined~2.nsf


    lösche ich jetzt das Original und benennen die Kopie um entsteht:
    meinedatenbank.nsf aber diesmal mit dem 8.3-Namen der Kopie
    meined~2.nsf


    Also kann es sehr wohl sein, dass deine Datenbank über einen [nicht [mehr] existierenden] xxxx~? 8.3 Namen referenziert wurde. Ausschließen würde ich es nicht.


    Ich würde zuerst mal prüfen, ob die Datei auch einen 8.3 Namen hat und diese auch darüber öffnen. Alternativ, wenn sich die Datei im Data-Verzeichnis befindet geht der Test auch andersrum, nämlich erst die Serverreplik öffnen und dann lokal nach einer Replik davon (also ohne Dateinamen, über die ID) suchen lassen.

  • moinsen nochmal,
    konnte mich erst jetzt wieder mit dem Problem beschäftigen.
    Also die DB ist absolut 8.3 konform. DB-Name besteht eh nur aus 4 zeichen. (xxxx.nsf) Also, das es daran liegt, ist sehr unwahrscheinlich. Die Tatsache, das die DB in einem anderen Win98 sich öffnen und replizieren ließ spricht auch dagegen, das etwas mit der DB nicht stimmt. Der Replikator funktioniert auch, da weitere DB´s vom gleichen Server problemlos repliziert werden.


    Ich bin irgendwie ratlos.....???


    ---===gorden.s===---

  • Also, nur um sicher zu gehen wo und wie der Fehler genau auftritt:


    1. Workspace (Kacheldesktop) aufmachen


    2. Alle verbliebenen Kacheln der DB mit der <ENTF>-Taste beseitigen


    3. Desktop 1x komprimieren (Rechtsklick => Eigenschaften => Komprimieren)


    4. lokale Replik mittels Datei => Datenbank öffnen... wieder dem Desktop hinzufügen


    5. Rechtsklick auf Kachel => Eigenschaften (Name der Datei nochmals prüfen), Datenbank 1x per Doppelklick probehalber öffnen und schliessen


    6. Rechtsklick auf Kachel => Replizierung => Replik suchen... und hier den Server angeben


    7. Datenbank (diesmal die Serverreplik) 1x per Doppelklick probehalber öffnen und schliessen


    8. Rechtsklick => Replizierung => Replizieren => Replizierung mit Optionen


    9. OK startet Replikation


    An welcher Stelle kommt jetzt ein Fehler und wo wird dieser ausgegeben (Screenshot bitte).

  • Moinsen,


    danke für die super Beschreibung!http://www.dominoforum.de/uploads/smil418b6ca82ecaa.gif
    http://www.dominoforum.de/uploads/smil418b6ca82ecaa.gif


    Der Bug lag anscheinend innerhalb des Desktop.
    Das man alle DB´s löschen soll, war mir bisher unbekannt. Bislang hat es bei Problemen immer gereicht die entsprechende DB vom Desktop zu löschen. Aber man lernt ja nie aus.... ;)


    Danke für die Info.


    Gruß


    ---===gorden.s===---