Mit Agent auf andere DB zugreifen

[yannick]

Darüber müsste ich mich jetzt noch informieren (Chef natürlich grad nicht da).

Falls nicht...Gibt es noch eine andere Möglichkeit das Excel-Sheet direkt auf dem Server zu bearbeiten? Das RT-Item sollte sich doch eigentlich auch bearbeiten lassen, oder?

[koehlerbv]

Nein, da gibt es für Dich keine andere Möglichkeit - ohne Excel kommst Du an kein Excel-Objekt heran.

Bernhard

[Peter Klett]

Natürlich kannst Du das RTItem bearbeiten. Da kannst Du zum Beispiel die Exceldatei lösen. Aber das ist nur eine Datei und zum Lösen der Datei verwendest Du Funktionen von Notes. Um die Exceldatei zu bearbeiten, verwendest Du Funktionen von Excel, die Du ohne Excel nicht hast. Wird dann auch spannend, wenn der Server unter Linux läuft.

[yannick]

Verdammt. Dann werde ich mal nachfragen, bezweifel aber stark, dass Excel installiert ist.

Okay, angenommen Excel wäre vorhanden und die Bearbeitung auf der temporären Datei wäre fertig. Jetzt muss ich ja die Excel-Datei wieder in das RT-Feld bekommen. Also einfach gedacht müsste ich jetzt alles rückgängig machen. Also erst das Object setzen, dann das Object an das RTItem hängen und zum Schluss das alte RTItem durch das neue ersetzen im Dokument. Allerdings will das bei mir nicht so ganz klappen  

Code

	Dim rtitemNew As NotesRichTextItem	
	Dim objNew As NotesEmbeddedObject
	Set rtitemNew = New NotesRichTextItem( doc, "Body" )
	Set objNew = rtitemNew.EmbedObject _
	( EMBED_ATTACHMENT, "", "c:\\temp\\text.xls")

Jetzt habe ich doch ein neues RTItem mit dem überarbeiteten Excel-Dokument als Embedded-Object oder?

[Peter Klett]

Nein, Du hast jetzt zwei RTItems. Lösche vorher das alte

Call doc.RemoveItem ("Body")

Am Ende nicht vergessen, das Dokument zu speichern

Call doc.Save (True, True)

[yannick]

Okay, nach der Bearbeitung des Dokuments habe ich folgenden Code:

Code

	doc.Removeitem("template")	'altes Feld mit RT-Item
	Dim rtitemNew As NotesRichTextItem	
	Dim objNew As NotesEmbeddedObject
	Set rtitemNew = doc.Createrichtextitem("template") 'neues Feld mit RT-Item
	Set objNew = rtitemNew.EmbedObject _
	( EMBED_ATTACHMENT, "", "c:\\temp\\template.xls")
	
	Call doc.Save(true, false)

Das ganze funktioniert soweit auch. Jetzt wird, nachdem der Agent ausgeführt wurde, das RT-Item (also das Icon) nicht mehr als Excel-Icon angezeigt, sondern einfach ein graues Viereck...Öffnen kann ich es ganz normal.
Dann muss ich jetzt noch die eigentliche Form mit dem, in dem jetzt erstellten Dokument vorhandenem Excel-Sheet, verknüpfen. Also bisher hatte ich in einer Form einfach ein Excel-Sheet als Attachment. Dieses Excel-Sheet soll jetzt immer das neue Excel-Dokument als Quelle verwenden.

[Peter Klett]

Nun kommen wir doch langsam zu der Frage, was Du eigentlich vorhast.

Was passiert mit der Datei? In welchem Kontext wird die genutzt und wozu?

[koehlerbv]

Was man jetzt schon sagen kann: Das gegenwärtige Konzept ist zu 100% untauglich und falsch.

