Verwirrung: Agent manuell aufgerufen geht - per Script nicht -> hä?

[Basti*]

Hallo zusammen,

hab hier ein merkwürdiges Verhalten bei meinen Scripten. Ich habe eine Ansicht mit einem ImportButton, der hat quasi folgenden Code

Code

@Command( [RunAgent] ;"Delete");  
@Command( [RunAgent] ;"Import");
@Command( [RunAgent] ;"Update");

Es passiert (normalerweise) folgendes:

Delete: Alle Dokumente mit Form="abc" (per db.ftsearch) werden gelöscht.
Import: Eine CSV-Datei wird geladen und es wird für jede Zeile ein neues Dokument (Form="abc") erzeugt
Update: ich suche (per db.ftsearch) ein Dokument (form="xyz") und aktualisiere Daten

Zwischendurch wird der db.index laufend aktualisiert.

Auf dem autarken Entwicklungssystem (lokal) klappt das wunderbar.

Auf dem Server (8er) klappte(!) das bis vor kurzem auch! Jetzt haben wir vor ein paar Tagen hier die 8.5er Clients bekommen. Und nun gehts nicht mehr.

Das Delete geht. Auch der Import. Aber beim Update findet er scheinbar keine Dokumente bei der Suche. Das erste Dok ist bereits leer:

Code

...
query$ = |(FIELD FORM = "abc")|
Set dc = db.FTSearch(query$,0) 	
Set doc = dc.GetFirstDocument

While Not (doc Is Nothing) 
    count = count + 1
    ...
    ...
Wend
...

count bleibt null => doc ist nothing

Erst wenn ich den UpdateAgent manuell über das DropDownMenü Aktionen aufrufe, geht es.
Hat jemand eine Idee, woran das klemmt?
Liegt das am Aufruf der Scripte über die Agents?

Basti

[Peter Klett]

Die Ursache für Dein Problem kenne ich nicht, ich würde aber die Suche der Dokumente nicht über einen FTSearch machen, sondern über einen Search. Beim Search gibst Du eine Selektionsformel wie bei einer Ansicht ein. Wenn ich das richtig verstehe, suchst Du im Volltext nach Dokumente die in einem Feld genau einen Wert haben, und da ist Search viel besser.

query$ = |FORM = "abc"|
Set dc = db.Search(query$, Nothing, 0)    
Set doc = dc.GetFirstDocument

While Not (doc Is Nothing)
    count = count + 1
    ...
    ...
Wend

[Glombi]

Ich würde überhaupt nicht suchen, sondern ein Ansicht verwenden, deren erste Spalte nach Form sortiert ist.

Die Collection bekommst Du dann mit
set view = db.GetView("Name der Ansicht")
-> hier evtl. sicherheitshalber:call view.Refresh
set dc = view.GetAllDocumentsByKey( "abc", True )

Andreas

[Basti*]

Ja, das Suchen per Anischt hatte ich anfangs auch. Dabei hatte ich irgendwann das Problem, dass ich aus welchen Gründen auch immer "GeisterDokumente" hatte. Die waren da, wurden aber in der Ansicht nicht angezeigt.

Bei einer anderen Suche, die dann über db.ftsearch lief (weil mehrere Felder vergleichen wurden), wurden die dann doch gefunden und haben Chaos verursacht. Hat mich n paar Stunden & Nerven gekostet, bevor ich geschnallt hatte, dass dort noch ein "Geist" sein Unwesen treibt. Per db.ftsearch wurden diese Geister gefunden und konnte gelöscht werden. Daher bin ich bei db.ftsearch gelandet.

Kennt ihr derartige GeisterDokumente und wisst, wie die zustande kommen?

Basti

[flaite]

Interessant zumindest für mich, der wo gewaltige praktische Lücken im Umgang mit Lotus Domino angesammelt hat.
Kannst Du bitte vorher einmal den Volltext-Index noch mal neu aufbauen und dann den Agenten noch mal starten?
In meiner aktiven Zeit hätte ich immer die Lösung von Andreas gewählt.

[Basti*]

Kannst Du bitte vorher einmal den Volltext-Index noch mal neu aufbauen und dann den Agenten noch mal starten?

Vor dem Aufruf von db.ftsearch wird der DB-Index automatisch per Script aktualisiert.

If ( db.LastModified > db.LastFTIndexed ) Then
   Call db.UpdateFTIndex(False)
End If

Das müsste doch identisch mit dem manuellen Neuaufbau sein, oder?

[Peter Klett]

Notes produziert von sich aus keine "Geisterdokumente" (außer Replizier- und Speicherkonflikte, falls man die dazu zählen möchte). Es könnte sich dabei um Überbleibsel aus missglückten Funktionen handeln. Wenn zum Beispiel Dokumente erstellt wurden, ohne das Feld Form zu füllen und in allen Ansichten nach Form selektiert wird, sind die nicht sichtbar. Ein FTSearch (oder auch ein Search) findet die natürlich, wenn nach anderen Feldern gesucht wird, ohne dass Form berücksichtigt wird.

