Autor Thema: Komische Suche in Multivalue-Felder  (Gelesen 4349 mal)

Offline guerilla

  • Junior Mitglied
  • **
  • Beiträge: 74
  • Geschlecht: Männlich
    • campino2k.de
Komische Suche in Multivalue-Felder
« 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.

Lotus Notes ist ein sehr mächtiges und rätselhaftes Programm. Und seine Macht wird nur von seiner Rätselhaftigkeit übertroffen.

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Komische Suche in Multivalue-Felder
« Antwort #1 am: 24.09.07 - 12:39:33 »
WIE erfolgt die Suche? dbSearch, FTI, ...

Bernhard

Offline guerilla

  • Junior Mitglied
  • **
  • Beiträge: 74
  • Geschlecht: Männlich
    • campino2k.de
Re: Komische Suche in Multivalue-Felder
« Antwort #2 am: 24.09.07 - 12:41:20 »
Mit URL-Params in einer Searchview
Lotus Notes ist ein sehr mächtiges und rätselhaftes Programm. Und seine Macht wird nur von seiner Rätselhaftigkeit übertroffen.

Offline guerilla

  • Junior Mitglied
  • **
  • Beiträge: 74
  • Geschlecht: Männlich
    • campino2k.de
Re: Komische Suche in Multivalue-Felder
« Antwort #3 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...
Lotus Notes ist ein sehr mächtiges und rätselhaftes Programm. Und seine Macht wird nur von seiner Rätselhaftigkeit übertroffen.

Offline m3

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 8.102
  • Geschlecht: Männlich
  • Non ex transverso sed deorsum!
    • leyrers online pamphlet
Re: Komische Suche in Multivalue-Felder
« Antwort #4 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
HTH
m³ aka. Martin -- leyrers online pamphlet | LEYON - All things Lotus (IBM Collaborations Solutions)

All programs evolve until they can send email.
Except Microsoft Exchange.
    - Memorable Quotes from Alt.Sysadmin.Recovery

"Lotus Notes ist wie ein Badezimmer, geht ohne Kacheln, aber nicht so gut." -- Peter Klett

"If there isn't at least a handful of solutions for any given problem, it isn't IBM"™ - @notessensai

Offline guerilla

  • Junior Mitglied
  • **
  • Beiträge: 74
  • Geschlecht: Männlich
    • campino2k.de
Re: Komische Suche in Multivalue-Felder
« Antwort #5 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.
Lotus Notes ist ein sehr mächtiges und rätselhaftes Programm. Und seine Macht wird nur von seiner Rätselhaftigkeit übertroffen.

Offline guerilla

  • Junior Mitglied
  • **
  • Beiträge: 74
  • Geschlecht: Männlich
    • campino2k.de
Re: Komische Suche in Multivalue-Felder
« Antwort #6 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.
Lotus Notes ist ein sehr mächtiges und rätselhaftes Programm. Und seine Macht wird nur von seiner Rätselhaftigkeit übertroffen.

Offline m3

  • Freund des Hauses!
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 8.102
  • Geschlecht: Männlich
  • Non ex transverso sed deorsum!
    • leyrers online pamphlet
Re: Komische Suche in Multivalue-Felder
« Antwort #7 am: 25.09.07 - 13:27:25 »
Den lokalen Cache schon gelöscht?
HTH
m³ aka. Martin -- leyrers online pamphlet | LEYON - All things Lotus (IBM Collaborations Solutions)

All programs evolve until they can send email.
Except Microsoft Exchange.
    - Memorable Quotes from Alt.Sysadmin.Recovery

"Lotus Notes ist wie ein Badezimmer, geht ohne Kacheln, aber nicht so gut." -- Peter Klett

"If there isn't at least a handful of solutions for any given problem, it isn't IBM"™ - @notessensai

Offline guerilla

  • Junior Mitglied
  • **
  • Beiträge: 74
  • Geschlecht: Männlich
    • campino2k.de
Re: Komische Suche in Multivalue-Felder
« Antwort #8 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)
Lotus Notes ist ein sehr mächtiges und rätselhaftes Programm. Und seine Macht wird nur von seiner Rätselhaftigkeit übertroffen.

Offline DerAndre

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 1.655
  • Geschlecht: Männlich
  • Keep cool!
Re: Komische Suche in Multivalue-Felder
« Antwort #9 am: 25.09.07 - 16:01:47 »
Notes zu und die cache.dsk löschen Notes wieder starten.
André

Elterninitiative diabetischer Kinder und Jugendlicher e.V.
-----------------------------------------------------------------------------
Fliegen ist die Kunst auf den Boden zu Fallen, aber daneben.
-----------------------------------------------------------------------------
Etwas mehr Hardware dazu zu kaufen ist viel billiger als
Software besser zu machen. ( Niklaus Wirth )

Offline guerilla

  • Junior Mitglied
  • **
  • Beiträge: 74
  • Geschlecht: Männlich
    • campino2k.de
Re: Komische Suche in Multivalue-Felder
« Antwort #10 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.
« Letzte Änderung: 25.09.07 - 16:49:05 von guerilla »
Lotus Notes ist ein sehr mächtiges und rätselhaftes Programm. Und seine Macht wird nur von seiner Rätselhaftigkeit übertroffen.

Offline pete_bla

  • Senior Mitglied
  • ****
  • Beiträge: 455
  • Geschlecht: Männlich
  • dot net gitz net!
Re: Komische Suche in Multivalue-Felder
« Antwort #11 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.
pete(r)

Offline guerilla

  • Junior Mitglied
  • **
  • Beiträge: 74
  • Geschlecht: Männlich
    • campino2k.de
Re: Komische Suche in Multivalue-Felder
« Antwort #12 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...
Lotus Notes ist ein sehr mächtiges und rätselhaftes Programm. Und seine Macht wird nur von seiner Rätselhaftigkeit übertroffen.

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Komische Suche in Multivalue-Felder
« Antwort #13 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

Offline pete_bla

  • Senior Mitglied
  • ****
  • Beiträge: 455
  • Geschlecht: Männlich
  • dot net gitz net!
Re: Komische Suche in Multivalue-Felder
« Antwort #14 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)
pete(r)

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Komische Suche in Multivalue-Felder
« Antwort #15 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

Offline guerilla

  • Junior Mitglied
  • **
  • Beiträge: 74
  • Geschlecht: Männlich
    • campino2k.de
Re: Komische Suche in Multivalue-Felder
« Antwort #16 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.
Lotus Notes ist ein sehr mächtiges und rätselhaftes Programm. Und seine Macht wird nur von seiner Rätselhaftigkeit übertroffen.

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Komische Suche in Multivalue-Felder
« Antwort #17 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

Offline guerilla

  • Junior Mitglied
  • **
  • Beiträge: 74
  • Geschlecht: Männlich
    • campino2k.de
Re: Komische Suche in Multivalue-Felder
« Antwort #18 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.

Lotus Notes ist ein sehr mächtiges und rätselhaftes Programm. Und seine Macht wird nur von seiner Rätselhaftigkeit übertroffen.

Offline koehlerbv

  • Moderator
  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 20.460
  • Geschlecht: Männlich
Re: Komische Suche in Multivalue-Felder
« Antwort #19 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

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz