db.Search findet Dokumente, die es eigentlich nicht geben dürfte

[rar]

Hallo Leute,
db.Search bringt mich noch zum verzweifeln....

Ich habe mehrere DBs. (A, B und C)
In DB A wird ein Dok angelegt. Im PostSave des Doks wird dann in DB B und DB C ein neues Dok angelegt. Diese neuen Doks haben ein Feld "Quellid" in dem die UNID des Ursprungsdoks gespeichert wird. (Falls es im Ursprungdok eine Änderung gibt, such ich über das Feld die dazugehörigen Doks in den anderen DBs.)

Mein Problem ist jetzt folgendes:
Bei neuen Dokumenten findet die Zeile

Code

Set coll = dbVb.Search( {Quellid = "} + doc.Universalid + {"} , Nothing, 0 )

ab und zu 0 Dokumente (wie es eigentlich sein sollte), ab und zu findet das Search auch 5 oder 3 oder 7 Doks, in denen aber im Feld Quellid ein ganz anderer Wert steht. 

Bitte habt eine Idee woran das liegen könnte!

lG
-einratloserdaniel

[Tode]

warum kennt eigentlich niemand die Such- Ressourcen...

Eine kurze Suche mit "NotesDatabase" & "Search" in der Knowledgebase bringt das beigefügte Dokument zu Tage.

HTH
Tode


LotusScript Search Method Returns Unexpected Documents that Do Not Meet Search Criteria
Product:
Lotus Domino  >  Lotus Domino Designer  >  Versions 6.0, 5.0, 6.5
Platform(s):
Platform Independent
Doc Number:
1144798

Published   13.09.2004
Technote

Problem

When using the LotusScript Search method (of the NotesDatabase class), the returned collection set includes documents which do not meet the search formula criteria.  This occurs in cases where the LotusScript code is executed from a  Notes 5.x Client and is searching a database on a Notes Domino 6.x server.  This issue has also been reported in cases where the Notes Client is running a 6.x French release.

Further examination reveals that the unexpected documents are Profile documents.

The issue does not occur if the database being searched is open in the User Interface, or if the agent is being run within the LotusScript Debugger and the NotesDatabase object for the searched database has been expanded.



Solution
This issue has been reported to Lotus software Quality Engineering.  The Software Problem Report (SPR) for the 5.x client searching to a 6.x server is #ICAO5T3TND. The SPR for the French 6.x Client is #PJON5PQTQX.

Workaround:
You can remove the undesired Profile documents from the returned collection by performing a conditional check to determine if the NotesDocument objects IsProfile property is True, and then removing it from the collection, using the NotesDocumentCollection classes DeleteDocument method (the method does not actually delete the document from the database).

For example:

Set doc=col.getfirstdocument
While Not doc Is Nothing
   Set nextdoc=col.getnextdocument(doc)
   If doc.isprofile=True Then
       Call col.deletedocument(doc)
   End If
   Set doc=nextdoc
Wend

NOTE:  There is an additional issue in which an unexpected number of documents are accessed in a collection set when the Search method makes use of the MaxDoc parameter.  For more information on this, refer to the document titled "MaxDoc Parameter in LotusScript Search Method Does Not Work" (#1094421).

[koehlerbv]

This issue has also been reported in cases where the Notes Client is running a 6.x French release.

Ist dies dem amerikanischen Verständnis von "good old Europe" (old = R5) geschuldet? 

Noch ein Hinweis von mir (auch wenn der mit der Problemursache nichts zu tun hat): Verwende niemals "+", um Strings in LS zu verketten, sondern immer "&". Es gibt "nette" Beispiele (hier im Forum zu finden), wie man mit dem nicht dafür vorgesehenen "+" unerwartet auf die Nase fallen kann.

Bernhard

[rar]

@Tode:
Tja... was soll ich sagen. Nachdem ich jetzt 5 Minuten schämend in der Ecke gestanden bin, kann ich mich endlich auf den Workaround stürzen. Wir verwenden 5er Client und 6er Server... Ich dachte da irgendwie nicht an die KB. Sorry, dass ich nicht erst dort nachschaute. Ich gelobe Besserung. Danke jedenfalls für den Wink. So werde ich das Problem lösen. 

@Bernhard:
Als ich in Script angefangen habe, habe ich immer "+" verwendet. Dass ein "&" ein "+Cstr()" ersetzt, habe ich erst viel später herausgefunden. Und bei doc.UniversalID weiss ich ja, dass der Rückgabewert ein String ist und hatte deswegen eigentlich keine Bedenken. Wie könnte man denn noch auf die Nase fallen? Also wenns nur um die Verkettung von Strings, Zahlen oder Datumswerten geht, da pass ich schon auf.

-daniel

[koehlerbv]

Daniel, für den Programmierer muss gelten: Ordnung und Sauberkeit im Schlachthof. Ohne wenn und aber. Lotus dokumentiert als Concatenator für Strings in LotusScript nur das Zeichen "&", und das aus gutem Grunde.
Probiere
Messagebox 100 + "200" (nur so als Beispiel).

Irgendwann scheppert es dann eben ...

Bernhard

[rar]

In diesem Fred hast du mich wegen dem "&" kritisiert und gesagt

Ich halte es hier aber mit Andreas: Es ist unsauberes Coden, es liest sich schlechter. Ich mach's einfach nicht.

Bernhard

Erwischt

[koehlerbv]

Nein, nicht erwischt, Daniel 

Ich bezog mich da auf "&" und seine Verwendung als zwangsweiser Typ-Wandler. Beispiel:
Sauber: "Dokumente: " + Cstr (Variable_Vom_Typ_Long)
Unsauber: "Dokumente: " + Variable_Vom_Typ_Long

Ich gestehe gerne Fehler ein (und lerne so dazu), aber an dieser Stelle bleibe ich bei meinem "Ordnung und Sauberkeit im Schlachthof".

Beste Grüsse über ein paar (weisse) Berge ins benachbarte Inntal,
Bernhard