Datenbanksuche mit db.Search

[Onkel Domino]

Hallo zusammen!

Ich möchte eine Datenbank nach bestimmten Dokumenten durchsuchen. Es sollen Dokumenten gefunden werden, die ein bestimmtes Datumsfeld haben, welches in einem bestimmten Zeitraum liegt. Dafür habe ich die Search Funktion der NotesDatabase Klasse ins Auge gefasst. Nun habe ich gerade hier im Forum gelesen, dass man damit aber keine Datumswerte auswerten kann sondern nur Strings.

Wie kann ich anhand der Kriterien am einfachsten eine NotesDocumentCollection bekommen?

Vielen Dank schon mal für die Hilfe!

[TMC]

<TMC denkt nach>
Hab zwar glaub ich db.search noch nie in Zusammenhang mit Datumsbereichen verwendet, aber wüsste jetzt nicht was da dagegenspricht...
</TMC denkt nach>

An DBSearch übergibst Du doch eine @Formel. Grundsätzlich sollten da auch Datumsselektionen möglich sein.

Poste doch mal den Link, wo Du das gelesen hast, dass dies nicht geht. Und poste gleichmal Deine @Formel so wie Du diese an DBSearch übergeben willst. Und poste die Fehlermeldung, die dabei erscheint.

[Onkel Domino]

Hi Matthias,

hier der Link: http://www.atnotes.de/index.php?topic=17167.msg103330#msg103330

Zitat: "Mit NotesDatabase.Search kannst Du allerdings Konstrukte mit Datumswerten nicht verwenden - hier gehen in der Tat nur Strings."

Mein Code:

--- schnipp ---
Dim rg_col As NotesDocumentCollection
Set sDate = New NotesDateTime(uidoc.FieldGetText("StartDate"))
Set eDate = New NotesDateTime(uidoc.FieldGetText("EndDate"))
   
searchFormula$ = {Form = "invoice" & Date >= "} & sDate & {" & Date <= "} & eDate & {"}
Set rg_col = db.Search(searchFormula$, Nothing,0)
msgbox rg_col.Count
--- schnipp ---


Der Fehler besteht dann darin, dass die Anzahl der gefundenen Dokumente nicht mit denen Übereinstimmt, die es eigentlich sein sollten.

So long,
Markus


Ergänzung:
Sorry: Fehlermeldung ist "Type mismatch" bei o.g. SearchFormula! Hatte da noch etwas rumgetweakt =

[TMC]

Hi Markus,

OK, wenn Bernhard (koehlerbv) das sagt, dann stimmt das wohl 

Ich hätte jetzt geglaubt dass das in jedem Fall geht.

@Bernhard (in der Hoffnung dass er das liest):
Gibt es dazu eine Dokumentation warum dies mit Datumswerten nicht geht? Würde mich auch interessieren. Die ND6 Designerhelp zu NotesDatabase.Search sagt dazu nichts.

Matthias

[TMC]

Ergänzung:
Sorry: Fehlermeldung ist "Type mismatch" bei o.g. SearchFormula! Hatte da noch etwas rumgetweakt =

Nur eine Idee:
Übergib mal die Datumsfelder via @Date.

Tipp:
Zum testen von @Formula in LS ist Msgbox sehr hilfreich. Lass Dir das String zum Testen also als Msgbox ausgeben, da sieht man dann leichter, ob eine Klammer o.ä. fehlt.

[koehlerbv]

