Sichtbar machen einer Collection

1. offizieller Beitrag

    Eigentlich möchte ich eine View erstellen in der die Select Anweisung variabel gestaltet werden können. Leider klappt es nicht, da beim öffnen dieser View keine Abfrageparameter übergeben werden können. Oder habe ich etwas verpasst????
    Nun kann ich ja per FTSearch eindeutige Dokumente in einer Collection catchen,bearbeiten u.s.w. Gibt es eine Möglichkeit diese temporäre Collection in irgenteiner Weise dem User sichtbar zu machen??? Habe vielleicht eine Lücke oder bin zu dämlich. Vielleicht kann mir jemand weiterhelfen.

    • Offizieller Beitrag

    mir fallen da 2 Dinge ein.


    Wenn Du immer die gleiche FT-Suche benutzt, dann speicher die Suche. Die funktioniert dann in einer Ansicht.


    Die 2. Möglichkeit ist es die Dokumnete in der dc in einen privaten Ordner zu legen.


    Gruß
    Dirk

    Rein logisches Denken verschafft uns keine Erkenntnis über die wirkliche Welt.
    Alle Erkenntnis der Wirklichkeit beginnt mit der Erfahrung und endet mit ihr.
    Alle Aussagen, zu denen man auf rein logischen Wegen kommt, sind, was die Realität angeht, vollkommen leer.
    Albert Einstein

    Hallo Diali,
    was meinst Du mit speichern? Ich würde es sowieso als eine Aktion laufen lassen.
    Nein, wenn ich immer die gleiche Suche hätte, dann würde ich es in der View ja mit Select ..... machen.
    Ich möchte folgendes erreichen: Bevor die View öffnet, per Box meine Suchkriterien erfassen z.B. Feld x: = variabell, Feld y = variabel. Nun genau diese Parameter kann ich beim öffnen der View nicht übergeben. Ein verschieben oder kopieren in einem Folder ist nicht so schön und vergrössert unötig die DB. Stelle Dir vor, das Ergebnis ergibt 30.000 Dokumente oder mehr.
    Das Produkt wird ein Reporttool. Z.Z. löse ich das Problem indem ich bestimmte Daten in Excel exportiere und dort können meine Kollegen dann Ihre Daten reporten wie sie wollen. Aber das kann nicht sein, das man per Script keinen Lösungsansatz vernünftig hinbekommt.
    Bin also für alle Ansätze dankbar.


    ron

    Die Datenbank wird durch das Verschieben in einen ordner nur sehr unwesentlich größer, denn die Dokumente werden ja nicht kopiert, sondern es wird nur festgelegt dass diese Dokumente in diesem Ordner angezeigt werden.
    Daher halte ich das für die sauberste Lösung wenn du es variable gestalten willst.

    Hi,


    ich weiß zwar nicht, wie häufig die Reports erstellt werden und ob diese Revisionssicher aufbewahrt werden müssen, aber als Alternative kannst Du Dir ja bei Notes abschauen, wie z.B. die LOG-Analyse läuft.
    Dort wird das Ergebnis der Recherche einfach in eine andere DB kopiert. Das hat mehrere Vor- und Nachteile:



    Vorteile:
    - evtl. spez. angepasste ACL
    - geänderte Masken - Felder nicht mehr bearbeitbar
    - in der DB stehen nur die gewünschten Dokumente -> kein Problem mit Ansichtsauswahl
    - man braucht nur die benötigten Felder exportieren
    - die Original-DB wird nicht belastet
    - beliebige Reports nach Deinen Wunschkriterien erstellbar


    Nachteile:
    - bei 30000 Dokumenten evtl. nicht wirklich schnell
    - evtl. viele Report-DBs

    Für jedes Problem gibt es eine einfache Lösung, die es noch schlimmer macht.

    ich favorisiere auch die Methode mit den Ordnern - habe ich selber schon so umgesetzt. Die Search - Methode dauert wirklich sehr lange und verbraucht auch viele Server-Ressourcen.


    Es wäre besser, wenn man die Suche einschränken könnte und nur nach bestimmten Feldern sucht. Dann könnte man eine Ansicht anlegen und mit GetDokumentsByKey zugreifen.

    Also im R6 funktioniert die Übergabe einer Selection Formula: einfach im Script ein NotesView-Object erstellen und dann über die Eigenschaft SelectionFormula setzen... man kann auch Spalten hinzufügen/löschen Spaltenformel ändern etc... ist eine brauchbare neue Funktion in R6! ;)

    ... und in der DB ist spätestens dann ein heilloses durcheinander, wenn mehrere Leute sich mehrere Reports erstellen und sich womöglich die selben Ordner/Ansichten "teilen" ...
    Alternativ kann man ja mit persönlichen Ansichten arbeiten - es ist aber wie bereits gesagt einfach "nur" ein Mengenproblem. Wenige Reports, die im Idealfall nur eine Person erstellt, können in der DB verbleiben - bei einer größeren Anzahl würde ich die ext. DB favorisieren. Wobei "größere Anzahl" sicherlich auch immer relativ ist :)

    Für jedes Problem gibt es eine einfache Lösung, die es noch schlimmer macht.

    Dazu Ordner werden vom indexer kaum berührt, während Ansichten vom indexer überarbeitet werden wenn sich dokument zahl ändert..
    Sprich wenn ein dokument den kriterien entsprechend hinzugefügt werden würde (oder entfernt) würde das den anzahl dokumente im ansicht ändern. Einen Ordner würde davon nicht berüht, und den auswahl bleibt den original zahl und damit erhalten.


    Wichtiges detail...