Sichere Alternative für ComputeWithForm

[basile]

Liebe Mitforisten,

ich suche nach einer "sicheren" Alternative für ComputeWithForm. Die Aufgabenstellung ist in etwa folgendermaßen:
Ich habe Dokumente für (elektrische) Bauteile und möchte daraus "Geräte" bauen. Dabei soll können natürlich mehrere von einem Bauteil mehrere in einem Gerät vorhanden ein (1:n-Beziehung). Die Beziehung soll auf beiden Seiten (Bauteil und Gerät) transparent sein (über embedded view). Wenn sich z.B. der Name des Bauteils ändert, möchte ich das in dem Geräte-Dokument sehen (Update). -> eigentlich ein klassisches rel. Datenbank-Problem. Ich nutze aber Lotus.
Derzeit habe ich das mit "Linkdokumenten" gelöst. Solch ein Dokument wird für jede Beziehung eines Gerätes zu einem Bauteil angelegt (1:1-Relation).In so einem Linkdokument ist die UNID des Bauteils und des Gerätes drin, der Name von den beiden und die verbaute Anzahl.
Im Linkdokument kann ich den Namen des Bauteil über eine Ansicht abfragen (Feldformel), damit ist der immer aktuell.
Diese Aktualisierung eines Linkdokuments kann ich aber nicht aus einem anderen Dokument (Gerätedokument) anstossen. Zwar kann ich aus dem Gerätedokument einfache Feldupdates (z.B. Feldwert + 1) anstossen (ComputeWithForm), das Ergebnis wird dauch ganz toll geändert/gespeichert. Aber komplexe Aktionen wie z.B. einen Feldwert über einen View besorgen/ins Feld schreiben/Linkdokument speichern geht aber nicht. Die Speichermethode nach ComputeWithForm wartet nicht auf das vollständige Durchlaufen aller Scripte in allen Feldern??!!!!!
Meine Lösung sieht so aus, dass ich aus dem Gerätedokument(Bauteildokument) alle damit verknüpften Verknüfungsdokumente abklappere und den Update sozusagen "von Ferne" und "per Hand" mache. Das geht, widerspricht aber ganz kolossal meiner Auffassung von Objektorientierung.

Habt Ihr vielleicht eine gängige Lösung/Trick für dieses Problem in Eurer Schatzkiste?

In froher Erwartung

Udo

[basile]

nochwas dazu....
natürlich kann ich eine update-Methode in QuerySave des LinkDokumentes schreibehn und aus dem GeräteDokument alle Linkdokumente im Client (editierbar) öffnen/speichern/schließen, das ist zwar einigermaßen Objektorientiert, sieht aber bei 1000 Verknüpfungen auch irgendwie komisch aus, wenn die Tableiste über 10 sek flackert 

In froher Erwartung

Udo

[jo@chim]

Warum lagerst Du die Routine nicht auf einen Backgroundagenten aus? (RunOnServer)

[Peter Klett]

Bei 1000 mal Dokument öffnen, speichern und schließen raucht Dir der Client ab, denn es wird nicht sequentiell abgearbeitet. Irgendwann ist dann der Speicher voll und der NotesClient dahin.

Ich würde die ganzen Berechnungen in eine Script-Bibliothek bauen, die unabhängig vom geöffneten Dokument funktionieren. Diese Routine kannst Du dann beim Speichern aufrufen oder aber auch bei einer Änderung "von außen". Dabei hast Du dann nur einen Code, der gewartet werden muss.

[thkn777]

Da die Link-Dokumente die Teile-Bezeichnung statisch halten (sonst können diese nicht in Ansichten angezeigt werden), sollte ein Update eines Teile-Dokumentes den Update der Link-Dokumente nach sich ziehen. Ob vom Client direkt nach der Änderung, über eine Client-Aktion oder über einen zyklisch laufenden Wartungsagenten... das kommt darauf an.

Das Gerätedokument zeigt die Info's ja nur an... hat damit also (eigentlich) gar nichts zu tun.