Ich will noch nicht mal meine Hand dafür ins Feuer legen, dass es absolut nicht geht - die Zeit fehlt gerade für Pro und Contra-Belege.
Wie dem auch sei: Von derartigen Stunts mit dbSearch würde ich die Finger lassen - wenn es keine Bummi-Datenbank ist, dann geht die Performance sowas von brutal in den Keller, dass man das keinem User mehr zumuten kann. Mein Tip: FTSearch oder Alternativen suchen ('ne nette Lookup-Ansicht bauen ist manchmal viel einfacher als manch anderer Krampf).

Ich bleibe aber dran an dem Thread, sowie Zeit ist.

Bernhard

[TMC]

Danke für's Auffinden und die Antwort, Bernhard.

db.Search ist ja generell nicht der Bringer in Sachen Performance.
Aber macht es wirklich einen Unterschied, ob man z.B. nach einem Feldinhalt sucht oder aber ob ein Datumsfeld in einer Range enthalten ist?
Rein logisch könnte ich mir vorstellen, dass da seitens Performance nahezu kein Unterschied ist, da ja in beiden Fällen ein Dokument "in die Hand genommen werden muss" und nachgesehen werden muss, ob es dem Kriterium entspricht. Ob das nun ein Textfeld ist oder Datumsfeld: da sehe ich performanceseitig nicht wirklich einen Unterschied (ohne das jetzt getestet zu haben).

[y20frank]

Ob das nun ein Textfeld ist oder Datumsfeld: da sehe ich performanceseitig nicht wirklich einen Unterschied (ohne das jetzt getestet zu haben).

Die Performance dürfte hier eigentlich keine Rolle spielen. Text wird ja im Grunde nur "blöd" ausgelesen, Inhalte von Datumsfeldern müssen je nach regionaler Einstellung beim Auslesen umgesetzt werden (TT/MM/JJJJ | MM/DD/YY | TT/MMM/JJJJ HH:mm:SS usw)... aber das dürfte sicher nur im Bereich von wenigen MilliSecs liegen... (solange man nicht mit SAP-Tables arbeitet  )

@Bernhard:

('ne nette Lookup-Ansicht bauen ist manchmal viel einfacher als manch anderer Krampf).

Jau, das ist wohl wahr!!!

Besten Gruß
Frank

[TMC]

Jo, Frank, so sehe ich das auch.

Aber Auslöser dieses Threads war ja, dass eine Suche nach Datumswerten gar nicht geht gemäß Posting von Bernhard. Ich denke dabei hatte sich Bernhard durchaus was gedacht bei dem Posting.
Bin schon gespannt auf seine Infos (sowie er wieder Zeit hat wie oben erwähnt).

Matthias

[koehlerbv]

Nein, nein - bei grossen DBs macht es einen grossen Unterschied, ob man über den FTI, eine Lookup-Ansicht oder dbSearch geht.

Ich muss jetzt ehrlich gestehen: Mir fehlt jetzt nicht nur die Zeit, sondern auch die Erinnerung an den 23.07.2004 (das erwähnte Posting) und das, was hiermit zusammenhängt.
An sich: SELECT in einer Ansicht basiert ja auf den gleichen Routinen wie dbSearch - und da geht es ja auch. Aber auch mit @Date etc. - es läuft nicht. Aber: AFAIK. Ich hoffe, mir fällt auch die Begründung wieder ein.

Ich rufe mal eine neue Bastelrunde aus 

Bernhard

[TMC]

Nein, nein - bei grossen DBs macht es einen grossen Unterschied, ob man über den FTI, eine Lookup-Ansicht oder dbSearch geht.

"Nein nein" bezüglich was, Bernhard? Klar, dbSearch ist nunmal langsamer als FTI etc. Aber dies stand auch hier nicht zur Diskussion.

An sich: SELECT in einer Ansicht basiert ja auf den gleichen Routinen wie dbSearch - und da geht es ja auch. Aber auch mit @Date etc. - es läuft nicht. Aber: AFAIK. Ich hoffe, mir fällt auch die Begründung wieder ein.

Würde mich wundern, wenn es nicht geht. Wie gesagt: Die ND6 Designerhilfe sagt nix darüber (was aber überhaupt nichts heißt, es wurde dort ja schon so vieles vergessen zu erwähnen).

Bin gespannt auf die Ergebnisse von Markus.

Matthias

[Onkel Domino]

Hallo,

ich habe ein wenig rumprobiert, es aber nicht ans Laufen bekommen. Der Type Mismatch von eben lag dem falschen Datentyp von sDate und eDate zugrunde. Das musst nämlich vom Typ String sein und nicht von Typ NotesDateTime...

Mein Code bis jetzt:

--- schnipp ---
Dim sDate As String
Dim eDate As String
sDate = uidoc.FieldGetText("StartDate")
eDate = uidoc.FieldGetText("EndDate")

Msgbox uidoc.FieldGetText("StartDate")

searchFormula$ = { "Date > } & sDate & {"}
Set col = db.Search(searchFormula$, Nothing,0)   
Msgbox col.Count
Msgbox col.Query
--- schnipp ---

Auch wenn ich ein Datum eingebe nach dem es auf jeden Fall Dokumente geben müsste, meldet col.Count 0 Dokumente. col-Query liefert z.B. "Date > 01.11.2000". Irgendwie scheint das Format noch nicht zu stimmen.

Zum Hintergrund:
Es gibt in der DB Rechnungen und Personen, die ggfs. für die Rechnungen Provision bekommen. Meine Idee war: alle Rechnungsdokumente im betreffenden Zeitraum zu einer NotesDocumentCollection zusammensuchen, dann den ersten Sachbearbeiter wählen und alle Rechnungen in dem der Sachbearbeiter vorkommt in eine neue NotesDocumentCollection packen.

Tja, mit diesen Schwierigkeiten gleich am Anfang hätte ich jetzt nicht gerechnet :-(
Was sind denn so die "best pracitces" wenn man Dokumente innerhalb eines bestimmten Zeitraumes haben möchte? Der Zeitraum muss natürlich variabel sein...


Nachtrag zum Code:
"Date" ist ein Feld im Rechnungsdokument. Vielleicht stimmt bei der Syntax schon was nicht?!

[koehlerbv]

Auch wenn ich ein Datum eingebe nach dem es auf jeden Fall Dokumente geben müsste, meldet col.Count 0 Dokumente. col-Query liefert z.B. "Date > 01.11.2000". Irgendwie scheint das Format noch nicht zu stimmen.

Das Herangehen an die Problematik ist grundsätzlich falsch, Markus.
Du musst immer ausgehen von einer puren @functions SELECT-Formel. Und "Date > 01.11.2000" hat da überhaupt nichts zu suchen - "01.11.2000" ist ein String, kein Datum. Sowas wie
Date > @Date ([01.11.2000]) würde dem entsprechen.

Es ist ein interessantes Thema - auch wenn ich vom Verfahren wegen der Performace-Probleme überhaupt nichts halte - und daher schade, dass ich heute / morgen (naja, vielleicht doch, wenn es weiter so flott läuft wie heute  ) so wenig Zeit habe.

Bernhard

[y20frank]

Jop, da hat Bernhard wie so oft Recht... so funzt es zB

   Dim s As New NotesSession
   Dim db As NotesDatabase
   Set db = s.CurrentDatabase
   Dim sDate As String
   Dim eDate As String
   Dim ws As New NotesUIWorkspace
   Set uidoc = ws.CurrentDocument
   sDate = uidoc.FieldGetText("StartDate")
   eDate = uidoc.FieldGetText("EndDate")
'   searchFormula = "Datum = @Today"
   searchFormula = "Datum < @Today"
   
   Set col = db.Search(searchFormula , Nothing ,0)
   Msgbox col.Count & Chr(10) & col.Query & Chr(10) & datum & " " & sDate
   

[Onkel Domino]

Hallo,

erst eimmal danke für die vielen Tipps. Besonders an Bernhard: ich konnte nun das Datumproblem umsetzen. Folgender Code funktioniert:

--- schnipp ---
(...)
Dim sDate As String
Dim eDate As String
sDate = uidoc.FieldGetText("StartDate")
eDate = uidoc.FieldGetText("EndDate")

searchFormula$ = { Date = @Date([} & sDate & {])}

Set col = db.Search(searchFormula$, Nothing,0)   
Msgbox col.Count
Msgbox col.Query
--- schnipp ---

Nur was ich beim besten Willen nicht verstehe:

searchFormula$ = { (Form = "invoice") & (Date = @Date([} & sDate & {]))}

will nicht funktionieren, obwohl der Searchstring damit dann (z.B.)

(Form = "invoice") & (Date = @Date([22.10.2004]))

lautet und das ist doch eine ordentliche SELECT Abfrage, oder? Fehlermeldung kommt keine, es kommen einfach nur 0 Dokumente zurück obwohl es definitiv welche gibt...

Noch irgendwelche Ideen?

[koehlerbv]

Kann es sowas simples sein wie: Die Maske heisst "Invoice" und nicht "invoice" ?

Bernhard

[Onkel Domino]

Mensch Bernhard, das war's! Wenn man den Wald vor lauter Bäumen nicht mehr sieht...

Das muss jetzt aber unter uns bleiben ;)=

DANKE!

[koehlerbv]

Was meinst Du, auf Grund welcher Erfahrungen ich darauf gekommen bin ? 

Bernhard