Anfängerfragen - Ansicht anpassen und Feld in 2 Dokumenten

[Mich90]

Hallo liebe Community,

ich bin ganz neu in der Entwickler-Welt von Lotus Notes und bin sozusagen blindlings auf kleine Probleme gestoßen. Ich habe versucht, mich über Suchmaschinen und die interne Hilfe schlau zu machen, aber wenn man nicht weiß, nach was man suchen soll, fällt das doch recht schwer   , deswegen hoffe ich hier Hilfe zu bekommen.

Mein 1. Problem:
In einem der Dokumente sind Felder, mit komma-getrennten Werten und Felder mit ganz normalen Werten. In meiner Ansicht sollen natürlich in allen Spalten nur ein Wert jeweils stehen.
Das erste komma-getrennte Wert konnte ich noch durch ein
@Trim(@Explode(fldMed00H4; ","))
auflösen.
Nun habe ich aber das Problem, dass ich nicht weiß, wie ich das 2. auflösen soll, denn die Werte gehören logisch zusammen. Beispiel:
In fldMed00H4 stehen verschiedene Typen (mit Komma getrennt) in meinem anderen Feld steht zu jedem Typ eine zugehörige Zahl. Nun brauch ich in der Ansicht natürlich zu jedem Typ nur die eine Zahl, die auch an der xten Stelle steht, an der auch der Typ in seinem Feld steht.
Wie löse ich das?


Das 2. Problem:
Ich habe ein Feld in einem Dokument und dieses Feld soll an anderer Stelle in der Datenbank nochmal dargestellt werden und dort natürlich auch verändert werden können. Ich habe in der Dokumentation den Befehl @DbLookUp gefunden, weiß aber nicht wirklich, ob der in dieser Situation passend ist.
Beispiel:
Im Dokument Country gibt es verschiedene Einträge, die der Administrator der Datenbank eingeben kann. Ein Feld soll auch durch den Benutzer eingegeben werden können. Dieser hat ebenfalls ein Dokument für Country. Das eine Feld soll nun nicht mehr vom Administrator, sondern vom Benutzer eingetragen werden können. Da allerdings viele Ansichten und Dokumente sich Daten aus dem Feld vom Admin ziehen und diese darstellen, wäre es fatal, dieses Feld zu löschen. Deswegen würde ich dieses gerne einfach nochmal an anderer Stelle darstellen und bearbeiten können.
Ist dies möglich? Wenn ja, hat da jemand Tipps bzw. die Befehle / eine Anleitung für so etwas?

Wahrscheinlich sind meine Probleme trivial, aber als Anfänger steige ich durch die Thematik noch nicht ganz durch.

Vielen Dank für jegliche Tipps und Hinweise.
Grüße
Micha

[Peter Klett]

Zum 1. Problem solltest Du nochmal genau darstellen, was in den jeweiligen Feldern steht, und wie die Ansicht aussehen soll, sonst gibt es zuviele Interpretationsmöglichkeiten zu der Frage.

Zum 2. Problem:

Der Admin pflegt ein Feld, und jeder Benutzer soll auch so eines haben? Wenn unterschiedliche Benutzer dort unterschiedliche Werte eintragen, was soll dann beim Admin-Dokument gelten?

Du kannst z.B. mittels @Dialogbox (Formel) oder NotesUIWorkspace.Dialogbox (Script) nur das eine Feld direkt im Admin-Dokument ändern lassen, musst aber auf die Zugriffsrechte achten. Hat der gewöhnliche Benutzer kein Bearbeitungsrecht auf das Admindokument, brauchst Du einen Agenten, der auf dem Server von einem höher berechtigten User ausgeführt wird.

Aber auch hier wäre es sinnvoll, wenn man mehr über den Sinn erfahren könnte.

[Mich90]

Guten Morgen,

erstmal vielen Dank für die Antwort.

zu Problem 1:
Ein Dokument sieht zum Beispiel so aus:
Feldname    :   Inhalt
fldMed00H4:Wirkstoff 1, Wirkstoff 2,Wirkstoff 3,Wirkstoff 4
fldMed00F2:Zahl1,Zahl2,Zahl3,Zahl4,
Land:Deutschland
Währung:Euro

Meine Ansicht soll nun folgendes darstellen:
Wirkstoffe    Zahlen    Land           Währung
Wirkstoff 1    Zahl1    Deutschland   Euro
Wirkstoff 2    Zahl2    Deutschland   Euro
Wirkstoff 3    Zahl3    Deutschland   Euro
Wirkstoff 4    Zahl4    Deutschland   Euro