Sowie ein richtiger Administrator den Domino unter seiner Kuratel hat, wird dort Excel nicht laufen.
Und Excel auf dem Domino ist für diesen Zweck sowieso unnötig: Du willst doch offensichtlich neue Dokumente erstellen lassen mit einem Excel-Sheet, das auf den aktuellsten Werten basiert.
Dann sollte man in das Setup-Dokument (wie nun schon erreicht) das Vorlage-Sheet packen (nicht aktuell gehalten). Beim Erstellen eines neuen Dokuments wird dieses *lokal* beim Anwender gelöst, dann läuft der Prozess der Zellenaktualisierung und *dann* wird das Sheet an das neue Notes-Dokument geklatscht.

HTH,
Bernhard

PS: FYI - beim Anhängen im Backend bekommst Du immer das graue Standardsymbol - völlig unabhängig von Excel oder irgendeiner anderern Anwendung, mit denen das Dateiformat im Frontend (Windows) verknüpft ist.

[yannick]

So - nach einer kurzen Mittagspause bin ich auf den gleichen Schluss gekommen. Ich wollte nur erstmal den Ablauf Sheet extrahieren-bearbeiten-hochladen im Gesamten fertig haben. Dass das Konzept so nicht richtig ist, wurde mir auch relativ schnell klar. Wenn man neu ist in dieser Umgebung, weiß man nicht immer genau was wie möglich ist. Aber ich möchte mich gerne hineinarbeiten und dazu lernen.
Also wie ich es jetzt geplant habe: Man klickt auf den entsprechenden Button und gelangt zu der besagten Form. Dort kann man sich (wahrscheinlich einfach wieder über einen Button "download") das Sheet runterladen. Bei diesem Vorgang passiert dann genau das, was ihr mir in den letzten Post erklärt habt. Da der User sich das Sheet sowieso runterladen (also speichern) muss, kann man also das hinterlegte Sheet wie beschrieben auf dem PC des Users speichern und auch gleich dort aktualisieren.
Ist das jetzt vom Konzept besser?
Danke und Gruß

[Peter Klett]

ja

[yannick]

Super, klappt wunderbar. Also nochmal vielen Dank an alle Helfer! Schön, dass hier auch einem Neuling weitergeholfen wird

[yannick]

Hallo zusammen,
da ich nicht noch einmal einen neuen Thread aufmachen wollte, und es auch gut hier rein passt schreibe ich es einfach hier. Zur Angelegenheit:
In unserer Datenbank werden nur Dokumente einer Form gespeichert (es ist quasi wie ein Formular). Dieses Formular hat mehrere sections. Unter bestimmten Umständen (die hier jetzt unwichtig sind) wird in einer anderen DB (DB2) ein Dokument, das über einen primary key eindeutig zu dem Dokument in unserer DB zugeordnet werden kann, erstellt. Im Moment müsste der User, der den Antrag in unserer DB stellt, am Ende das "Ergebnis" einmal in DB2 eintragen, und einmal in die entspr. section aus dem Formular unserer DB. Da der User aber i.d.R. seine Ergebnisse nur in DB2 einträgt wollten wir diese Felder mit unseren Feldern "synchronisieren".
Da ich, wie gesagt, noch relativ neu in Lotus Notes/Domino (ca. 2-3 Wochen) bin wollte ich euch meine Ideen dazu vorstellen. Der Grund ist, dass wir morgen ein Meeting darüber haben und wir quasi die Besitzer der anderen DB davon überzeugen müssen, dass diese Synchronisation nötig ist, und eben dementsprechend auch Möglichkeiten vorstellen müssen was wir uns bisher gedacht haben. Hier also meine Ideen:

1. Infos manuell über Button aus DB2 holen:
    Einen Button in unser Formular integrieren, der (nur) für dieses Dokument die section im Formular mit den Daten aus DB2 füllt.
    Voraussetzung: Jeder User unserer DB, der den Button betätigen kann (können nur bestimmte Rollen) bräuchte Lesezugriff
    auf DB2.
2. Infos periodisch über Agent aus DB2 holen:
    Einen Agent programmieren, der periodisch (z.B. wöchentlich) die sections aller Dokumente unserer DB mit den Daten aus den
    jeweiligen Dokumenten der DB2 füllt.
    Voraussetzung: Unsere DB bräuchte Lesezugriff auf DB2 und müsste dort als Trusted Server eingetragen sein.
