Selektive Replikation mit externen Variablen

    Hallo Miteinander,
    wiedermal eine Frage auf die sicher keiner ne Antwort hat.
    Wir müssen eine Große Datenbank auf den Notebooks der Außendienstmitarbeiter installieren. Damit sie aber nicht die kompletten 30 GB auf ihr Notebook gepackt bekommen wollen wir eine Relikationsformel benutzen. Soweit so gut. Jetzt kommt das eigentliche Problem. Es gibt für jeden Mitarbeiter Dokumente mit Feldern, welche lediglich die UserID nicht den Notesnamen beinhalten, da diese Dokumente via API von einem technischem User erzeugt werden. Jetzt hatte ich mir gedacht, Replikationsformel = Formelsprache, bedeutet ich kann @Environment benutzen und die UserID zusätzlich in die notes.ini packen, aber Fehlanzeige. Wenn ich die UserID in die Formel packe klappt alles, wenn ich dann aber die @Environment Funktion benutze geht nix. Hat jemand ne Idee was man da nutzen kann oder wie man auf eine externe Konfigurationsdatei zugreifen kann? Ich möchte nur sehr ungern für jeden User eine Datenbank mit eigener Replikationsformel anlegen.


    Viele Grüße Enrico

    es gibt aus meiner sicht 3 lösungsansätze die mir sofort dazu einfallen:


    a) leserfelder
    vorteil: keine superkompliziert zu wartenden rep.-formeln
    nachteil: der user kann auch serverseitig die anderen dok's nicht sehen.


    b) selektive rep.-formel pro user
    vorteil: ähm...keiner
    nachteil: etliche, z.b. schwer zu warten, user kann formel verseh. od. abs. ändern, formel wird dort berechnet wo sie gerade läuft - führt zu "unerklärlichen" ergebnissen


    c) sel. rep. mit gemeinsam-persönlicher (private on 1st use) ansicht in der server-db
    vorteil: user sieht serverseitig alles, lokal nur seins
    nachteil: bei sehr vielen usern wird die serverseitige db um etliches größer.


    noch was zur sel. rep.-formel pro user: könnte man den user mittels button und ein wenig script selbst erzeugen lassen, aber ist nur schwer zu warten das ganze...schon gar nicht nachträglich ohne weiteres änderbar.


    noch ne anmerkung zum feldinhalt - wenn bereits ein username drin steht, warum nicht mittels agenten auf den echten namen ändern lassen?

    Hallo Carsten,


    erstmal danke für die Antwort. Zur weitergehenden Erklärung. Also User können nix an der Datenbank ändern, da sie keinerlei Zugriff auf diese Datenbank haben. Lediglich der Technische User welcher im Hintergrund per API auf die Datenbank(konsistente ACL) zugreift kann Dokumente erzeugen/bearbeiten/etc. und auf die Serverreplik der DB zugreifen. (Die Replikation der Datenbank erfolgt auch über eine API Aufruf) In dieser Datenbank werden alle Office Dokumente gespeichert, welche aus diversen Anwendungen erzeugt werden. Um wieder zum eigentlichen Thema zu kommen, der Punkt Leserfelder und pers. Ansicht fällt raus, da alle mit dem gleichen technischen User auf der lokalen und auch der Serverdatenbank arbeiten. Bleibt noch die Lösung mit der ich angefangen habe, Replikationsfomel entweder eine pro User oder halt der scheinbar nicht mögliche Zugriff auf eine externe Variable.


    Gruß Enrico

    Ok...damit kommen gleich etliche probleme:


    - rep.-formel pro user in der server-db anlegen fällt aus da alle mit der gleichen id zugreifen.


    - leser- und designelemente fallen aus selbigen grund aus.


    - @environment fällt aus da es nicht in auswahlen verwendbar ist (übrigens auch alle anderen @funktionen die nicht ausschließlich auf die zu selektierenden dok's zugreifen)


    dann bliebe aus meiner sicht nur ein script, das einmalig von der user-workstation aus die lokale replik der datenbank erzeugt und dabei die replikationsformel auf beliebiger basis generiert. wichtig dabei ist dass die replikationsformel selbst unter keinen umständen mitrepliziert werden darf da ja jeder user eine eigene hat - für den server aber es sich immer um die gleiche person handelt weil alle die gleiche id verwenden. complicated - i know ;=)


    abhängig von der anzahl der user wärs sicher stabiler und weniger aufwand wenn man einfach x technische user-id's erzeugt. nur nochmal als anmerkung...

    Du schreibst:

    Zitat

    Die Replikation der Datenbank erfolgt auch über eine API Aufruf


    Wie meinst du das, die User replizieren den DB doch "normal" oder ??


    Du schreibst sonnst noch:

    Zitat

    Um wieder zum eigentlichen Thema zu kommen, der Punkt Leserfelder und pers. Ansicht fällt raus, da alle mit dem gleichen technischen User auf der lokalen und auch der Serverdatenbank arbeiten.


    Was ? Die user arbeiten doch mit ihren eigene ID's oder ???
    Wie sollten die dann unterscheiden wer was wo sehen darf ?
    Es muß einen unterscheidung geben, sonnst kannst du nicht unterscheiden.
    Wenn die admins (so wie du vorher gesagt hast) die user.id irgendwo in das dokument vergraben haben, sollte es auch möglich sein dieses feld in einen lesernamen feld zu ändern, und den user der berechtigung haben dürfen, dann zu geben.
    ZUSÄTZLICH solltest du dann einen Autoren feld für den Technische user, Admins und Server(n) anlegen, damit die auch berechtigung haben das dokument zu ändern.


    Zum replikations formel.. wenn du den für ein User erstellen möchtest, dann mußt der eh vom user oder vom admin dort eingetragen werden, und damit wäre einen variabele zwar schön, aber nicht sinnvoll.. deshalb könnte mann dort direkt den wert eintragen der du über einen variabele machen möchtest.


    Wichtig zu wissen ist das eine Replikations formel noch mehr tut als "nur" selektive dokumente holen.. es ENTFERNT auch dokumente die nicht den formel entsprechen.. wichtig zu wissen weil einen formel falsch rum geschrieben kann der KOMPLETTEN datenbank inhalt entfernen.. denk dran entfernen ist NICHT gleich löschen, weil beim löschen ein deletion stub wird dabei nicht erzeugt.