berechnete Felder refreshen

[dh-paule]

Hallo Jungs,

heut will ich's wissen ;-)

Folgendes Problem: Ich habe in einer Maske (Abfrage) berechnete Felder welchen Ihren Inhalt aus einer anderen Maske (Bezug) beziehen. Ändere ich nun die Maske (Bezug) so ändert sich das entsprechende Feld  in der Maske (Abfrage) erst nachdem ich die Dokumente geöffnet, bearbeitet und gespeichert habe. :-(

Wie bekomme ich es hin das nach einer Änderung in der Maske (Bezug) die Änderungen auf alle zugehörigen Dokumente übertragen wird?

[Semeaphoros]

Da berechnete Felder eine reine Angelegenheit des UI ist, muss dies leider ausprogrammiert werden, sprich im QuerySave des Ausgangsdokumentes muss für das Nachtragen in abhängigen Dokumenten gesorgt werden. Datentechnisch ist diese Architektur (wegen der Datendupletten) ziemlich kritisch, stellt sich also die Frage, ob man das nicht durch eine Architekturänderung anders lösen könnte

[botschi]

Moin,

kannst Du nicht Haupt- und Antwortdokumente draus machen? Denn vererbt sich eine Änderung in der Hauptmaske automatisch in die Antwortmaske.
Natürlich sind noch kleine Haken und Formeln nötig, aber unterm Strich ist das eine sehr einfache und schnelle Lösung.

[Glombi]

Auch bei Haupt- und Antworten ist das kein relationales System. Änderungen werden nicht automatisch in die anderen Dokumente geschrieben, sondern man muss das programmieren.

Aus diesem Grund - und auch wegen der von Semeaphorus bereits angesprochenen Speicher- und Replizierkonflikte - empfehlen sich Felder, die Berechnet zur Anzeige sind. Dort dann per @DbLookup den Wert aus dem anderen Dokument zur Laufzeit lesen.
Nachteil dieser Lösung: Zur Anzeige berechnete Felder können nicht in Views dargestellt werden.

Andreas

[dh-paule]

Hallo botschi,

für Haupt- und Antwortdokumente  ist es zuspät, ich habe da schon 14000 Dok's drin :-)

Hallo Semeaphoros,

die Architektur ist ja gerade mein Problem :-(
Es geht um eine Kunden/Geräte DB. Alle Kunden habe eine Kundenummer und die zugehörigen Geräte sind über die Kundenummer verknüpft. In der Gerätemaske sind nur die Kundennummer + Gerätenummer + Beschreibung abgelegt. Die Kundendaten werden als berechneter Text zur Anzeige gebracht.

Nun möchte ich die Kundendaten als berechnete Felder einfügen da ich das Problem habe das ich in einer view mit allen Geräten "nur" die Kundenummer sehen kann, nicht die Kundendaten wie z.B. den Ort. Leider funzt dBLookUp in view's nicht.

Wenn es also eine Möglichkeit gäbe in einer view die Kundendaten zum Gerät anzuzeigen, dann würde ich liebend gern auf das mitführen der Kundendaten in berechneten Feldern verzichten.

[dh-paule]

@Glombi

DANKE, genau das ist die Zusammenfassung meines Problems ;-)
[zeitgleich geschrieben]

[Semeaphoros]

Das geht nur wie ich schon gesagt habe, indem man das selber nachführt, und das ist nicht ganz trivial, muss vor allem auch sauber implementiert werden, wenn man nicht irgendwann einen unlösbaren Pflegeaufwand der Applikation haben möchte. In meinem letztjähriten Vortrag zu Objekten gibt es eine Beispielapplikation, die so etwas macht: unter http://www.ligonet.ch gibt es das Vortragsmaterial und die Beispiele.

[Glombi]

Seit R5 finde ich die Lösung, sogenannte Embedded Views zu verwenden, wesentlich eleganten, als immer alle möglichen Felder mitzuschleppen und dann bei einer kleinen Änderung zig Dokumente zu aktualisieren.

Daher mein Vorschlag: Baue in die Maske Geräte eine eingebettete Ansicht ein - mit Single Category (Sorry, ich kenne nur die englischen Begriffe auswendig). Der Schlüssel für die SIngle Category ist die Kundennummer, die ja bereits in der Gerätemaske ist.
Die Ansicht, die als eingebettete Ansicht verwendet wird, muss dann nach der Kundennummer kategorisiert sein.

Damit kannst Du das zwar nicht in der View darstellen, aber "relational" im Dokument.

Andersherum funktioniert das natürlich auch: Du kannst im Kundendokument alle Geräte anzeigen, die der Kunde hat.

Andreas

[dh-paule]

@Glombi,

genau das habe ich gemacht. In der Kundenmaske ist eine embedded view die alle Geräte des Kunden anzeigt. Mir reicht das auch so, aber die User möchten halt in der Geräteliste nicht extra auf das Gerät klicken um das Dok. zu öffnen sondern wollen schon in der view sehen wo das Gerät steht.

[koehlerbv]

Eine von sicher vielen denkbaren Varianten:

View nimmt Kunden- und Gerätedocs auf.
View ist kategorisiert nach Kunde
Per hidden column sortiertst Du die Docs vor: Zuerst Kunde, dann alle Geräte
In der eigentlichen Anzeigespalte zeigst Du - wenn Geräte-Dokument - die von Dir gewünschten Angaben, sonst die Angaben zum Kunden.
Das ganze kann man dann ja auch noch schon mehrzeilig aufbauen.

Wie gesagt - nur EINE Idee, aber evtl. die simpelste.

Bernhard

[Glombi]

Wie wär es mit der Dokumentvorschau?
Du machst eine Rahmengruppe mit 3 Frames:
Links: Navigation
Rechts oben: Ansicht
Rechts unten: Dokumentvorschau.

Falls das den Usern auch nicht genehm ist, musst Du wohl oder übel die Felder als berechnete Felder aufnehmen und bei einer Änderung im Kundendokument diese ändern. Das ist aber programmtechnisch easy.
Bspw. im QueryClose abfragen, ob sich diese Felder geändert haben. Falls ja, eine NotesDocumentCollection anhand der Kundennummer holen und dann in die zugehörigen Dokumente schreiben.

Andreas

[Semeaphoros]

Wohl eine der wenigen Varianten, die ohne Nachführen der Daten funktioniert, macht aber die View recht "unhantlich" für den Entwickler und damit für Anpassungen. Aber ohne irgend einen Preis geht das sowieso nicht ab.