3. Trigger in DB2
    Einen Agent in DB2 einbauen, der, sobald die entsprechenden Felder in DB2 gefüllt wurden,  diese an das entsprechende
    Dokument in unserer DB sendet.

Ich denke Nummer3 wäre am besten, wird aber wohl nicht umsetzbar sein, da dies Programmieraufwand für die Leute der DB2 bedeutet. Nummer2 wird wahrscheinlich wegfallen, da Nummer1 (meiner Meinung nach) wohl am einfachsten umzusetzen wäre.

Meine Fragen wären jetzt zum einen, ob es vielleicht noch andere Möglichkeiten gibt, die wir von unserer Seite her umsetzen können? Und zum anderen welche Voraussetzungen bestehen müssten, damit diese Möglichkeiten umsetzbar wären (Stichwort Access etc.)?

Ich hoffe das "Problem" ist einigermaßen rübergekommen, falls ihr sonst noch etwas wissen müsstet einfach nachfragen. Und schonmal vielen Dank!

[Peter Klett]

Deine Frage ist schwierig zu beantworten, da das Umfeld völlig unklar ist. Im vorhergehenden Thread dreht sich alles um Excel, jetzt schreibst Du "Stichwort Access". Meinst Du damit MS Access oder den Zugriff auf die andere Datenbank?

Wenn die gewünschten Daten in der db2 in Notes gehalten sind (also Items in Dokumenten, keine Dateianhänge), würde ich in die Maske der db1 Felder "berechnet zur Anzeige" einbauen, die die Informationen aus der db2 beim Öffnen des Dokuments aktuell holen. Diese Informationen werden allerdings nicht im Dokument der db1 gespeichert. Zugriff auf db2 wäre wie bei Deiner Idee 1. Da folgt die nächste Unklarheit: Wozu werden die Informationen gebraucht? Nur zum Anschauen, wenn das Dokument geöffnet ist, oder soll damit auch im Hintergrund gerechnet werden und die Daten müssen in der db1 gespeichert sein?

Der Trigger in db2 hat einen Nachteil, wenn db1 aus irgendeinem Grund nicht verfügbar ist (Server läuft nicht, Zugriff fehlt o.ä.), erfolgt keine Übertragung der Änderung. Welches Event holt das später nach?

Ein periodischer Agent, der die Daten abgleicht, ist m.E. die beste Wahl, außer die Daten müssen realtime aktuell sein. Und dann ist da wieder die Unklarheit von oben: liegen die Daten in Excel, wird es mit dem periodischen Agenten schwierig (das hatten wir schon diskutiert).

EDIT: Bei "berechnet zur Anzeige" müssen natürlich alle Zugriff auf db2 haben, hatte überlesen, dass es nur ein bestimmter Kreis Benutzer sein soll. Wie häufig ändern sich die Daten? Wenn niemand auf den Button drückt, bleiben die alt.

[yannick]

Okay, wie gesagt, die Fragen beantworte ich gern.

Also bei den "Daten" handelt es sich um ganz normale Textfelder (also hier geht´s nicht um Excel!). Die DB2 ist ebenfalls in Notes gehalten. Also ich meine den Zugriff auf die DB2. Diese Daten werden "leider" in der DB2 gebraucht, um auch mit ihnen zu rechnen. Sie müssen also in unserer DB gespeichert werden; sie werden z.B. auch in ein Excel-Sheet exportiert. Die Daten müssen daher auch nicht realtime aktuell sein. Es würde genügen zum einen den Button einzufügen, mit dem man "manuell" die Daten aktualisieren kann und zum anderen bevor die Daten in das Excel-Sheet exportiert werden einen Agent laufen zu lassen, der dies automatisch für alle Dokumente macht. Der Export in Excel wird manuell angestoßen, somit wäre das gleiche bei dem Agent, der die Dokumente vorher aktualisiert.

Was würden wir für diese Methode also benötigen?
- alle "Rollen", die den Button betätigen können brauchen Lesezugriff auf DB2
- programmatische Namen der Views und Felder, von denen wir die Daten ziehen wollen
- Servername und Filepath
Ist das alles was wir dafür benötigen?

