Einmalig oder immer wieder ?

Für Einmalig würd ich mir schnell ne Ansicht zusammenbauen, die genauso aufgebaut ist (von den Spalten her), wie die Importdatei.

Die Importdatei dann als *.wk3 speichern und über "Datei"->"Importieren" in der Ansicht importieren, dabei Maske auswählen und evtl. Felder berechnen lassen.

So was hatte ich schon befürchtet  

Wir nutzen für so etwas NOTRIX, darüber lassen sich Pump-Jobs zwischen relationaler DB und Notes-DB erstellen und ausführen.

Ansonsten bleibt vermutlich nur der Weg über einen Script-Agent, der die Importdatei auseinanderpflückt und in die DB importiert.
Wenn dann noch vorhandene Dokumente upgedatet werden sollen, wirds nochmal haariger, evtl. sollte man sich überlegen, vor einem Import die alten Daten aus der Notes-DB zu löschen und einen komplett neuen Import zu starten.

Wie oft kommt denn schätzungsweise so ein Import vor ? D.h. wie oft werden sich die Daten ändern ?

Gibt es denn irgendein eindeutiges Kennzeichen je Dokument, so daß man z.B. Benutzer Paul Meier einwandfrei identifizieren kann, um ihm aus der anderen DB die aktuelle Telefonnummer zuzuweisen ?

Wenn ja, könntest Du einen Agent bauen, der sich alle Dokumente aus der DB mit den aktuellen Daten ausliest, diese dann über eine Schleife durchläuft und sich das jeweils zugehörige Dokument aus der neuen Datenbank holt.
Dann kann man da entweder die Daten noch vergleichen oder direkt überschießen und wenn kein zugehöriges Dokument gefunden wird, wird eben ein neues erstellt.

Aber das ganze ist nicht ohne, wie gut sind denn deine LotusScript-Kenntnisse ?

Dann muß ich dich glaub ich enttäuschen. Ohne Script-Kenntnisse wirst Du das nicht lösen können.

Dann bleibt entweder nur der Weg über einen externen Dienstleister, der das nach deinen Anforderungen umsetzt oder der Weg über den Import per View.

sorry, keine Lösung nur ein Vorschlag/eine Frage.

Du hast Daten, die sich öfter mal ändern. Diese Daten hältst du redundant an mehreren Orten.
Hast du schonmal darüber nachgedacht, diese Situation zu überdenken und ggf. zu verbessern?

das mag jetzt klugscheißerisch klingen, ist aber nicht so gemeint.

das Gift jeder zuverlässigen Information.

sehr schön. Ich sehe schon, ich muss auch etwas mehr in Metaphern schreiben

die Datenhaltung an mehreren Orten möchte ich ja gerade verhindern.....
Ich habe eine Datenbank, wo unter anderem auch die Telefonnummern der Mitarbeiter gepflegt werden. Da das eine DB ist, die nur für administrative Zwecke ist, möchte ich diese Datenbank nicht allen Mitarbeitern zur Verfügung stellen. Deshalb wollte ich  diese Telefonnummern der Mitarbeiter in eine andere Datenbank, die für Mitarbeiter ist (Schriftverkehr, Arbeitsanweisungen etc.) , z.B. mit einer separaten Ansicht "veröffentlichen". Gepflegt sollen diese Telefonnummern jedoch nur in meiner "Admin-DB". Die Ansicht sollte aber in der anderen DB dann aktualisiert werden.
Sorry, wenn ich mich so umständlich ausdrücke. Bin halt noch ein echtes Greenhorn...

aber wenn du rüberschiebst, dann hast du genau das, was du eigentlich vermeiden willst, nämlich die gleiche Daten (hoffentlich) an zwei Stellen.

ok, könnte man sagen, mach ich irgendwas, dass mir die Daten zu bestimmten Gelegenheiten synchronisiert.
Besser würde ich finden, die Daten in der öffentlich zugänglichen DB per DbLookup aus der administrativen DB auszulesen.

Schau mal in der Designer-Hilfe nach DbLookup.
Das kombiniert mit einem (zur Anzeige) berechneten Feld müsste dein Problem lösen, ohne redundante Datenhaltung.

tja, da hast du recht.

ich gebe mich geschlagen, machts mit nem Agent.

Vielen Dank erst mal für eure Beiträge.
Wie mache ich das mit dem Agenten? Wäre schön, wenn ihr mir da noch etwas Hilfe geben könntet.
Danke im voraus