Profildokument

[Legolas]

Hallo Forum,

ich sehe den Wald vor lauter Bäumen wohl nicht mehr!!

Mein Problem:
Eine Anwendung hat ein Profildokument. Dieses will ich zu Backupzwecken manuell in ein "normales" Notesdokument sichern. Allerdings muss noch eine
Datei angehängt werden, die auf dem Dominoserver liegt.

Hört sich erst mal nicht dramatisch an!
Aber...

Wenn ich nun das Profildokument in ein neues Dokument kopiere und dieses dann per agent.runonserver dem Backend übergebe um auf dem Dominoserver noch eine Datei anzuhängen die dort im Dateiverzeichnis liegt, gibt es lauter seltsame phänomene. 

Wie z.B.:
- Das per agent übergebene Dokument ist manchmal nicht vorhanden
- Das Profildokument ist manchmal zurückgesetz nach dem Kopiervorgang
- usw.

Für mich sieht es aus, als wenn beim kopieren eine Referenz zwischen den Dokumenten bestehen bleiben würde die hier alles zum spinnen bringt.

Code

initialisierung usw...
 
	Set konfigDoc = ws.Currentdocument.Document
		If konfigDoc Is Nothing Then
			IB_MsgBox "No UI document" , 64, "Co_Hinweis"
			Exit function
		End If
		
		Set archiveDoc = CurrentDatabase.Createdocument()
		Call konfigDoc.Copyallitems(archiveDoc, True)
		Call archiveDoc.Save(True, False)
		Call archiveDoc.Replaceitemvalue("Form", "BackupConfiguration")
		Call archiveDoc.Replaceitemvalue("C_Dokart", "BackupConfiguration")
		Call archiveDoc.Replaceitemvalue("BackupName", vZwerg)
		Call archiveDoc.Save(True, False)
		
		'Agent zum sichern der Client.Store Datei auf dem Server starten
		Set agent = CURRENTDatabase.Getagent("Backup_Save_Client.Store")
		If agent Is Nothing Then
			Call C_ALog("E", 1, "Agent: Backup_Save_Client.Store not found!", "")
		Else
			Call agent.Runonserver(archiveDoc.Noteid)			
		End If
 

Hier der Azuszug aus dem RunOnServer Agenten
Ich habe hier versucht zu testzwecken das Dokument nochmals mit der UNID zu öffnen. Hier kommt dann die Meldung, dass das Dokument nicht vorhanden ist!

Code

' Aktueller Agent
	Set agent = ses.CurrentAgent
	Set archivDoc = CURRENTDatabase.GetDocumentByID(agent.ParameterDocID)
 
	If archiveDoc Is Nothing Then
		Call C_ALog("E", 1, "Can't find dbsetup for detache client.store file!", "")
		Exit sub 		
	End If
	
	unid = archivDoc.Universalid
	Print "####  unid: " & unid
	Set archivDoc = Nothing
	
	Set archivDocNew = CURRENTDatabase.Getdocumentbyunid(unid)
	If Not archivDocNew Is Nothing Then
		Call C_ALog("E", 1, "archiveDoc not found!", "") 
		exit sub	
	End If

Umgebung:
Notes und Domino 9 deutsch aktuellste Version



Grüße
Bernd

[Peter Klett]

konfigdoc ist das Profildokument und archivedoc das "normale"?

Ich könnte mir vorstellen, dass Du mit

Call konfigDoc.Copyallitems(archiveDoc, True)

irgendwelche Flags oder Felder mitkopierst, die Dir in die Suppe spucken, z.B. ein Leserfeld für den Benutzer, das dafür sorgt, dass das Dokument nicht vom Agentenunterzeichner gelesen werden kann.

Ich würde mir mal die Felderliste vom archivedoc ansehen, ob da Items enthalten sind, die Du dort definitiv nicht benötigst. Diese Items könntest Du nach dem Copyallitems einzeln löschen, oder Du definierst, welche Felder Du übernehmen willst. Erstes ist vermutlich einfacher und wartungsfreier.

[ascabg]

Hallo,