Die Wirkstoffe konnte ich wie gesagt oben mit @Trim(@Explode(fldMed00H4; ",")) trennen. Allerdings habe ich bei den Zahlen das Problem, dass hier noch alle Werte drinstehen und ich nicht weiß, wie ich diese so trennen kann, dass immer die richtige Zahl zu dem dazugehörigem Wirkstoff angezeigt wird.

Zu Problem 2:
Jetzige Situation: Zu den Ländern werden bis jetzt immer nur von einer Person (Admin der Datenbank) bestimmte Felder ausgefüllt. Dazu wird immer per Mail von den Ländern geschrieben, was geändert werden muss. Das ist natürlich sehr umständlich. Nun sollen die Länder in ihrer Ansicht (andere Maske) dieses Feld ändern. Dazu muss das Feld dort ersteinmal existieren und die schon bestehenden Werte übernehmen.
Allerdings habe ich (als blutiger Anfänger) überhaupt keine Ahnung, wie ich den Bezug zum schon existierenden Feld der anderen Maske herstelle. Ich habe mir gedacht, ich könnte die beiden Felder einfach "gleichschalten", sodass beide denselben Inhalt haben, ohne groß etwas ändern zu müssen.

Ich hoffe diese Infos helfen weiter  

[Peter Klett]

Zum Problem 1:

Zeigst Du die Dokumente mit der Option "Mehrfachwerte getrennt anzeigen" in der Ansicht an? So dass es den Anschein hat, als wäre jeder Wert in einem eigenen Dokument? Dann kannst Du das nicht in zwei Spalten darstellen. Rechne in einer Spalte beide Werte (also Wirkstoff und Zahl) zusammen, so dass Du nachher z.B. folgende Werte IN EINER SPALTE anzeigst

Wirkstoff1 = Zahl1
Wirkstoff2 = Zahl2
usw.

Das wird dann häßlich bei

Wirkstoff mit langem Namen = 4,02
Kurzwirkstoff = 100,45

Auch umdrehen sieht nicht immer toll aus

4,01 = Wirkstoff mit langem Namen
100,45 = Kurzwirkstoff

Ob man ein TAB (@Char (9)) in einer Spalte verwenden kann, habe ich noch nicht probiert, aber richtig schick wird das nie.

Nutzt Du nicht "Mehrfachwerte getrennt anzeigen", geht es (bedingt) in zwei Spalten. Du musst dann in der Ansicht anzeigen, wieviele Zeilen je Spalte angezeigt werden können (max. 9) und gibst als Trennzeichen bei Mehrfachwert in der Spalte "Neue Zeile" an. Haken an der Sachen (und deshalb nur bedingt) ist, dass Dir die Spalten verrutschen können, z.B. ein automatischer Umburch in einer zu schmalen Spalte 1 führt dazu, dass die Spalte 2 nicht mehr zur Spalte 1 passt. Bei mehr als 9 Zeilen ist sowieso Ende. Sortieren der Spalten kannst Du dann allerdings auch vergessen. Ich würde daher auf jeden Fall die erste Variante vorziehen.

Das 2. Problem habe ich immer noch nicht ganz geschnallt. Ein automatisches "Bezug herstellen zu Feldern einer anderen Maske" gibt es so nicht, kann man aber natürlich bauen. Die Aussage "blutiger Anfänger" lässt allerdings die Erfolgsaussichten nicht rosig erscheinen ...

[Mich90]

Hallo,

vielen Dank für deinen Lösungsvorschlag. Allerdings war ich mit Ergebnissen nur teilweise zufrieden, welshalb ich nocheinmal mit deinem Stichwort "Mehrfachwerte" gegoogelt und siehe da, jemand hatte genau das selbe Problem und hat es sehr anschaulich beschrieben, wie ich finde:
http://www.madicon.de/tippstricks/index_files/000141.php
Das ist genau das, was ich erreichen wollte!

Das 2. Problem besteht leider immer noch:
Ich weiß leider nicht, wie ich es besser beschreiben soll. Vielleicht noch einen Versuch:
In einer Maske kann der Admin Werte für Länder eingeben, zB in das Feld Marke.
Das ist umständlich, da die Länder jeweils auch eine Maske Land haben und die Marke ja auch selbst eintragen könnten. Auf das Feld der Marken in der Admin-Maske basieren allerdings viele Anzeigen und Funktionen der Datenbank, weshalb ich das ungern alles ändern würde, die Chance hier Fehler zu machen wäre viel zu groß.
Deshalb:
Kann ich diese Felder in der Maske der normalen Benutzer auch irgendwie unterbringen, sodass die Werte natürlich überall identisch sind?
 

Vielen Dank auf jeden Fall schonmal für den 1. Ansatz !

Grüße,
Micha

[Peter Klett]

Die Lösung für 1. kannte ich auch noch nicht, ist ja wirklich einfach.

Nochmal zu 2.: Du hast also ein Admin-Dokument, in dem Du für jedes Land die Marke eintragen kannst. Dann hast Du für jedes Land ein eigenes Dokument, in das Du jetzt auch die Marke eintragen willst?

Am einfachsten ist dann ein periodisch laufender Agent, der die Werte aus den Länderdokumenten mit dem Admindokument abgleicht. Wie schon gesagt, eine automatische Synchronisation mit Haken setzen, synchronisiere Feld A mit Feld B, gibt es nicht (oder besser, ist mir nicht bekannt).

[Mich90]

Zu Lösung 2 : Hmm, das Feld muss nicht unbedingt im Admin-Dokument bleiben, es würde auch genügen, das Feld (allerdings inklusive der schon bestehenden Inhalte zu jedem Land) in die andere Maske zu migrieren? Wäre so etwas denn möglich? Ansonsten muss ich eben damit leben 

[Peter Klett]

Du musst schon wissen, was Du willst, dann geht ziemlich alles.

Erst schreibst Du, dass das Feld nicht aus dem Admindokument entfernt werden soll, weil Dokumente und Ansichten (Ansichten halte ich allerdings für ein Gerücht) sich die Informationen daraus holen.

Jetzt schreibst Du, dass es da nicht drin bleiben muss? Und die willst das Feld in eine andere Maske migrieren?

Falls Du soetwas suchst, wie: "Ich ziehe das Feld aus der Maske A in die Maske B, dadurch gibt das Dokument mit der Maske A die Inhalte logisch verteilt an Dokumente der Maske B ab und alle Funktionalitäten in der Datenbank (und vermutlich noch anderen Datenbanken, die darauf zugreifen) passen sich dem vollautomatisch an", dann musst Du in eine Verkaufsveranstaltung gehen, wo einem sowas schön bunt in PowerPoint präsentiert wird. Und sicherlich findest Du dort auch Leute, die das glauben (die nennt man "Entscheider"). Mit der Realität hat das allerdings nichts zu tun. 

Also im Ernst:

Wenn Du Ländereinstellungen hast, die zu Länderdokumenten gehören, dann bau die da ein, denn da gehören die auch hin. Wenn Du die Informationen schon in einem Admindokument hast, baue Dir eine Routine, die die Daten verteilt. Alternativ gibt es dafür die Drucker-Tastatur-Praktikanten-Lösung. Funktionalität, die auf das Admindokument schaut, musst Du umbauen. Zum Testen empfiehlt es sich absolut, die Felder (genau Items) aus dem Admindokument zu löschen (@Deletefield, oder NotesDocument.RemoveItem), denn durch das Löschen eines Feldes in einer Maske ändert sich kein einziges Item eines bestehenden Dokuments.

Wenn Du das alles nicht willst, kannst Du mit einer Notlösung, wie von mir vorher beschrieben - also die redundante Datenhaltung in Länder- und Admindokument incl. automatisiertem Datenabgleich - arbeiten.

Also: Erst musst Du wissen, was Du willst, dann kannst Du überlegen, wie es gehen soll, und dann kannst Du das bauen. Anders wird das nix.

[Mich90]

Und sicherlich findest Du dort auch Leute, die das glauben (die nennt man "Entscheider").

Ja und genau so einen habe ich á la: Es ist doch schon alles da, du musst das doch "nur mal eben" woanders hinschieben. Ich bin Azubi und dies ist keine Entwickler- sondern eine Anwenderabteilung in der ich gerade eingesetzt bin, also ist auch kein "Techniker" außer mir da, der mir da Unterstützung geben kann.

Na gut .. back to the topic:
Das, was jetzt in dem Admin-Dokument funktioniert, soll auf das Anwenderdokument übertragen werden. Nicht mehr, aber auch nicht weniger.
Eigentlich ist es egal, wie das gemacht wird, es sollte eben eine schöne und vor allem funktionierende Lösung sein. Da der Admin sowieso Zugriff auf alle Dokumente hat, müssen die Felder nicht im Admin-Dokument bleiben.
Ich war am Anfang der Ansicht, es wäre einfacher, die bisherige Funktionalität so zu belassen und beim Anwender ein neues Feld hinzuzufügen (eben Felder zu verknüpfen - geht nicht). Das scheint aber so einfach, wie ich mir das vorgestellt habe, ja nicht zu funktionieren.

[Peter Klett]

So in etwa hatte ich mir das schon gedacht ...

Dann solltest Du zuerst analysieren, welche Masken, Events (evtl. sogar weitere Datenbanken) usw. auf die Admindokumente zugreifen und diese Informationen verwenden. Das ist eine sehr schwierige Aufgabe, die Du so vermutlich nicht lösen kannst. Hast Du alle Stellen lokalisiert, kannst Du überlegen, ob ein Umbau wirtschaftlich ist. Wenn Du Azubi in einer Anwenderabteilung bist, stellt sich mir natürlich die Frage, wer das gebaut hat (Entwickler innerhalb / außerhalb der Firma / zugekaufte Software) und wer für den Betrieb der Datenbank verantwortlich ist. Mit denen solltest Du das unbedingt abstimmen.

U.U. operierst Du mit den Einstellungen direkt am offenen Herzen, das ist aus der Ferne aber nicht sicher zu beurteilen.

Wenn Du sicher gehen willst, dass die Anwendung nachher noch funktioniert, lässt Du grundsätzlich alles so, wie es ist. Die Einstellungen bleiben im Admin-Dokument, werden dort aber nicht mehr angezeigt oder nur noch zum Lesen, also nicht bearbeitbar. In die Länderdokumente nimmst Du im ersten Schritt die Einstellungen auf. Dann musst Du die Daten aus dem Admindokument in die Länderdokumente verteilen (vermutlich per Hand). Zuletzt baust Du eine Routine, die die Daten aus den Länderdokumenten in das Admindokument übernimmt. Dann hast Du die Steuerung des Systems unverändert über die Admindokumente, die Bearbeitung dieser Steuerung aber in den Länderdokumenten. Das ist nicht die ideale Lösung, die man bei einem Redesign erreichen würde, erscheint mir aber wesentlich wirtschaftlicher und sicherer.

[Mich90]

Hm, ja, so eine Lösung hatte ich schon beinahe erwartet, vielen dank!

Das mit dem "offenen Herzen" kann ich zumindest verneinen, da ich mir eine Lokale Replik gezogen habe, an der ich basteln kann. So kann wenigstens nichts produktives kaputt gehen

Vielen Dank !

[m3]

... bis zur nächsten Replikation.

Zum Spielen sind Kopien besser geeignet.

[klaussal]

Lokale Replik gezogen habe

Vorsicht, da können auch Design-Elemente repliziert werden !!

und mittels Replikation werden nicht nur Daten, sondern auch Design-Elemente (Masken, Ansichten, Agenten etc.) auf alle Server und Clients automatisch verteilt.

Besser: lokale Kopie

[klaussal]

 
zu langsam

[Peter Klett]

Mit offenem Herzen hatte ich auch eher die Funktionalität gemeint. Weißt Du denn, ob nicht andere Anwendungen hinten runterfallen würden, wenn sich an der Steuerung etwas ändert?

Replik finde ich genauso gefährlich, wie Martin (EDIT: und Klaus). Einmal über die Replikatorseite die Mails repliziert und falsch geklickt, ist die Änderung produktiv. Erstelle Dir eine Kopie der Datenbank als Testdatenbank und dann erstelle Dir auch noch eine Schablone, in der Du entwickelst, die Du dann jeweils über die Testdatenbank legst (Gestaltung aktualisieren oder Schablone wechseln). Wenn dann alles funktioniert, kann mit der Schablone die produktive Datenbank aktualisiert werden. Aber auch da würde ich mich erst einmal über das Freigabeverfahren mit den Admins oder anderen Entwicklern in der Firma unterhalten.  

[m3]

Ach, das ist doch kein Geschwindigkeitswettbewerb hier.

[Mich90]

Code

Zum Spielen sind Kopien besser geeignet.

Überzeugt !