Da ich aus Deinen Postings herausgelesen habe, daß Dir dieser Ansatz nicht gefällt, wie wäre es mit:


Alternative:
Teileliste dynamisch generieren - z.B. per Script in ein RichTextFeld schreiben. Also etwas zusätzlich zur embedded View. Das RTF kann man sinnvoll formatieren und hat ggf. sogar ein Dokument, das man als "Version x" ablegen kann. Und - es ist (analog zu SQL - "live"). Ich hatte bisher noch nie Probleme, wenn ein Nutzer ein paar Sekunden auf 20+ Seiten A4 warten mußte (Du sprachst von Teilelisten mit 1000+ Elementen).


Alternative2:
Analog, aber Export nach Word/Excel für eine bessere Darstellung / für den Druck / für Reports.


Für kleinere Datenmengen gab's da mal den TableWalker... aber da Du ja schon Linkdokumente nimmst, schau Dir mal meine beiden Alternativen an. Für die tägliche Arbeit (Teile zu Geräten hinzufügen etc. ist so eine RTF-Liste natürlich nicht gut geeignet.

Viel Erfolg,
Th.

[jo@chim]

Genau so ähnlich wie das Peter vorgeschlagen hat funktioniert das bei mir seit Jahren ohne Probleme: im Postsave die NoteID an einen Agenten per RunOnServer übergeben, der die Antwortdokumente mit den Referenzen auf das Hauptdokument aktualisiert...

...

Code

Call agent.RunOnServer(Source.Document.NoteID)

...

Code

Sub Initialize
	Dim session As New NotesSession
	Dim db As NotesDatabase
	Dim rdoc As NotesDocument
	Dim dc As NotesDocumentCollection
	Dim agent As NotesAgent
	
	Set agent = session.CurrentAgent	
	Set db = session.CurrentDatabase
	Set doc = db.GetDocumentByID( agent.ParameterDocID )
	Set dc = doc.responses
	
	If Not (dc Is Nothing) Then
		Set rdoc = dc.GetFirstDocument
		While Not ( rdoc Is Nothing )	
			On Error Resume Next
			Call rdoc.ComputeWithForm( False, False )
			Call rdoc.Save(True,False)
			Set rdoc = dc.GetNextDocument(rdoc)
		Wend
	End If
End Sub

[Peter Klett]

aber nicht mit ComputeWithForm, sondern per Script gerechnet ...

[basile]

Hallo Ihrs,

vielen Dank für Eure schnellen und ausführlichen Antworten. Das mit dem Agenten (zeit oder Eventgesteuert) oder den Script ist ein etwas anderer Weg, als ich jetzt nutze. Mein Problem ist, dass derjenige Programmierer, der aktualisieren will, sich immer genau die Dokumente ansehen muss und in einer extra Bibliothek/Maske/Whatever Code hinterlegen muss, der dann genau sagt, was in einem Dokumenttyp passieren soll. Ich dachte, es gibt einen mehr Objektorientierten Ansatz, in dem ich sagen kann: "Objekt (Linkdokument), aktualisiere Dich!", ohne im einzelnen genau zu wissen, was da passiert, da die Logik im Objekt (Dokumenttyp) selbst steckt.
Im Prinzip macht ComputWithForm genau das (die Logik steckt in den Feldern der Maske und diese werden halt durchlaufen und spulen ihren Code ab) - oder der Name suggeriert das. leider funktioniert ComputeWithForm nicht mit komplexen Formeln, die Beziehungen zu Views, etc... pflegen.
Ich habe ja keine Probleme, den Code aus der Maske auszulagern, aber das zwingt mich oder jmd. anderen in 1-2...10 Jahren dazu, sich dezidiert mit den Einzelheiten auseinanderzusetzen. Außerdem sollte ich in meinem Linkdokument keinen Felnamen ändern, dann knallt ... oder auch nicht und funktioniert einfach nicht mehr.

Alos, vielen Dank an Alle

Udo

[jo@chim]

Code

