Das Notes Forum

Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: guerilla am 24.09.07 - 12:36:34

Titel: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 24.09.07 - 12:36:34
Hallöchen...

Folgendes Problem stellt sich mir:

Ich habe Dokumente in denen jweils 2 Multivalue-Felder sind. Teilweise überschneiden sich die Inhalte (was eben die "interessanten" Suchergebnisse ergibt).

1. Ich Suche in einer Searchview nach einem Namen und möchte die Suchergebnisse auf die Dokumente begrenzen, die im Feld "Addressgroups" den Wert "00TEST" enthalten. Kein Ergebnis. Müsste aber ein Ergebnis sein. Ganz sicher.

2. Ich entferne die Bedingung der Adressgruppe. Mehrere Ergbnisse (was richtig ist, den der Name taucht in mehreren Dokumenten auf)

Ich setze zu Fall zwei die Bedingung, dass im Feld "AddressKeywords" der Wert "00TEST" enthalten ist Ein Ergbnis. (was richtig ist)

Das komische an der Sache ist: Die Felder AddressGroups und -Keywords enthalten in besagtem Beispieldokument die gleichen Werte und sind ansonsten (bsi auf den Namen) in sämtlichen Eigenschaften identisch. Beim Eingrenzen der Suche wird für beide Felder die gleiche Syntax verwendet, was ja eigentlich in diesem Fall die gleichen Ergebnisse liefern sollte.

Dummerweise habe ich immer, wenn ich die Suchklausel auf das Feld AddressGroups anwende keine Ergebnisse. Egal nach was ich suche.

Ich habe den Index der DB schon mehrmals neu aufgebaut, aber ich habe keine Ahnung woran das liegen kann.

Hoffentlich weiss einer hier Rat.

Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: koehlerbv am 24.09.07 - 12:39:33
WIE erfolgt die Suche? dbSearch, FTI, ...

Bernhard
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 24.09.07 - 12:41:20
Mit URL-Params in einer Searchview
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 24.09.07 - 14:30:41
Interessant an der Geschichte ist das seltsame Verhalten, wenn ich die Suche über den Notes-Client benutze und im More-Tab die Option "Field" benutzen möchte.

Da zeigt er für das Keywords-Feld "contains" und "contains not" an, für das Addressgroups-FEld "is on" "is between" etc.

Irgendwas ist da faul...
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: m3 am 24.09.07 - 14:36:13
Das klingt nach einem Problem, das ich auch schon habe/hatte:
http://atnotes.de/index.php?topic=37642.0
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 24.09.07 - 14:45:04
Bei mir sind das beides Text-List-Felder, die mit CONTAINS durchsucht werden.... Wie gesagt, Felder sind soweit funktional identisch, aber irgendwie funktionierts bei einem Feld, bei dem anderen nicht.
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 25.09.07 - 13:15:19
Kann man irgendwie den Feldtyp, den die Notes-Suche im Client für ein Feld "gespeichert" hat, ändern?
Wenn ja, wie? Ich hab's sogar schon mit nem updall -R versucht, aber der Feldtyp, den die Suche zulässt, passt einfach nicht.

Ich hab mal ein Bild angehängt, dass den IST und den SOLL-Zustand zeigt.
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: m3 am 25.09.07 - 13:27:25
Den lokalen Cache schon gelöscht?
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 25.09.07 - 15:49:18
Wie mach ich das?

BTW: Ich hab alle AddressGroup-Felder in der DB gelöscht und spasseshalber neu eingebaut, mit dem Ergebnis, dass das Feld AdressGroups weiterhin ein Datumsfeld ist und, wenn ich es umbenenne, das umbenannte Feld richtig erscheint (xAddressGroups = text list mit den contains-Wählern), das Feld Addressgroups weiterhin gelistet wird - als Datumsfeld)
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: DerAndre am 25.09.07 - 16:01:47
Notes zu und die cache.dsk löschen Notes wieder starten.
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 25.09.07 - 16:31:04
Bei mir war's ne Cache.ndk, aber das Problem bleibt.

Zitat
Was meinen Sie, Watson?
- Holmes, ich glaube ihre Datenbank ist total gefuckt, am Arsch, verreckt. Absolut FUBAR.
Danke, Watson.
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: pete_bla am 25.09.07 - 19:12:54
Hi,

das mit dem "is On" "is After"... ist ja eigentlich für ein Datumsfeld vorgesehen (aber dass weisst Du bestimmt schon)

So wie ich das sehe gibts/gabs da mal ein Dokument mit einem Datum in dem Feld und die DB/FTindex hat jetzt nen Knall!

Updall -C oder -X
fixup
compact
FT-Index löschen und neu anlegen
haben alle auch nichts gebracht (bei mir R6.55 Server/Client)

Einziges was hilft war:
neue Replik anlegen, (ohne FT-Index)
orginal DB löschen
"neue orginal" von der Replik erstellen.
neuen FT-Index anlegen.
(Oder natürlich eine neue DB)

Ist es immernoch da, mach Dich auf die Suche nach dem Dokument mit dem "TimeDate" Feld und hoffe eins zu finden. Dann nochmals von vorne.

Gruss, Pete(r)

PS.:
Wers nachbauen will:
Neue DB anlegen
1 Maske, 1 Feld, Zuerst Typ "Datum"
dann mit der Maske ein Dokument erstellt,
dann das Feld in der Maske auf "Text" geändert
und die Eingeschaft in der FT-Suche ging nie wieder weg....
(auch mit allem oben, auch mit allen Dokumenten löschen.....)
erst nach der neuen Replik oder in einer neuen Kopie wars wieder ok.
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 25.09.07 - 20:28:45
@pete: ich probier's morgen nochmal aus. aber ne kopie ohne FT hatte ich schon ausprobiert, replik allerdings noch nicht.

Ich hab in allen Dokumenten das betreffende Feld rausgelöscht (deletefield) und auch in allen Designelementen das Feld gelöscht.

Dann ein Template lokal gezogen, lokal compacted, designreplace etc.

fixup und updall -X hab ich noch nicht probiert. -C schon und -B auch

Wenn ich dann morgen weitermache: Was meinst Du mit "neue original von der Replik anlegen"? Eine neue Kopie?

Mit Notespeek habe ich das Feld übrigens gefunden und <ironie>total überraschend war die Eigenschaft lt. DB "Time/Date". Haha. </ironie>

Ich habe übrigens 655er Client und 7er Server.... Ist das ein Serverproblem, dann ist es auch im 7er noch...
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: koehlerbv am 25.09.07 - 20:38:16
So ganz verstehe ich jetzt das Problem nicht mehr. Notes bietet mit dieser Art der Suche eine gewisse Hilfestellung. Dabei muss ein Item-Type berücksichtigt werden. Der stammt aus einer Tabelle. Und für diese Tabelle muss man sich einigen - gleichzeitig kann man aber ohne weiteres gleichnamige Felder mit unterschiedlichen Feldtypen anlegen. Wie soll sich Notes dann entscheiden?

Ich sehe für Dich nur einen sauberen Weg (der angesichts Deiner bisherigen Aufräumaktionen sicherlich gangbar ist): Erstelle ein neues Feld und ordne diesem Feldnamen das betreffende Item neu zu.

Und wenn Du / Ihr ein Problem mit eindeutigen Feldnamen / konsistenten Itemtypen habt (was ja wirklich nacherlebbar ist und jedem passieren kann): Zwingt Euch, im Feld- bzw. Itemnamen eben immer auch den Datentypen mit zu verzeichnen.

Bernhard
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: pete_bla am 25.09.07 - 20:48:30
Hi,

@guerilla
Wenn ich dann morgen weitermache: Was meinst Du mit "neue original von der Replik anlegen"?
Wenn du die Replik lokal ziest, musst Du sie ja wieder auf den Server bekommen.
wenn du die auf dem Server ziehst, ist das natürlich Banane,
dann kannst du die "Replik" ja wieder ins Verzeichnis "reinlegen".

@koehlerbv
Versteh mich nicht falsch, dass ich Felder vom Typ "mischen" möchte....
Der Effekt ist mir nur schon mal aufgefallen und ich würde auch gerne genauer wissen woran es hapert(e).

Pete(r)
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: koehlerbv am 25.09.07 - 21:01:54
Pete, wir haben uns da schon nicht falsch verstanden. Nur: Wenn Du eine Tabelle führst, können die Werte nur eindeutig sein. Und das ist ja eigentlich Notes-untypisch, aber genau deswegen ist bei der Entwicklung eben doch Disziplin angesagt.

Bernhard
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 25.09.07 - 21:14:06
So ganz verstehe ich jetzt das Problem nicht mehr. Notes bietet mit dieser Art der Suche eine gewisse Hilfestellung. Dabei muss ein Item-Type berücksichtigt werden. Der stammt aus einer Tabelle. Und für diese Tabelle muss man sich einigen - gleichzeitig kann man aber ohne weiteres gleichnamige Felder mit unterschiedlichen Feldtypen anlegen. Wie soll sich Notes dann entscheiden?

Ich sehe für Dich nur einen sauberen Weg (der angesichts Deiner bisherigen Aufräumaktionen sicherlich gangbar ist): Erstelle ein neues Feld und ordne diesem Feldnamen das betreffende Item neu zu.

