SelectionFormula wird geändert, View updated nicht

[masseur81]

Hallo,

ich habe in einem Formular eine Liste, die Daten per DbColumn aus einer View ausliest. Diese Ansicht soll aber abhängig von der UID des geöffneten Dokuments sein. Deshalb muss beim Öffnen des Dokumentes die SelectionFormula der View geändert werden.

Diese Formel wird nun auch gespeichert, ist auch korrekt, nur im View werden immer noch die gleichen Dokumente angezeigt.
Wenn ich den View dann im ND öffne, und den View erneut speichere, dann klappt es. Was muss ich tun, damit der View es gleich rafft? Die Methode Refresh der Klasse NotesView hat nicht geholfen.

[masseur81]

Kleine Ergänzung noch: @DbLookup geht hier sicher nicht, weil ich eine exklusive Abfrage habe, d.h. ich möchte alle Einträge anzeigen, die einen bestimmten Wert nicht haben.

[koehlerbv]

WIE veränderst Du die view selection formula?
Verwendest Du @dbColumn mit dem NoCache-Parameter?

Bernhard

[ata]

... das hört sich ja spannend an. Du änderst die Selection-Formel einer Ansicht und erwartest, daß der Index sofort neu gebildet wird, bzw. möchtest wissen, wie du den Index auf einen Refresh bekommst...

... wäre vielleicht ein privater Odner das bessere Instrument?

Toni

[masseur81]

Also ich führe vor dem Öffnen eines Formulars ein kleines LotusScript aus, welches per

Code

view.SelectionFormula = "..."

die Selektionsformel ändert. So wie ich das lt. Doku und internetquellen verstanden habe, sollte das schon reichen.

Dann wird das Formular geöffnet, und eine Listbox soll die Einträge dieses Views verwenden. Oder gibt es ne andere Möglichkeit?

Zusatzinfo über die Selektion: Es sollen nur bestimmte Dokumente angezeigt werden, die die UID des zu öffnenden Dokumentes in einem Multivalue-Feld nicht enthalten.

[Thomas Schulte]

Das ist hundsmiserable Bescheidene Mist Programmierung.

Tschuldigung aber das musste mal gesagt werden.

Erstens, was machst du denn wenn zwei Leute gleichzeitig die Maske öffnen. Zweitens, fehlt da nach der Änderung noch ein Refresh, damit der Indexer auch losläuft, schließlich muss der Index ja jedesmal neu gebildet werden. Und Drittens, was glaubst du was diese Art der Programmierung mit deiner Performance anstellt, wenn du mal mehr als ein paar hundert Dokumente in deine Datenbank hast.

Wenn schon dann macht man sowas mit einem DB.Search und steckt die Ergebnisse so wie man sie braucht in ein verstecktes Feld aus dem man dann die Auswahl zieht.

[masseur81]

Danke für den Tip, DB.Search könnte auch klappen, wobei ich dann den View, also diese eine Spalte auch simulieren muss (Wiederverwendbarkeit?).

Entschuldige die Bemerkung, aber bislang ist alles in Lotus Notes "hundsmiserable Bescheidene Mist Programmierung".

[Thomas Schulte]

Nein ist es nicht.
Du arbeitest nur einfach GEGEN das System. Das ist vermutlich das Kardinalproblem.

[masseur81]

Da stimme ich dir zu. Ich bin in Notes-Entwicklung absoluter Newbie und habe längst noch nicht alle Konzepte verstanden.

Allerdings lässt die Usability für den Entwickler auch stark zu wünschen übrig. Aber schweifen wir nicht vom Thema ab. Ich habe es mit DB.Search realisieren können, dein Tip war also sehr hilfreich.

Danke!

[Thomas Schulte]

Mit der Usability für den Entwickler stimme ich dir zu.

Der Rest ....

Gerade bei Domino/Notes Datenbanken ist es enorm wichtig, das man die darunterliegenden Konzepte und Strukturen, die sich von einer relationalen Datenbank grundlegend unterscheiden, verstanden hat, um brauchbare Anwendungen zu entwickeln. Dieser Lernprozess ist häufig mit ziemlichen Schmerzen für den Entwickler verbunden.