aber nicht mit ComputeWithForm, sondern per Script gerechnet ...

Was meinst Du denn damit Peter? Ist es nicht viel aufwändiger, per Script einzelne Felder zu aktualisieren als in einem Rutsch mit ComputeWithForm.?
(Ok StampAllMulti wär auch noch ne Alternative, wenn man tatsächlich nur einzelne Felder aktualisieren will und nicht alle Formeln in der Response neu berechnen...)

[basile]

Hallo Joachim,

ich sehe gerade Dein Posting:
genau das ist ja mein Problem: ComputWithForm klingt so, als wenn man die Methode aufruft und sich dann das Document aktualisiert. Man braucht sich keine Gedanken machen, was im einzelnen passiert und wie die Felder gefüllt werden, das sollen die eben selbst wissen.
Bei einfachen Operationen mach ComputeWitForm das auch (ich sach jetzt mal: "Liebes Feld, nehme Deinen Wert, addiere 1 hinzu und schrebibe den Wert in Dich rein!"). Das geht problemlos. Wenn aber die Operationen in einem Feld komplexer werden und noch Daten, wie in meinem Fall aus einem View kommen sollen, dann tut's ComputeWithForm einfach nicht. es passiert ... nichts. nichtmal ne Fehlermeldung. Das ist irgendwie bitter, denn man sieht nicht, wenns nicht klappt.

viele Grüße


Udo

[basile]

Hallo Joachim,

nochwas zu Deinem Posting: StampAll/StampAllMulti geht auch, da werden die Felder in einem Document "auf einen Rutsch" gesetzt. Aber auch da habe ich die Logik nicht in dem Dokument, in dem die Felder geetzt werden, sondern in der aufrufenden Routine.
Hier noch ein nettes Beispiel für StampAll:
http://johnjardin.ukuvuma.co.za/2011/10/24/lotusscript-tip-use-stampallmulti-to-avoid-unnecessary-looping/

IBM hat leider keins geliefert.

Viele Grüße

Udo
 

[Peter Klett]

Code

aber nicht mit ComputeWithForm, sondern per Script gerechnet ...

Was meinst Du denn damit Peter? Ist es nicht viel aufwändiger, per Script einzelne Felder zu aktualisieren als in einem Rutsch mit ComputeWithForm.?
(Ok StampAllMulti wär auch noch ne Alternative, wenn man tatsächlich nur einzelne Felder aktualisieren will und nicht alle Formeln in der Response neu berechnen...)

Ich meine damit, dass sich die Frage "Sichere Alternative für ComputeWithForm" wohl kaum mit "ComputeWithForm" beantworten lässt ...

[Tode]

Da liegst Du aber falsch @Udo: ComputeWithForm berechnet JEDE Formel, egal wie komplex sie ist, und ComputeWithForm wirft sogar einen Fehler, wenn man die Parameter entsprechend setzt.

Jetzt kommt das grosse "ABER": Fällt ComputeWithForm bei EINER Formel auf die Nase, dann sind nur die Felder OBERHALB des Fehlers berechnet, die Felder UNTERHALB nicht.

UND: ComputeWithForm ist sehr viel sensibler als ein Compute im Frontend.

Beispiel:

Du hast ein Datumsfeld "Datum" und füllst das per Script mit doc.Datum = "22.05.2014".
Wenn Du das Dokument nun im Frontend öffnest, und neu abspeicherst, dann wird das Klaglos in ein gültiges Datum umgewandelt, Du bekommst keinerlei Meldung o.ä. über einen falschen Typ.

ComputeWithForm wird aber an diesem Feld abbrechen mit der Fehlermeldung "Datum erwartet" und alle Felder UNTERHALB nicht mehr berechnen.

AUSSERDEM hat ComputeWithForm keinen Zugriff auf "Berechnet zur Anzeige"- Felder, was u.U. auch zu Fehlern führt.

Das heisst: ein ComputeWithForm darf man nur dann einsetzen, wenn man sich zu 100% sicher ist, dass alle Formeln / Felder zu jedem Zeitpunkt die richtigen Werte / Feldtypen haben, sonst bricht es ab.