Und wenn Du / Ihr ein Problem mit eindeutigen Feldnamen / konsistenten Itemtypen habt (was ja wirklich nacherlebbar ist und jedem passieren kann): Zwingt Euch, im Feld- bzw. Itemnamen eben immer auch den Datentypen mit zu verzeichnen.

Mir hier Inkompetenz zu unterstellen finde ich, ist der falsche Weg. Ich frage hier nach, weil ich hoffe, dass jemand das Problem schon hatte und vielleicht eine Lösung dafür hat. Ich habe einen CLP bei mir im Büro und der wusste auch nicht weiter, sonst hätte ich gar nicht gefragt.
Ist ja auch nicht so, dass das Problem so alltäglich ist wie Listen abgleichen oder RTF-Ersetzungen zu machen oder so.

Das Feld, um das es geht, heisst AddressGroups. Das Feld war einheitlich in den Designelementen IMMER ein TextList-Field. Nirgends stand in einem dieser Felder ein Datum.

Obwohl es in allen Dokumenten ein TextList-Feld ist, ziegt mir NotesPeek und die Suche an, es wäre ein Datumsfeld, ohne das es jemals ein war. Wir haben keine gleichnamigen Felder mit unterschiedlichen Typen. Ich habe zigmal ne Synopsis gemacht und Stück für Stück durchsucht.
Ich hänge seit 2 Tagen an dem Scheiss-Problem und hatte gehofft, man könnte mir hier helfen.

Und wie ich bereits gesagt hatte:
Zitat
BTW: Ich hab alle AddressGroup-Felder in der DB gelöscht und spasseshalber neu eingebaut, mit dem Ergebnis, dass das Feld AdressGroups weiterhin ein Datumsfeld ist und, wenn ich es umbenenne, das umbenannte Feld richtig erscheint (xAddressGroups = text list mit den contains-Wählern), das Feld Addressgroups weiterhin gelistet wird - als Datumsfeld)
Habe ich auch das schon probiert. Wenn ich nicht so verzweifelt wäre, würde ich mich hier nicht so anstellen. Danke für die Aufmerksamkeit.
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: koehlerbv am 25.09.07 - 21:32:12
Hast Du mein Posting überhaupt richtig gelesen, Chris? Habe ich Dir irgendwo Inkompetenz vorgeworfen? Habe ich nicht gesagt, dass das jedem passieren kann?

Weiters: Würdest Du Deinen Hals dafür riskieren, dass das Item (Feld ist wurscht!) nicht irgendwann erstmals mit anderem Typ angelegt wurde?

Wie bereits angedeutet: Deine Reaktion verstehe ich nicht.

Bernhard
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 25.09.07 - 21:54:22
@Bernhard: Tut mir leid, wirklich. Ich bin momentan einfach ziemlich fertig und das Problem"chen" da macht es einfach nicht besser. Ich sitz da echt seit 2 Tagen dran und das dumme ist, das unser Kunde das gleiche Problem hat und das vermutlich irgendwann auf unserm Server aufgetreten ist (glaube ich).

Ich möchte mich hiermit in aller Form entschuldigen, schließlich habe ich hier schon wertvolle Tipps bekommen.

Chris

PS: Ich würde nicht direkt meinen Hals riskieren, aber da ich weiß, wer das konzipiert und entwickelt hat, bin ich mir zu 99,9% sicher, dass das Feld nie ein Datumsfeld war.

Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: koehlerbv am 25.09.07 - 22:17:39
Chris, wir beide haben kein Problem - nach Deiner Reaktion schon gar nicht!  ;)

Konzentrieren wir uns wieder auf die Lösung.
Ich würde ein neues Item (und demzufolge auch ein neues Feld im Frontend) erzeugen und die Werte übertragen. Oder eine eigene Suchroutine einsetzen (insofern das passt und man dazu die passenden Werkzeuge hat).

Bernhard
Titel: Re: Komische Suche in Multivalue-Felder
Beitrag von: guerilla am 26.09.07 - 15:09:38
So, ich hab jetzt mal mithilfe von Ferdy Christants DXL Exporter meine DB exportiert, Design Only.

Kann jemand mit
Code
<item name='AddressGroups' summary='false' sign='true'>
<itemdata type='400'>
AAAAAAAAAAA=
</itemdata></item>
Etwas anfangen? lt. dieser Seite hier : http://www.bobzblog.com/tuxedoguy.nsf/dx/what-if.....-1?opendocument&comments
scheint das ein Time/Date zu sein, allerdings taucht das Teil in keiner Synopsis auf...
Theoretisch müsste ich ja bloß den richtigen Datatype einsetzen und das TEil zurückimportieren, dann sollte es funktionieren... Theoretisch. Jetzt muss ich nur noch rausfinden, wo sich das blöde Ding versteckt (im Designer) und in welchen Typ ich das ändern muss...