Ansicht auf Masken mit eingebeteter Ansicht

[heidiweber]

Hallo

Ich habe eine (Haupt-)Maske mit einer eingebeteten Ansicht. In dieser eingebeteten Ansicht werden Personen zu der (Haupt-)Makse angezeigt.

Jetzt habe ich eine Ansicht, in der die (Haupt-)Maske angezeigt wird. In einer Spalte sollen aber zusätzlich alle Vor-und Nachnamen der Personen angezeigt werden, die sich in der eingebeteten Ansicht befinden.

Wie kann man sowas machen?
Vielen Dank
cu
Heidi

[koehlerbv]

Eingebetete Ansichten sind was für ein Kloster ...

Die Daten, die in einem Dokument mittels einer eingebetteten Ansicht sichtbar sind, werden ad hoc gebildet und stehen Dir in einer Ansicht nicht zur Verfügung. Dort kannst Du nur Daten anzeigen, die im Dokument tatsächlich gespeichert sind.

Stehen die zugehörigen Personendokumente in der gleichen Datenbank?

Bernhard

[heidiweber]

Hi Bernhard,

die Personendokumente sind in der gleichen Datenbank.

cu
Heidi

p.s.: Eingebetete Ansichten sind was für ein Kloster ... --> mmmhh

[m3]

Eingebetete Ansichten sind was für ein Kloster ...

Aber bei den eingebetteten Ansichten musst Du beten, damit sie funktionieren.

[koehlerbv]

In diesem Fall hast Du noch die Möglichkeit, diese Personendokumente über eine Kategorisierung (sowas musst Du ja eigentlich bei der eingebetteten Ansicht auch verwenden) unter den Hauptdokumenten anzeigen lassen.
Diese jedoch in einer eigenen Spalte anzuzeigen geht nur, wenn die Namen im (Haupt)Dokument selbst gespeichert sind.

Bernhard

[heidiweber]

Sorry Bernhard- vielleicht habe ich das nicht geschnallt.

Ich kann die Personendokumente unter den Hauptdokumenten anzeigen lassen? Wenn ja, kann ich die dann "ausblenden", so dass man in der Ansicht nach den Vor-Nachnamen der Personen suchen kann? Falls das geht, wie muss ich dann kategorisieren? In der eingebeteten Ansicht selektiere ich doch nach den Personenmasken (Kategorie: UnID).


Vielen Dank an euch
cu
Heidi

p.s.: und warum beten - ich hatte bis jetzt noch keine Probleme mit eingebeteten Ansichten. Wie kann man das denn sonst machen?

[koehlerbv]

Eingebettet, Heidi. Eingebetet ist was ganz anderes.

Wenn Deine Schlüssel, mit der Haupt- und Personendokumente verkettet sind, eine ID ist, dann sieht es schlecht aus - Du müsstest im Personendokument ein Feld mit dem gleichen Inhalt wie die Hauptdokumente zur Sortierung haben, um kategorisieren zu können.
Anders wäre es bei Antwortdokumenten.

Aber eine Suche nach den Personennamen à la Ansichtssortierung in der 1. Spalte ist nicht möglich.

Bernhard

[heidiweber]

die sind über eine ID miteinander verbunden - dann gehts halt leider nicht - war ja nur als zusätzlichen Komfort gedacht...

Vielen Dank an euch
cu
Heidi

p.s. ich bete für die eingebettete Ansicht:) peinlich peinlich

[Axel]

die sind über eine ID miteinander verbunden - dann gehts halt leider nicht - war ja nur als zusätzlichen Komfort gedacht...

Wie sind die Dokumente genau miteinander verbunden? Deine Aussage ist viel zu allgemeingültig.


Axel

[heidiweber]

die Personenmaske hat nur ein Feld mit der UnID des Haupt-Dokumentes. Ist kein Mutter-Kind-Dokument.

cu
Heidi

p.s.: falls es nicht geht, ist es auch nicht so schlimm

[Axel]

Dann kannst du danach kategorisieren.

Spaltenformel:
@If(From = "Hauptmaske"; @Text(@DocumentUniqueID); FeldmitUNIDausPersenmaske)

Diese Spalte würde ich aber verbergen. Was du noch brauchst wäre ein Sortierfeld. Damit der Haupteintrag immer vor den Personen steht. In der Hauptmaske fügst du ein berechnetes Zahlenfeld ein in setzt den Wert auf 1. In der Personenmaske fügst du das gleiche Feld (berechnet, Zahlenfeld, gleicher Name wie im Hauptdokument!!) ein und setzt hier den Wert auf 2.

In der Ansicht fügst du dann dieses Feld in die zweite Spalte ein und sortierst diese. Auch diese Spalte verbirgst du am besten.

So sollte es ganz grob gesprochen möglich sein.


Axel

[heidiweber]

du meinst doch sicher:

@If(Form = "Hauptmaske"; @Text(@DocumentUniqueID); FeldmitUNIDausPersenmaske)

[koehlerbv]

Sowas kann man natürlich machen, aber dann geht ja jede Sortierung verloren, Axel:

