Profile Document aus einer anderen DB öffnen

[macchina]

Hallo!

Steh hier vor einem kleinen Problem (vielleicht auch nur Denkfehler oder Brett vorm Kopf  )

Ausgangssituation:
Ich möchte in einer neuen DB sämtliche Profildokumente meiner DBs zentral verwalten. Dazu lege ich in der neuen DB pro Profildokument ein Dokument an (DBServer, DBFilepath, NameOfProfile). Mit einem Button möchte ich nun das Profildokument der entsprechenden DB öffnen.

Hier mein Code (ohne Errorhandling):

_{Dim s As New NotesSession
   Dim w As New NotesUIWorkspace   
   Dim thisdb As NotesDatabase
   Dim db As NotesDatabase
   Dim thisdoc As NotesDocument
   Dim uidoc As NotesUIDocument
   
   Set uidoc = w.CurrentDocument
   Set thisdoc = uidoc.Document
   Set thisdb = s.CurrentDatabase
   
   Set db = s.GetDatabase(thisdoc.DBServer(0),thisdoc.DBFilepath(0),False)
   
   Set  pdoc = db.GetProfileDocument( thisdoc.NameOfProfile(0) )
   
   Set uidoc = w.EditDocument(True,pdoc,False)}

Verhält sich hier das EditDocument so wie EditProfile? D.h. wird das so geöffnete Profildokument auch wieder richtig als Profildokument abgespeichert?

Vielen Dank für Eure Hilfe!

LG Ernstl

[pete_bla]

Hi,

also zum öffnen der Profildokument:
hast du auch berücksichtigt, dass Du eventuell einen Schlüssel, wie z.b. Username für
notesDatabase.GetProfileDocument( profilename$ [, uniqueKey$ ] )
benötigst?
ich würde Dir da noch zu GetProfileDocCollection(profilename$) raten, dann kannst du alle als NotesDocumentCollection holen.

Der EditDocument müsste schon das Profil sauber öffnen, habs aber nicht getestet.
Aus 5er und teilweise 6er Zeiten weiss ich aber, dass so ein öffnen von Dokumenten in einer anderen Datenbank Probleme mit der Maske und Teilmasken machen kann. Besonders <= 5 hat Notes dann versucht die Maske aus der lokalen (thisdb) zu verwenden.

Wenn Du das Profil sowieso herkopieren wills, dann würde ich Dir aber dazu raten,
die Profile als reguläre Dokumente zu speichern.

• Sie sind dann auch in Views auswertbar,
• Du brauchst keinen eindeutigen schlüssel (sonst darf ja nur für jedes eins pro DB exisiteren)
• keine "cache-Probleme"
• ..

Und als Profil brauchts du Sie eigentlich auch nicht in deiner DB.


Gruss, Pete(r)

[koehlerbv]

Das war aber nicht die Frage, Pete.

Die Antwort auf Ernst's Frage lautet "ja". Ich verstehe allerdings nicht, wozu das Verfahren gut sein soll. Die Performance wird schlechter, beim Anlegen der ProfileDocs kann es durchaus Probleme geben (siehe Pete's Posting), Du verlierst u.U. Vorteile von ProfileDocs.

Wenn Du zentralisieren willst, folge Pete's Ratschlag: Nimm normale Dokumente.

Bernhard

[MadMetzger]

Und das Handling der normalen Dokumente erleichtert die Klasse für UserProfile (Evtl geht die auch nicht User gebunden).

[macchina]

Hallo!

Vielen Dank für Eure Antworten.
Ich will die Profil-Dokumente der einzelnen Datenbanken nicht in eine neue DB kopieren, sondern lediglich aus einer zentralen (neuen) DB, die einzelnen Profildokumente aufrufen, überprüfen u. ggf. überarbeiten können.

Dinge die zentral ausgelesen werden können (wie bei mir z.b. Abteilungen, Mitarbeiter-Telefonnummern, Stellvertreter, Vorgesetzte, etc.) hab ich sowieso nicht in den Profildokumenten gespeichert. Es geht mir darum, daß ich mir zentral eine Plattform schaffe, von wo ich alle DB-Einstellungen "aller Datenbanken" verwalten kann, ohne mühsam alle Datenbanken durchzuforsten, um die Einstellungen zu kontrollieren.
Das Erstellen von Profildokumenten aus dieser Plattform heraus, ist nicht geplant (werde das irgendwie abfangen u. unterbinden). Die Erstbefüllung der Profildokumente soll immer in der Applikations-DB selbst erfolgen.

Aber wenn das mit ws.EditDocument klappt, ist meine Frage eh schon beantwortet 

Danke u. LG
Ernstl

P.S. den Schlüssel [UniqueKey] hab ich nirgendwo im Einsatz, bzw. könnte man als zusätzliches Feld abspeichern u. dann mitgeben.

[koehlerbv]

Und wenn Du "zentral verwaltest" und in dieser Zeit jemand die nutzniessende Datenbank offen hat, wird der die Änderung nicht mitbekommen, bis er diese wieder schliesst ... Das hat nun nichts mit Zentralität zu tun, sondern mit dem Caching von ProfileDocuments. Ergo: Lass die Finger davon, nimm normale Dokumente.

Bernhard

[macchina]

Ob ich das Profildokument von einer zentralen Stelle bearbeite oder direkt in der entsprechenden Datenbank, hat aber keinen Einfluss auf das Caching.
Ich habe bei meinen Datenbanken (dzt. ca. 150 dbs) keine Profil-Einstellungen, wo mich das Caching stört. Die Vor/Nachteile von Profildokumeten vs Normaldokumenten sind mir bekannt.
Einstellungen, bei denen das Caching nachteilig wäre, lese ich sowieso aus zentralen Datenbanken aus.

Ernstl