Ansatzpunkte für eine Archiv-DB

[skywook]

Hallo,
möchte gerne Dokumente in eine Archiv-DB kopieren. Habe folgende Ansatzpunkte. Für Verbesserungsvorschläge wäre ich dankbar.

- In der "Master"-DB soll über ein Profil-Dokument gesteuert werden: Pfad der Archiv-DB und nach wieviel Tagen (nach dem Erstelldatum) archiviert werden soll.

- Welche Variante würdet Ihr wählen:
1. Über eine Ansicht die zu Archivierenden Dokumente selektieren und dann per Agent in die Archiv-DB kopieren.
2. Oder über einen Agent alle Dokumente in der DB nach einem Selektionskriterium selektieren z.B. Archivdatum und dann in die Archiv-DB kopieren.

- Haltet Ihr es für sinnvoll in den Masken der Archiv-DB alle Felder auf berechnet setzen (Formel auf sich selbst) um etwaige Änderungen zu sperren.

Für weitere Tipps wäre ich euch dankbar.

[koehlerbv]

Zu Punkt 1: Das widerspricht Deiner (m.E. korrekten) Prämisse (und würde manuelles Eingreifen bedingen).
Zu Punkt 2: Das ist doch was, was Du als Prämisse genannt hast.

Zu Deiner letzten Frage: Wenn das ein richtiges Archiv sein soll, darf via ACL niemand (ausser Server) mehr Rechte als "Leser" haben. Damit sind jegliche Änderungen ausgeschlossen. Eine Designänderung wie von Dir genannt erlaubt nach wie vor Änderungen in Dokumenten, ist also untauglich.

Bernhard

[Gandhi]

Wenn die ArchivDB auch einen Effekt haben soll kommst Du auch meines Erachtens um eine Zeitsteuerung nicht  herum - da User generell die Tendenz haben im Zweifelsfall nicht zu archivieren.

[Tode]

eine Ansicht scheidet (wie von meinen Vorrednern gesagt) aus, weil sie keine "Dynamische" selektionsformel hat: Der Select kann kein Profildokument auslesen, und dessen Wert als Basis nehmen.

Deshalb : Agent erstellen, über db.Search (nicht FTSearch, das ist zu unsicher, wenn der FT- Index nicht aktuell ist) einen Select aus dem Profildokument zusammensetzen und dann die Collection verschieben.

Vorsicht: wenn Du eine Antworthierarchie verwendest, dann musst Du genau aufpassen, dass Du nicht Dokumente archivierst, die noch über Antwortdokumente verfügen.

Gruß
Tode

[skywook]

An Alle - Danke für die Infos 

Habe aber noch eine Frage: Würde gerne die Steuerung des Agenten komplett über das Profildokument durchführen lassen z.B. Selektionformel und das Ausführen-JaNein des Agenten.

Meine Vorstellung wäre. Der Agent läuft immer Nachts und prüft im Profildokument ob z.B.  der Haken bei aktiv gesetzt ist - dann tue was oder nicht.

Meine Frage muss der Agent vom Server gestartet werden oder reicht es wenn der Admin diesen in der DB einfach aktiviert.

[Gandhi]

Mehr oder weniger eine Frage des Gustos.
Möglich ist beides - wenn er regelmässig laufen soll, schreit das natürlich nach einem scheduled agent - ansonsten würde ich vom Administrator den Agenten auf dem Server starten lassen (sonst kann der arme Mensch während der Archivierung mit dem Client nicht mehr arbeiten).

[koehlerbv]

Ich denke, skywook meint eher die Signatur des Agents. Und die hängt davon ab, welche (bzw. wessen) Rechte zum Archivieren benötigt werden.

Bernhard

[skywook]

In der Archiv-DB hat der Server Schreibrechte und die User nur Leserechte. Somit müsste der Agent vom Server signiert werden. Oder liege ich da falsch.

Habe da leider noch ein paar Verständnisprobleme.

[koehlerbv]

Moment - was haben die User jetzt damit zu tun, ob der Agent mit der ID des Admins oder Servers signiert wird ? Der Signer braucht auf jeden Fall alle Rechte, die zum Lesen / Löschen aus der Quelle und zum Schreiben ins Ziel erforderlich sind.

Bernhard

[Gandhi]

Also in allen Umfeldern in denen ich bisher tätig war, hatten sowohl Server als auch Administratoren (zumindest effektiv) Managerrechte auf alle Datenbanken.
Dann wärs ziemlich wurscht, wer signiert.
Generell ist es aber eine gute Praxis alle Designelemente mit einer einheitlichen Signer ID zu befruchten - was ja dank run on behalf bei Agenten kein Problem mehr ist.
Der Vorteil kommt hier zwar nicht zum Tragen (da es vor allem die ECL Administration vereinfacht) aber man sollte es sich dennoch angewöhnen.

[skywook]

Signiert wird über den Admin-Konsole. Aber wo sehe ich denn mit welcher ID der Agent signiert wurde?
Wie sieht denn dann der Ablauf aus. Die Datenbank wird auf einem anderen Notes-Server installiert. Der mich als Admin nicht kennt. Somit wäre meine Signatur ja falsch. Muss dann der Admin dort zuerst die DB neu signieren damit alles funktioniert?

Wie schon gesagt, da fehlt mir noch ein wenig Backround

Zum Glück gibt es dieses Forum!!

[koehlerbv]

Muss dann der Admin dort zuerst die DB neu signieren damit alles funktioniert?

Genau so isses. Wer signiert hat, siehst Du in den Properties des Designelements - es ist der letzte Änderer. Entscheidend ist allerdings innerhalb des Designelements das Item $Signature. Dort findest Du den Signer auch eingetragen (u.a.).

HTH,
Bernhard