[Peter Klett]

ich meine ja, unter der Voraussetzung, dass die Benutzer überhaupt auf den Server der db2 zugreifen dürfen (was natürlich in "Lesezugriff auf db2" enthalten, aber eine ganz andere Baustelle ist)

[Peter Klett]

Die Antwort bezieht sich natürlich nur auf das Verhältnis zur db2 (so habe ich die Frage verstanden). Innerhalb Eurer db muss natürlich derjenige, der alle Dokumente aktualisieren soll, diese auch bearbeiten dürfen.

[koehlerbv]

- alle "Rollen", die den Button betätigen können brauchen Lesezugriff auf DB2

Nur theoretisch. Du kannst auch den Agent auf dem / vom Server lassen. Das kannst Du auch über einen Button manuell triggern (NotesAgent.RunOnServer).

Okay, wie gesagt, die Fragen beantworte ich gern.

Das würde ich nicht machen: Nimm die ReplicaID. Im Konfig-Dokument der ausführenden DB baust Du für den lieben Admin einen Buhtong, mit dem er die gewünschte DB2 aufwählen kann und im Hintergrund speicherst Du deren ReplicaID.

HTH,
Bernhard

[Peter Klett]

ReplicaID oder Dateiname ist auch wieder so eine Philosophiefrage. Definition in einem Konfigurationsdokument ist selbstverständlich, also niemals Server und Dateinamen oder IDs hart im Code verdrahten. Mir ist die Methode mit der ReplicaID zu wackelig und verwende deshalb lieber Server- und Dateiname, der ggf. aktualisiert werden muss (aber bei einer Reparatur einer Datenbank über eine Kopie muss die ReplikID aktualisiert werden, wir hatten schon beide Fälle). Bei ReplicaID bin ich mir nicht sicher, was passiert, wenn ich eine Kachel zuoberst auf dem Desktop habe, die auf einem anderen Server liegt, als das Programm eigentlich öffnen möchte. Ich meine, dass u.U. der Server vom Desktop gewinnt (zumindest, wenn der gewollte Server nicht erreichbar ist). Eventuell greife ich dann auf eine lokale Uralt-Replik zu und arbeite mit falschen Daten. Da ist mir ein kontrollierter Abbruch (Datenbank kann nicht geöffnet werden, Vorgang wird nicht durchgeführt) lieber.

Da Bernhard damit anscheinend keine schlechten Erfahrungen gemacht hat, scheint es so schlimm nicht zu sein, wie mir mein Bauch sagt, ich würde mich aber entschieden dagegen wehren, das als die einzig richtige Variante darzustellen.

[koehlerbv]

Nein, das ist natürlich kein Dogma. Du überlässt aber mit der Replica den Admins mehr Möglichkeiten als mit Server / Dateiname.
Welcher Server für das Suchen der ReplicaID verwendet wird, kannst Du programmatisch selbst bestimmen (was Yannick hier ja auch machen muss).

Bernhard

[flaite]

Ich habs in überdurchnittlich sorgfältig entwickelten und/oder wirklich großen Domino-Anwendungen öfter mit Replica-ID gesehen. Ist natürlich kein Dogma.

Eine für Anwendungs-Betreuer (oft Admins) gut sichtbare und verständliche Fehlermeldung ist für die ja hoffentlich nicht wöchentlich auftretenden Server-Umzüge per Kopie ECHT WICHTIG und EINE TOTAL GUTE IDEE (Stichwort defensive coding).

Die Autoren des Java-Codes mit dem ich so arbeite, berücksichtigen olche checks ob Objekt wirklich da, in geschätzten 80% der Fälle nicht. Hat mich heute morgen wieder 90 Minuten Geisterbahn in code, den ich weder verstehen muss noch soll noch will gekostet.  
Das durchschnittliche Verhalten ist:
- in den ersten 6 Monaten nach der Uni übertrieben viele Objekte auf null zu checken, auch wenn die nie null sein können.
- ab 6 Monaten bis zum Einstellen der Entwicklertätigkeit auf null checks grundsätzlich zu verzichten.