Der DB.Search funktioniert in Prinzip wie der Indexer für die Views und hat bei großen Datenbeständen auch die gleichen Probleme was die Performance angeht. Ist also nichts für Datenbanken mit zigtausenden von Dokumenten.
Was ich noch nie probiert habe ist ob ein NOT "!" vor einer Keyangabe in einem DBLookup wirkt. Damit wäre dein Problem nämlich schnell und effizient gelöst.

[koehlerbv]

Was ich noch nie probiert habe ist ob ein NOT "!" vor einer Keyangabe in einem DBLookup wirkt.

Das Konzept sagt, dass genau dies eben nicht funktioniert: Der Suchbegriff muss exakt mit dem Wert übereinstimmen, gesehen vom 1. Zeichen her (bei Zahlen / Daten der komplette Wert). Damit ist ein NOT ausgeschlossen.

Bernhard

[Thomas Schulte]

"!" NOT vor dem Key geht nicht. Steht zwar auch so in der Hilfe, war aber einen Versuch wert.

[Thomas Schulte]

Bernhard war schneller. Wobei das wieder so eine Lücke ist ...

Eigentlich wäre genau das logisch und vermutlich relativ einfach in die Formel mit einzubauen. Es ist ja nichts anderes als geh mit dem Key auf den View los und dreh anschließend das Ergebnis um. 

Naja irgendwann mach ich doch noch ein Blog auf. "Die verpassten Gelegenheiten", oder "Wie man die Entwicklung von Notes Datenbanken unnötig erschweren kann" ......

[Glombi]

Also ich würde zuerst ein @DbColumn machen und dann denn @DbLookup und dann mit @Trim(@Replace.... das herausfiltern. Übrig bleibt alles ausser die Treffer.

Andreas

[koehlerbv]

Vorausgesetzt, dass @dbColumn knackt nicht die 64k-Grenze, Andreas 

Bernhard

[Glombi]

Das ist das Berufsrisiko 
Mal sehen, wann IBM endlich diese dusselige Grenze kappt.

64K ist schon eine Menge. Die erste Spalte muss natürlich kategorisiert sein, damit gleiche Einträge nicht doppelt gezählt werden.

Andreas

[Thomas Schulte]

Andreas das hab ich mir auch schon überlegt, aber das geht nicht, weil du damit die Multivalue Dokumente nicht erwischt.

Zusatzinfo über die Selektion: Es sollen nur bestimmte Dokumente angezeigt werden, die die UID des zu öffnenden Dokumentes in einem Multivalue-Feld nicht enthalten.

Du müsstest eine Liste von Dokumenten rauskriegen und keine Liste von Werten, dann könnte es mit der Formelsprache funktionieren.

[Glombi]

Das kapiere ich nicht. Warum soll das nicht gehen, wenn die erste Spalte kategorisiert ist 

Liste1 := @DbColumn("";"";"Ansicht";2);
Liste2 := @DbLookup("";"";"Ansicht";DocID;2);
@Trim(@Replace(Liste1;Liste2;""))

Andreas

[Thomas Schulte]

Wenn ich mich micht komplett täusche dann hast du da immer noch die Daten drin von den Dokumenten wo die UNID des anderen als Mehrfachwert gespeichert ist

Doc 1
UNID1
UNID2
UNID3
UNID4
Doc 2
UNID1
UNID4
Doc 3
UNID2
UNID3

Ergibt als ersten dbcolumn
UNID1 (doc1)
UNID2 (doc1)
UNID3 (doc1)
UNID4 (doc1)
UNID1 (doc2)
UNID4 (doc2)
UNID2 (doc3)
UNID3 (doc3)
als zweites durch den Lookup
UNID4

Bleibt beim Trim immer noch:
UNID1 (doc1)
UNID2 (doc1)
UNID3 (doc1)
UNID1 (doc2)
UNID2 (doc3)
UNID3 (doc3)

stehen obwohl der Masseur (doc 1) und (doc2) nicht mehr in der Liste haben will.

[Glombi]

Die Ansicht muss nach UNID kategorisiert sein und der Key für den Lookup muss die UNID des Dokuments sein, welches herausgefiltert werden soll.
Zurückgegegen werden dann die Werte der 2. Spalte, die auch Mehrfachwerte enthalten können.

Durch das Replace werden dann alle Werte entfernt.

Es kann aber auch sein, dass ich die Aufgabenstellung völlig missverstanden habe...
Wie man mit einem DBColumn/DBLookup "Dokumente" zurückbekommen will versteh ich eh nicht.

Andreas