Domino 9 und frühere Versionen > ND6: Entwicklung

Komische Suche in Multivalue-Felder

<< < (4/5) > >>

koehlerbv:
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

guerilla:

--- Zitat 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.
--- Ende Zitat ---

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)
--- Ende Zitat ---
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.

koehlerbv:
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

guerilla:
@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.

koehlerbv:
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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete