Gordischer Formelknoten

[m3]

Werte @-Formel Spezialisten, ich ersuche im Unterstützung!

Mein Vorgänger hat mir folgendes @Formel-Konstruct überlassen:

Code

(@Date(DATBM)-[1.6.2007]) * (([2.6.2007]-@Date(DATBM)))>=0

Dieses wird dann einem db.Search übergeben. DATBM ist ein Multivalue-Datumsfeld.

Ich versuche gerade dieses Konstrukt durch ein FTSearch nachzubauen. Im Prinzip suche ich so alle Dokumente, in denen im Feld DATBM ein Datumswert vorkommt, der zwischen dem 1. und 2.6. liegt.
Könnte mir wer bitte einen Ansatz/Denkanstoß dazu liefern?

[pete_bla]

hört sich nach

Code

notesdate.timedifference

an...
nurnoch das gewurschtel von eventuellen textwerten im feld nach datum (mit timezone) ect...

[m3]

pete_bla (wir hätten im Forum hier gerne den "echten" Vornamen, zumindest in der Signatur),

ich muss den Ausdruck aber so umwursten, dass ich ihm FTSearch bzw. dem Eingabefenster der Notes Volltextsuche vorwerfen kann.
Dass ich mit timedifference einen unterschied herausbekomm, ist mir auch klar, hilft mir aber nicht weiter.

[Glombi]

Mein erster Ansatz wäre folgendes:

dim squery as string
squery = |[DATBM]=01.06.2007 or [DATBM]=02.06.2007|


Andreas

[m3]

Jup, wäre auch meiner gewesen. Da findet er aber nix.

Beispiel: Bei einem Dokument in der View schaut das Feld so aus:

Code

Field Name: DATBM
Data Type: Time/Date List or Range
Data Length: 76 bytes
Seq Num: 1
Dup Item ID: 0
Field Flags: SUMMARY 

13.01.2000
13.01.2000
13.01.2000
13.01.2000
13.01.2000
20.03.2000
26.04.2000
29.05.2000
18.01.2002

Sollte man doch beispielsweise mit einem "[DATBM]>=13.01.2000" finden, oder?
Nope, dem ist nicht so. Er findet gar nix

[pete_bla]

ok

dann der vorschlag

Code

CONTAINS

ist ja ein mehfachwert im feld und das ist das nette an den @Formel dass die die Mehrfachwerte von selbst interpretieren.
Ist aber dann leider wieder ein = und kein => ....

besser so mit der Signatur?

[jBubbleBoy]

Wird nur nach dem Datum gesucht oder gibt es noch andere Suchkriterien?

bubble

[m3]

Ah, im schlechtesten Fall ist das nur ein Teil einer langen ... AND ... Kette

"[DATBM] CONTAINS 13.01.2000" liefert mir ein "Query is not understandable".

@Peter: Viel besser, danke.

[pete_bla]

so un noch was,

beim ftsearch darfst du ja auch "text" als formel schreiben.
vorschlag:

Code

ftsearch("field DATBM is after 13.01.2000")

[m3]

vorschlag:

Code

ftsearch("field DATBM is after 13.01.2000")

Query is not understandable 

[pete_bla]

mist... 
dann muss ich doch mal nachschauen wie ich das genau gemacht hab....
(hatte aber kein datumsfeld)

[jBubbleBoy]

und was wenn du die Datumseinschränkungen erst nach dem FTSearch rausfilterst?

bubble

[m3]

und was wenn du die Datumseinschränkungen erst nach dem FTSearch rausfilterst?

In einer DB mit > 57.000 Dokumenten? Wozu hab ich die FT-Engine?

[jBubbleBoy]

okey,
also "is after" gibt es auf keinen Fall beim FTSearch, ich denke der String müßte in etwa so ausssehen:

query = {FIELD DATBM>=01.06.2007 AND FIELD DATBM<=02.06.2007}

bubble

[m3]

aber leider nur theoretisch

[flaite]

Hier gibts einen Hinweis:
http://204.3.199.129/tools/domino/v6/CleanInBox/ftsearch.htm

[pete_bla]

wie schon gesagt hab ichs nur für "Strings" 
felder mit datum & mehrfachwert leider nicht 

Code

FTSearch("field Subject contains hallo")

oder

Code

FTSearch("FIELD Subject = hallo")

funktioniert (aber eben nicht datum & mehfachwert)
der dann auch nicht das "field" will, sonst der "Query is not understandable".

Code

FTSearch("FIELD Datum =01.01.2007")

findet eben nur einfachwerte (auch wenn man die 'formel' in der suchbar zusammenschraubt).

sorry

[pete_bla]

so noch was zum datum und ftsearch aus der Knowledge Base....
http://www-1.ibm.com/support/docview.wss?uid=swg21102489
ist womöglich das das problem?
... trauriger workaround 

[jBubbleBoy]

mhmm das ist natürlich frustrierend, schon mal getestet wie lange ein db.search dauert?

bubble

[m3]

so noch was zum datum und ftsearch aus der Knowledge Base....
http://www-1.ibm.com/support/docview.wss?uid=swg21102489
ist womöglich das das problem?
... trauriger workaround 

ARGL. Das kanns aber nicht sein. Ich glaub, ich werd mal einen PMR aufmachen - wozu sind wir Premium Support Kunden. 

@BubbleBoy: Die Performance ist derzeit (noch) nicht die Frage. Aber mein Code baut bis jetzt FT-Suchausdrücke zusammen und nicht SELECT-Statements in Formelsprache. Und das will ich nicht umbauen.