Selection von Dokumenten einer View mit Schlüsselwort

1. offizieller Beitrag

    Hallo,


    ich brauche Hilfe bei folgendem Problem: In einer Notes-6.5-DB sind Dokumente mit 9 Feldern abgelegt. Feld 2 allerdings KANN Unterfelder enthalten. Das Suchwort ist entweder in Feld 2 oder einem der eventuell vorhandenen Unterfelder enthalten. Da in der Datenbank ca. 52000 Dokumente vorhanden sind, ich aber nur ca. 200 davon brauche, möchte ich wissen, wie ich ein Subset nur mit den interessierenden Dokumenten erhalten kann. Meine Versuche mit GetAllDocumentsbyKey bzw. GetAllItemsbyKey sind kläglich gescheitert. Noch eine Besonderheit: Ich arbeite von MS-Access aus und greife von VisualBasic auf die Notes-DB zu. Dadurch muss ich zunächst auf doc.ColumnValues(2) mit


    str_X = doc.ColumnValues(2)


    zugreifen. Enthält dieses Unterfelder, wird Fehler-Nr.err=13 ausgelöst. Daraufhin setzte ich einen String str_X wie folgt zusammen:
    I=0
    While err <>9
    str_X = str_X + doc.ColumnValues(2)(I)
    I = I + 1
    wend


    Da die Anzahl der Unterfelder variiert, läuft die Schleife solange, bis Fehler Err = 9 auftritt.


    Mit dieser Methode komme ich zwar zum Ziel - die Laufzeit ist aber unter aller Diskussion. Daher der Gedanke, direkt von Notes ein Subset anfordern zu können.


    Vielen Dank für jeden Hinweis im voraus.

    Probiers mit einer normalen Suche.


    db.Search( formula$, notesDateTime, maxDocs% )


    Bsp.
    db.Search( |Feld1="x" & Feld2="y"|, nothing, 0)


    nothing = keine Zeitbegrenzung der Dokumente
    0 = Keine Begrenzung für Anzahl gefundener Dokumente

    So is das mit dem Licht, mal brennt's und mal brennt's nicht.

    Das halte ich für -im besten Fall- suboptimal. Eine Suche kann ich unter 2 Bedingungen durchführen: auf einer volltextindizierten DB oder einer nicht indizierten DB. Im ersteren Falle möchte man bitte die FTSearch-Methode nehmen. Warum, dürfte klar sein...
    Ist die DB nicht indiziert kannst du gute Chancen haben, dass dein Statement diese Meldung auf die Konsole wirft:

    Zitat


    Warning: Agent is performing full text operations on database 'xxxxx.nsf' which is not full text indexed. This is extremely inefficient.


    Ärgerlicherweise kann ich meinen Usern nicht verbieten, eigene Agenten laufen zu lassen. Aber immer wenn ich das sehe, krieg ich den Hass. Denn es zeugt IMO von einer grundsätzlichen Verständnislücke und einer ebenso grundsätzlichen Mir-egal-Haltung dem Server, seiner Last und der Beeinträchtigung anderer User gegenüber.


    Macht das ein Agent in einer DB und krebst der Server nicht ohnehin schon bei 99,95% Last vor sich hin, mag das noch angehen. Auf Servern mit einigen hundert (Mail-)DBs und Usern, haut das aber tierisch ins Konto. Insofern, würde ich mir ernsthaft wünschen, IBM würde dieses Konstrukt lieber gestern als heute rausnehmen...


    Da mir auf Anhieb auch kein sinniger Grund einfällt, warum man das Statement überhaupt verwenden sollte, finde ich es eben suboptimal, es so unkommentiert zu posten...

    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

    • Offizieller Beitrag

    RockWilder
    ist der Entwickler ein Freund des Admins :D , fragt dieser ab, ob die DB:
    - flag = notesDatabase.IsFTindexed
    und je nach Flag und Zugriffsrechten des Users erzeugt der Entwickler mit
    - Call notesDatabase.CreateFTIndex( options& , recreate )
    einen neuen Index
    oder führt einen
    - Call notesDatabase.UpdateFTIndex( createFlag )
    aus.


    Geht dies wegen der Rechte nicht wird eine Meldung ausgegeben:
    "Wenden Sie sich an Ihren Domino-Administrator, der kann einen FT-Index auf die DB erstellen."


    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

    • Offizieller Beitrag

    ähm ... lese gerade ... 52000 Dokumente und dann keinen Index und Suchen, da wird selbst der temp. FT-Index aussteigen!


    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

    Jupp, und zwar ziemlich schnell. Erlaubt sind 5.000 Dokumente per default, es sei denn, man dreht das per ini-Eintrag hoch.


    Die UpdateFTIndex-Methode... Wartet der Agent eigentlich, bis das Statement fertig ist, oder macht er sofort mit der nächsten Zeile weiter? Weil, im ersten Fall kann so ein Agent bei ungünstigen DB-Design und/oder einem Uraltindex ziemlich lange dauern, was dem User vielleicht nicht gefällt, oder zumindest spanisch vorkommt (wir alle kennen die kurze Geduldsspanne bei Usern: "klick" ... "einundzwanzig...zweiundzwanzig...dreiundzwanzig..."klick"...einundzwanzig"klickklickklickklick"). In letzterem Fall kann der Agent auf die Nase fallen, wenn er im weiteren Verlauf eine indizierte DB erwartet, der Updater aber noch nicht durch ist...

    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

    Ich habe von einer Search und nie von einer FTSearch gesprochen(geschrieben). Wenn diese eine ähnlich schlimme Performance verursachen sollte bitte ich um Info.

    So is das mit dem Licht, mal brennt's und mal brennt's nicht.