Dokumente in andere Datenbank kopieren

  • Hi !
    ich möchte bestimmte Dokumente in eine andere Datenbank kopieren.
    Die Ziel- + Start Datenbank liegt in einem Domino Cluster und wird noch auf andere Server repliziert.


    Ich kopiere die Dokumente mit einem Agenten und der einfachen Aktion "In Datenbank kopieren".
    Die bestehenden Dokumente in der Ziel-Datenbank werden vorher alle gelöscht, da die Dokumente komplett in die Zieldatenbank kopiert werden.
    Das funktioniert auch alles.


    Mein Problem:
    Die neu kopierten Dokumente werden vom Replikator nicht als "neue" Dokumente erkannt und somit nicht in die anderen Datenbanken auf den anderen Servern repliziert.
    Wenn ich die Dokumente per Copy&Paste händisch in die Ziel-Datenbank kopiere ist es kein Problem.
    Was kann ich tun, um das händisch automatisch abzubilden ?!


    Jeder Hinweis ist gern genommen. ?(


    Steffi

  • Soweit ich weiß, erhält dieser Weg die GUID des Dokuments. Wäre dem so, könnte ich verstehen, warum der Replicator meint, keine Änderungen vorzufinden.

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • Versuch es mal mit NotesDocument.CopyToDatabase.
    Die Hilfe sagt: "CopyToDatabase also saves the new document." ... also sollte der Logik halber, die ID hinterher auch eine andere sein.

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • Nope


    Aber die Beispiel in der Hilfe sollten eigentlich ausreichen. Stichworte: NotesDatabase, AllDocuments, GetFirstDocument, CopyToDatabase.

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • Hmm, mit den standard agenten wird ein neues dokument erzeugt.. und nicht eins mit den Gleichen NoteID, sprich es ist ein neues Dokument auf diesen weg.
    Kannst du mal schauen WANN ein solches dokument in der Ziel datenbank erstellt würde (Weil das erstellungsdatum IST der ID vom Dokument [UNID und nicht NoteID, Sorry Ralf, mistverwechselung] ), wenn der Älter ist als den Zeitpunkt welches der Agent läuft, dann übernimmt der den erstellungsdatum des Original dokument. Allerdings sollte dann TROTZDEM der eingang in dieser datenbank wert auf den Zeitpunkt des Agenten stehen.


    Ich vermute eher das irgendwas beim Replication kaputt ist, als das es den Agent kopiererei als ursache hat.


    Melde mal die erstellungs und verarbeitungs zeitpunkte eines dokument im Original und als kopiertes dokument.

  • Sorry, ich muss widersprechen: das Datum ist nicht die NoteID. Die NoteID ist im Grunde nur ein laufender Zähler und kann daher bei zwei replizierten Dokumente unterschiedlich sein. Das Datum ist eigentlich die UNID und das ist, worauf (u.a.) der Replikator schielt.

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • Sorry meinerseits, Ralf: Die NoteID ist zeitabhängig, aber eben nur auf die jeweilige Datenbank. Wie sind beispielsweise NotsDocumentCollections sortiert? Richtig ... Und in jeder DB ggf. anders. Weil: Genau!


    Sabine: Ohne diesen Fall untersucht zu haben, bleibe ich bei meiner Meinung - "Finger weg von "Simple Actions", diese sind auch nur für simple Gestalten, die nichts besonderes erwarten" (obwohl manchmal "bseonderes" geschieht - ich glaube auch in diesem Fall nicht daran, dass deshalb der Replicator nicht anspringt, sorry).


    Bernhard

  • Ok, ich will jetzt keinen Streit vom Zaun brechen, deshalb der Verweis auf What are the components of a Note ID?


    typedef struct {
    DBID File; /* Unique (random) number */
    /* (Even though this field is called "File," */
    /* it doesn't have anything to do with the file!) */
    TIMEDATE Note; /* Original Note Creation time/date */
    } UNIVERSALNOTEID; #define UNID UNIVERSALNOTEID
    "If database A contains a note with a particular UNID and database B contains a note with the same UNID, the replicator concludes that these two notes are replica copies of one another."
    Mit anderen Worten: a) ein Zeitstempel und b) der Replikator springt darauf an



    Zur NID ist leider kein struct angegeben, nur so viel:
    "The NID is the file position of the Record Relocation Vector (RRV) for the note. An RRV is a DWORD offset in a file. (...) Since a note ID is specific to the database file that contains it, replica copies of the same note in other databases will most likely have a different note ID."
    Also: ein laufender Zähler.


    Im verlinkten Dokument sind noch weitere IDs angegeben ... nach welcher davon die NotesDocumentCollection sortiert ist, müsste man mal austesten ... habe ich aber (mit Verlaub) grad keine Lust zu. Mal schauen, ob ich das nachreichen werde. Interessieren tut es mich jedenfalls auch.

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • Nachtrag:
    ein schneller Blick in die Hilfe zeigt:
    a) ein FTSearch auf die NotesDatabase gibt eine nach Relevanz sortierte NotesDocumentCollection zurück. Das war zu erwarten.
    b) ein Search auf die NotesDatabase gibt angeblich eine unsortierte NotesDocumentCollection zurück. Das mag ich nicht so ganz glauben, da intern nach irgendeiner ID ganz sicher sortiert wird.


    Es hat aber noch eine ganze Menge andere Methoden anderer Klassen, die eine NotesDocumentCollection zurück geben. Leider steht da nicht, ob und wie sie sortiert sind. Wie gesagt: müsste mal ausgetestet werden...

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • Und auch wenn UNID gleich ist, kann dieses durchaus durch andere feldwerte zur replication kommen. Dafür gibt es noch viele andere zeitwerten und Secquenznummern die dazu beitragen.


    Wie gesagt, schau die Dokumente in den beide datenbanken an, und vergleiche die verschiedene datumswerten, ERST dann kann mann einen zutreffende aussage machen ob die gleich sind, oder ob die nur den gleichen feldwerte haben. Bis dahin ist es egal ob UNID oder NoteID gleich sind/wären.


    Übrigens.. Wenn 2 Datenbanken KEINE Replieken sind, dann ist es egal welche UNID oder NoteID die (neue) dokumente haben. Replizieren tut es nur unter replieken. Wenn ich also ein Dokument X in einen anderen DB schiebe (egal auf welcher weg!) und es in diesen Datenbank(replieken) also dann erst erstellt wird, MUSS das dokument repliziert werden, egal wann das letzte mal repliziert würde, weil es ist ein neues dokument, welches in keine der andere replieken da ist. Wenn es NICHT Repliziert, dann ist etwas falsch an dieses dokument (z.B. es darf nicht gelesen werden von den andere replieken), oder es ist einen Selectieve replications formel eingestellt der das dokument ausschließt.

  • Nur so nebenbei: In einem Szenario, in dem man ein Dokument immer wieder löscht und erneut reinkopiert, ist es im Normalfall so, dass die Kopie wieder die SELBE unid bekommt... Dieses Dokument bei IBM erklärt das Phänomen.


    Und das führt zu "seltsamem" Verhalten bei Replikationen (Replizierkonflikte, nicht stattfindende Replikation, etc.)


    Abgesehen davon ist es eine sehr schlechte Idee, immer alles zu löschen, und neu zu kopieren... Schlecht für die Datenbank, schlecht für die Performance, schlecht aus diversen Gründen...