Grzgbj
    Harry Hirsch
    Kuno Killerkarpfen
Dfgjosadr
    Wanda Fisch
    Super Man
Msadsaürt
    Schwulibert Geilhuber
    Walli Geier

Die erste Spalte ist also - sichtbar - wüst durcheinander, da sich die UNID nun nicht nach irgendeinem Feld des Dokuments richtet.
Was man natürlich nachträglich machen könnte, wäre - da ja die UNID des Hauptdokuments in den Personendokumenten steckt - diese doch per Agent zu Antwortdokumenten zu machen. Dann wäre es wieder gaaanz einfach. Aber hierfür sind ja auch noch ein paar andere Anpassungen erforderlich.

Bernhard

[flaite]

Dann wäre es wieder gaaanz einfach. Aber hierfür sind ja auch noch ein paar andere Anpassungen erforderlich.

Genau den selben Gedanken hatte ich auch.
Rein vom Modell her sind das ja auch vermutlich Parent-Child Beziehungen. Und der entsprechende Agent ist schnell geschrieben.

[koehlerbv]

Der Agent ist wirklich nur Pippifax. Da wir aber die gesamte Applikation nicht kennen, mag ich keine Prognosen darüber abgeben, was alles sonst noch anzupassen wäre: Ansichten ("show hierarchical"), die Personen-Maske als ResponseDoc, ... Gibt es sonst noch Aktionen, die mit Personendokumenten in Verbindung stehen?

Heidi sagt, das Ganze wäre nur ein "nice to have". Wenn das also nix grösseres werden soll ... Wenn doch: Dann hätte man sich das in der Planungsphase überlegen sollen, und ein Engagement in derartige Änderungen würde sich dann natürlich doch lohnen. Die Schaffung einer anderen Beziehung zwischen Haupt- und Personendokumenten würde ja in keiner Weise so effektiv funktionieren wie Parent-/Response-Docs (dieses Prinzip müsste dann ja nachgebaut und durch Update-Agents permanent am Leben gehalten werden müssen).

Bernhard

[Axel]

Sowas kann man natürlich machen, aber dann geht ja jede Sortierung verloren, Axel:

In diesem Fall muss ich recht geben. Aber....

Ich hatte mich dunkel dran erinnert, dass ich sowas schon mal gemacht hatte. Da war auch die Anforderung Dokumente für die Firma und Kontaktpersonen anzulegen, aber keine Haupt-  und Antwortdokumente zu verwenden. Nur konnte ich mich nicht mehr genau erinnern, wie ich das damals gemacht hatte. Ich habe jetzt mir die DB nochmal vorgenommen und mir die Ansicht angeschaut. Es ist doch etwas anders als ich oben geschrieben haben.

Die Dokumente sind auch über die ID verbunden. Außerdem enthalten die Personendokumente auch einige Infos des Hauptdokumentes, z.B. den Firmennamen.

Die Ansicht habe ich so aufgebaut

1.Spalte: Kategorisiert nach dem Firmennamen, Spalte sichtbar.
2.Spalte: UniqueID des Firmendokumentes, sortiert, Spalte unsichtbar
3.Spalte: Symbol zu grafischen Kennzeichnung Firma oder Kontaktperson, Spalte sichtbar
4.Spalte: Sortierfeld, wie oben beschrieben, damit zuerst Firma dann die Kontaktpersonen angezeigt werden, sortiert, Spalte unsichtbar.
5.Spalte: Beim Firmendokument wird "> Firma" angezeigt, sonst der Name der Kontaktperson, sortiert, Spalte sichtbar.

Ist einiger Aufwand, aber es funktioniert. Außerdem ist auch hier noch eine Update-Funktion für die Infos aus dem Firmendokument bei den Kontaktpersonen notwendig. Alles in allem und nach den Erfahrungen der Umsetzung würde ich sowas heute eigentlich nur noch mit Haupt- und Antwortdokumenten realiseren.


Axel

[heidiweber]

Ich bedanke mich vorerst bei euch. Leider bin ich nächste Woche auf Dienstreise. Kann das somit erst übernachste Woche ausprobieren:(((

Werde mich auf jedenfall diesbezüglich nochmals melden.
cu
Heidi

[koehlerbv]

Axel, was machst Du eigentlich mit der Spalte Nr. 2? Wenn ich jetzt nichts übersehe, sieht Deine Ansicht für den Nutzer so aus wie von Dir abgebildet - auch ohne zweite Spalte.

Bernhard

[Axel]

Gute Frage. Du kannst damit fast recht haben. 

In dieser Datenbank gibt es noch andere Ansichten, ohne Kategorisierung in der ersten Spalte. Und dann brauch ich die DocumentID, damit Firma und Kontaktperson zusammenstehen. Die abgebildete Ansicht habe ich dann per Copy & Paste eingefügt und die Kategoriespalte vorangesetzt. Dabei habe ich nicht probiert, ob man die ID-Spalte weglassen kann.

Ist ein guter Hinweis. Danke.


Axel