WENN man es einsetzt, muss man den Parameter setzen, dass es einen Fehler wirft, und so lange rumprobieren, bis das COmputeWithForm ohne Fehler durchläuft...
Das ist ne Heiden- Arbeit, in der Zeit hat man im Normalfall die Formeln zur Neuberechnung in Script nachprogrammiert...

[Peter Klett]

Ergänzend muss noch erwähnt werden, dass ComputeWithForm keine Scripte ausführt. Und spätestens dann, wenn man vielleicht im Postrecalc oder Querysave Berechnungen einbaut, ist man damit am Ende.

Also besser gleich eine saubere Scriptlösung. Eine zentrale Bibliothek, in der die Routinen zur Aktualisierung der Dokumente enthalten sind, und überall zur Verfügung stehen.

Das entspricht sicher nicht Deiner - vollkommen verständlichen - Erwartung einer Objektorientierung, ist aber in der Praxis recht wartungsfreundlich.

[basile]

Hallo Tode,

was ich meinte ist, dass ComputeWithForm zwar auch komplexe Formeln ausführt, aber das Ergebnis nicht im Dokument gespeichert wird. Das SpeichernEvent scheint vorher ausgeführt zu werden und dann kommt erst das Ergebnis an.

Viele Grüße

Udo

[Tode]

Natürlich wird das Dokument nicht gespeichert... Dafür rufst Du ja nach dem rdoc.ComputeWithForm ein rdoc.Save auf...

WENN die Ergebnisse nicht gespeichert werden, dann läuft das ComputeWithForm nicht durch... gründe habe ich Dir genannt, das Debugging des "Warum" ist allerdings ziemlich zeitaufwändig..

[basile]

Hallo Tode,

natürlich wird erst beim doc.save gespeichert. Das ist klar. Das habe ich auch aufgerufen. das Problem ist nur, dass eben der Wert, der durch ComputeWithForm in das Feld rein soll, nicht drin ist. Daher ist meine Vermutung, dass das Ergebnis der Viewabfrage im Client zu lange dauert. Inzwischen ist das LotusScript, das ComputeWithForm aufgerufen hat schon weiter und hat das Dokument schon gespeichert (Multithreading). Das ist aber nur eine Vermutung von mir im Ergebnis kommt nix an und das ist ärgerlich.

viele Grüße und ein sonniges Wochenende

Udo

[koehlerbv]

Udo, ein Timing-Problem ist das garantiert nicht. ComputeWithForm kann eben einige Dinge nicht und je nach Parameter wird sowas übergangen oder die ganze Veranstaltung mit Gemecker abgebrochen. ComputeWithForm taugt für garantiert simpelste Forms, sonst ist es Russisches Roulett.

Fazit: Solche Konstrukte für Arme und simpel Gestrickte nimmt man nicht, sondern behält den Prozess selbst in der Hand.

HTH,
Bernhard

[Tode]

LotusScript ist nicht MultiThreading- Fähig und läuft erst weiter, wenn das ComputeWithForm durch ist.

Insofern sind Deine Vermutungen schlicht Humbug... Den Grund dafür, das die Felder nicht gefüllt sind, habe ich Dir schon genannt.

Falls mal jemand über diesen Thread läuft, der das WIRKLICH braucht (obwohl ich voll mit Bernhard übereinstimme: ComputeWithForm ist eine viel zu unsichere Sache, als dass man sich drauf verlassen kann), hier noch ein Tipp (und leider die einzig mir bekannte Art), wie man rausfindet, in welchem Feld das ComputeWithForm den Schluckauf kriegt:

Man baut ein temp- Feld in die Maske ein, berechnet, Formel: @Now. Dieses Feld verschiebt man so lange nach unten in der Maske, bis es nach dem ComputeWithForm NICHT einen aktuelleren Wert hat... Dann ist das Feld unmittelbar darüber das, was den Fehler verursacht...