Eventuell konnte man in diesem Fall auch einmal kontrollieren, was NotesDocument.IsProfile
(hier also atchivedoc.IsProfile) zurueckliefert.


Andreas

[Thomas Schulte]

Aus bitterer Erfahrung mit einer Funktion, die genau das tun sollte, Items aus einem Profildokument in ein neues normales Dokument kopieren um dort Werte vorzubelegen, kann ich dir sagen, das funktioniert so nicht. Du musst durch alle Items einzeln durchgehen und jedes Item für sich kopieren.
Übrigens, das war noch mit Version 5 und 6. Da hat sich seitdem nichts geändert.
Ich hatte ähnliche Verhaltensweisen. Profildocument war plötzlicht leer. Oder ganz weg. Oder das neue Dokument war leer und solche Spielereien.

[Legolas]

Hallo Zusammen,

danke für die Rckmeldung.
Ich habe dies leider schon geahnt!

Werde wohl nicht drum rum kommen, die gefühlten 200.000 Felder manuell zu kopiern.

Grüße
Bernd

[koehlerbv]

Du wirst Dich leichter tun, die Profile Document-typischen Items nach einem CopyAallItems wieder zu removen.

Bernhard

[Legolas]

Hallo Bernhard,

bin mir da nicht so sicher!

Zum Einen kenn ich die Profildokument spezifischen Felder nicht genau und glaube auch, dass diese nicht alle ersichtlich sind.
Zum Anderen bezweifele ich mal, dass solche phänomene wie das nach dem Kopiervorgang auf einmal das Quellprofildokument leer ist, auf diesem Wege behoben sein werden.

Trotzdem danke für Deinen input.

Grüße
Bernd

[Peter Klett]

Vielleicht haben die Items irgendwelche bestimmten Eigenschaften, die beim Kopieren übernommen werden, daher wäre eine allgemeingültige Routine auf jeden Fall einen Versuch wert, die nur die Inhalte kopiert.

Sowas wie

Forall item in konfigdoc.Items
   Call archivedoc.ReplaceItemValue (item.Name, konfigdoc.GetItemValue (item.Name))
End Forall

Falls Du Richtextfelder dabei hast, musst Du die natürlich ausschließen.

[Richard Eder]

Hallo Bernd,

also das "$Name" Feld gehört da mal gar nicht rein... Ich würde nach dem CopyAllItems das Feld/Item "$Name" mit Remove entfernen. Und natürlich das neue Dokument zu keiner Zeit MIT dem Feld speichern (sonst ist es ja wieder ein Profil - und doppelte Profile verträgt die DB nicht wirklich).
Ich denke, das dürfte dann schon reichen.


Richard

[koehlerbv]

Wird das $Name mitgeführt, weiss man danach auch gar nicht mehr, welches Profile man denn nun erwischt hat bzw. man vernichtet das bestehende (siehe die Aussagen über "leere ProfileDocuments").

Bernhard

[pram]

Das mit $name kann ich bestätigen. Kopiert man dieses Item mit, so wird die Kopie zum neuen Profil (meist erst nach dem Clientneustart, da ja Profile sehr stark gecahced werden)

Wie Richard aber schon schrieb, reicht es, das Item vor dem SAVE wieder zu entfernen. Eine "Forall item in doc.items" Schleife würde ich nicht machen, da es wieder Sonderbehandlungen bei Richtexten mit Attachments und MIME-Items erfordert.

Legt man übrigens ein normales Dokument an und schreibt ein $NAME Item nach dem Schema wie es Profile anlegen, so bekommt man dieses Dokument anschließend sogar per db.getProfileDocument. Notes scheint intern eine Art DB-Search  auf $Name zu machen.

Man bekommt scheinbar immer das zuletzt angelegte Dokument. Dies ist m.E. sogar ein Sicherheitsproblem, da ich, sofern ich irgendwie Dokumente anlegen kann (Leser mit Öffentliche Dokumente schreiben reicht schon) jederzeit so ein Dokument anlegen kann, welches das Original-Profil überdeckt. Selbst wenn dieses mit Autorenfeldern für mich nicht bearbeitbar wäre.

Gruß
Roland