Dokumente in Abhängigkeit von Feldwerten in Ansicht anzeigen

[jknoblich]

Hi,
die Suche brachte mich nicht weiter und mit der Formelsprache stehe ich nach wie vor auf Kriegsfuß.
Vielleicht geht das auch gar nicht so, wie ich das will:

Ich habe eine Maske, in der u.a. Felder a1 bis a14 und b1 bis b14 drin sind.
In der Ansicht sollen nun die Felder a1 bis a14 in einer Spalte aufgelistet werden.
Und zwar :
- nur wenn sie nicht leer sind
- kategorisiert
- und (mein großes Problem) in Abhängigkeit von Feld b.

Also
Wenn Feld a1 nicht leer und das dazugehörige Feld b1 leer ist, dann zeige es in der Ansicht.
usw. für alle anderen Felder.

Hintergrund ist der, daß ich eine Checkliste da habe, wo ich in der Ansicht aufgelistet haben möchte, welche Dokumente noch etwas in der Checkliste offen haben.
Dabei ist Feld a der Checklisteneintrag und Feld b eine Checkbox, die bei Erledigung abgehakt wird.

Danke schon mal für Lösungsvorschläge.

[koehlerbv]

Ansichtsauswahl:
SELECT Form = "DeinMaskenname" & b != ""

[jknoblich]

War nicht ganz das, was ich gesucht hatte.
Bin dem Formelwirwar aus dem Weg gegangen, indem ich jetzt vor dem Speichern die Werte in ein Extrafeld schreibe.

Dann ist es in der Ansicht einfacher für mich.

Trotzdem Danke für die schnelle Antwort.

[Glombi]

Es wäre dann so gegangen:
Zugriffsformel der Ansicht:
SELECT
(a1 != "" & b1 = "") |
(a2 != "" & b2 = "") |
... ... ...
(a14 != "" & b14 = "")

Dann die Formel für die Kategoriespalte:
@Trim(
@If(a1 != "" & b1 = "";a1;"") :
@If(a2 != "" & b2 = "";a2;"") :
... ... ...
@If(a14 != "" & b14 = "";a14;"")
)

Andreas

[Semeaphoros]

... womit die von Jens gewählte Variante durchaus zur Nachahmung empfohlen werden kann, denn sonst verliert man sich leicht in Unübersichtlichkeit: Sprich: Auswertung im QuerySave der Felder und in einem speziellen Feld für die Ansichtsauswahl, vielleicht auch in speziellen Feldern für die Anzeige die vorausegwerteten Werte abspeichern.

Hat diverse Vorteile: kleinere Indizes, mehr Uebersicht im Code

[Glombi]

D'accord. Man muss in solchen Fällen immer zweierlei Dinge abwägen:
1) Will ich Flexibilität => verwende Formeln in Zugriffs- und Spaltenformeln in Ansichten
2) Will ich Performance => verwende ein berechnetes Feld in Dokumenten.

Nachteil von 2) Bei einer (evtl. kleinen) Änderung muss ich alle Dokumente (evtl. sehr viele) per Agent ändern. Wenn dann User die Datenbank replizieren (bspw. per 9600 Handyverbidnung) kommt bei denen echte Freude auf.

Also: Es gibt keine Generalempfehlung. Für die läppischen 14 Felder sehe ich aber keine Problem, die Variante 1 zu nehmen, wenn es viele Doks in der Datenbank gibt.

Andreas

[Semeaphoros]

Da kann ich mich voll anschliessen, das erweitert meine Ueberlegungen noch ein bisschen.

[koehlerbv]

Hm, da kann ich mich nicht ganz anschliessen ...
Der Ansichtsindex wird einmalig aufgebaut (so er nicht wegen @Today und Konsorten "flüchtig" ist).
Berechnete Felder werden jedoch bei jedem Speichern des Dokuments neu durchgerechnet. Was jedoch bei Verwenden von Methode 1 nicht ins Gewicht fällt, da ja hier auch der Ansichtsindex mit der gleichen Formel aktualisiert werden muß. Das passiert jedoch ggf. auf dem Server.

Bernhard

PS: Meine erste Antwort war leider ein Schnellschuss wegen zu oberflächlichen Lesens der Ursprungsfrage.

PSS:

und mit der Formelsprache stehe ich nach wie vor auf Kriegsfuß

Das halte ich für absolut bedenklich !

[Glombi]

Ich muss dazu sagen, dass ich letztens wegen der 64K Grenze zu Methode 2 greifen musste - die Felder habe ich dann in Script gesetzt.

Ich persönlich bevorzuge jedoch in den meisten Fällen Methode 1.

Andreas

P.S.: Wegen Kriegsfuß und Formelsprache: Das erlebe ich immer wieder bei Leuten, die Notes nicht seit "Geburt" machen, sondern erst nachdem se eine vernünftige Sprache gelernt haben zu Notes kommen. Die Formelsprache ist äußerst gewöhnungsbedürftig und hat Ihre Tücken (Reihenfolge, keine Schleifen, Anlehnung an die V3 Menüstruktur,...)
Schön ist, wenn man die Stärken von @Formeln und Script kennt, und das entsprechend einsetzt.