Zur Diskussion Ansicht vs. Search

Ich bevorzuge ein Search, da dann vom Server keine Ansicht aktualisiert werden muss. Die fehlende Ansicht kann natürlich auch nicht kaputtgehen. Natürlich ist ein Search langsamer als eine Ansicht, da ja praktisch eine temporäre Ansicht aufgebaut werden muss. Unschlagbar ist ein Search, wenn Username und/oder Datum im Select enthalten ist. Natürlich ist der Kontext auch wichtig zu beachten. Ist es eine Useraktion, bei der Performance sehr wichtig ist, ist eine Ansicht vorzuziehen, bei Hintergrundagenten, die nachts laufen, und bei denen es nicht darauf ankommt, ob sie ein paar Minuten langsamer sind, halte ich Search für die erste Wahl. Ein "Richtig" oder "Falsch" gibt es allerdings m.E. nicht.

[Basti*]

Suchmethoden sind doch immer wieder ein spannendes und nicht ganhz unwichtiges Thema

In wiefern können Ansichten kaputt gehen?

Wie schaut es mit der Performance bei Ansicht vs. Search vs. FtSearch aus? Ich habe in der DB gut 120.000 Dokumente.

Wie ist das bei dieser Anzahl an Dokumenten beim Suchen, wo ich mal ein Dokument oder mal eine Handvoll finden möchte? Ist da Ansicht, die normale Search oder dann doch ftSearch besser? Man könnte ja Ansichten für die wichtigsten Abfragen bauen. Dann stapeln sich aber die VerwaltungsAnsichten ... schlimm?

Wie sollte man btw. eine unscharfe Suche realisieren? Ich möchte Dokumente finden, die irgendwo in einem der Felder z.B. ein "ABCD" stehen haben, aber auch "ABCF" oder "ABC-D". Wenn ich das richtig im Kopf habe, dann geht das doch nur über die db.ftsearch, oder?

[Peter Klett]

Bei Ansichten kann der Ansichtsindex kaputtgehen, der muss dann administrativ neu aufgebaut werden. (z.B. mit einem load updall -r)

Früher habe ich alles über Ansichten realisiert, damit waren sehr viele (sogar zu viele, weil ich es allgemeingültiger hätte machen können) Ansichten vorhanden. Und ab und zu ging auch mal eine kaputt (natürlich nur unter Notes 4, heute passiert sowas bestimmt nicht mehr  ).

Beim nächsten Projekt bin ich vom einen Extrem zum anderen gegangen und verwende heute kaum versteckte Ansichten (sichtbare Ansichten benutzte ich natürlich niemals für Agenten oder andere Funktionen). Bisher (also in den letzten sieben Jahren) bin ich ganz gut damit gefahren. An Fehlerzustände aufgrund defekter Ansichten kann ich mich nicht mehr erinnern.

Zum Nutzen der Volltextsuche kann ich nicht viel beitragen, weil ich die nicht mag und deshalb nicht nutze (pränatal vertriebener Ostpreußendickschädel). Wenn Deine Suchen nur mit FTSearch darstellbar sind, nutze es. Vielleicht hilft aber auch sowas wie @Contains oder @Matches (nie benutzt, nur mal gelesen) oder ähnliches im Search.

[ata]

... Geisterdokumente kenne ich auch noch als Löschstubs - Dokumente ohne Felder und ohne UNID und doch da, die können einem immer wieder mal in die Quere kommen. Mit

If doc.IsValid Then ...

... kann man die abfangen...

Ich verwende aus Gründen der Performance lieber Views. Der Search kann bei 120000 Dokumenten dann schon ziemlich lange dauern. wenn er mehrfach hintereinander gefahren wird habe ich schon beobachtet, dass er dann schneller die Collection liefert. Der FT-Search hat so seine Macken - im Standard liefert er nur 5000 Dokumente zurück. Ausserdem mußt du auf den aktualisierten Index achten - nicht mein "Liebling"...

Den Select einer View kann man auch programmatisch ändern - allerdings kostet der View.Refresh dann auch seine Zeit. Daher gehe ich öfters mal den db.Search - der liefert alle Dokumente - aber eben langsamer...

Toni

[Basti*]

Vielen Dank für eure Hinweise!

Fazit: DEN einen Königsweg gibt es wie üblich nicht

Ich werde dann individuell entscheiden müssen, welche Suche welche Anforderungen hat: muß schnell sein, darf langsam sein, Aufruf alle 5 Minuten oder einmal am Tag, usw. Und dann kommen je nach dem mal Ansichten, mal db.search oder auch db.ftsearch in Frage.