Pfad einer DB ermitteln

[rar]

Hi Leute,
durch die Hitze ist meine Leistungsfähigkeit etwas eingeschränkt. Häng schon an einfachen Problemen 

Ich habe ein Agent, der auf dem Server läuft und eine DB umbenennen soll. Der Befehl Name eignet sich da recht gut. Es reicht aber nicht mit db.Filepath den Pfad auszulesen, da ja das z.B. "E:\Notes\Daten\" vor dem Pfad fehlt. Es kommt daher die Fehlermeldung File not found.
Ich wollte dann so den kompletten Pfad ermitteln:
strFile = session.GetEnvironmentString( "Directory",True ) + "\" + db.FilePath
Das geht aber auch nicht, denn da kommt dann "E:\Notes\Data\..." statt "E:\Notes\Daten\..."  zurück 
Der richtige Pfad wäre "E:\Notes\Daten\Datenbanken\MeineDatenbank.nsf"

Hat jemand eine Idee wie ich an den richtigen Pfad komm?

-daniel

[eknori]

Bist du sicher, daß du den Code nicht lokal auf deinem rechner ausführst ??

Möchtest du die Datenbank über das Filesystem umbenennen ??

[eknori]

du kannst den Pfad auf der Platte ja über die Registry abfragen

@Prompt([Ok];"Titel";@RegQueryValue("HKEY_LOCAL_MACHINE"; "Software\\Lotus\\Notes\\5.0"; "DataPath"))

Dann pappst du nur noch den db.filepath hinten dran. Der ist ja relativ zum DataPath.

@RegQueryValue funktioniert auch mit evaluate

[rar]

Sooo. einiges Probiert, aber nix herausgefunden.

Danke erst einmal für die Tipps, Eknori.

Der code läuft in einem getriggerten Agenten. Also auf dem Server. Und die DB möchte ich über das Filesystem umbenennen.

@RegQueryValue liefert wie GetEnvironmentString den falschen Pfad zurück.

Ich glaube das Problem hängt mit irgendwelchen .dir Files zusammen.
In dem Screenshot sieht man, dass der Pfad am Server (der von RegQueryValue und GetEnvironmentString zurückgegeben wird) nicht dem Physischem Pfad (den ich fürs Umbenennen brauch) entspricht.

[m3]

Der code läuft in einem getriggerten Agenten. Also auf dem Server. Und die DB möchte ich über das Filesystem umbenennen.

Das ist KEINE gute Idee (tm). 

[rar]

Warum ist das keine gute Idee?

Die Datenbank wächst relativ schnell und ist zur Zeit über 12gb groß. Das Ziel ist jährlich eine die neue DB zu erstellen und die alte soll auf z.B. DBName2005.nsf umbenannt werden.
Die alte DB zu kopieren und die Dokumente dann zu löschen dauert ewig. Das sollte mit
Name strFileAlt As strFileNeu
viel besser gehen.

[Thomas Schulte]

Der code läuft in einem getriggerten Agenten. Also auf dem Server. Und die DB möchte ich über das Filesystem umbenennen.

Das ist KEINE gute Idee (tm). 

Weil du unter anderem darauf stoßen wirst, das dein Code die Datenbank gar nicht umbenennen kann, weil der Domino Server das Teil am Wickel hat.

Besser ist da so was wie die Archivierung der Mail DB aufzubauen. Das bedeutet, erstelle eine Archiv Db aus folgendem Template mit folgendem Namen. Wenn du diese DB erstellt hast, dann verschiebe alle zu archivierenden Dokumente von DB Aktiv nach DB Archiv.
Wenn deine DB so was wie ein logische Struktur hat. Haupt/Antwortdokumente dann muss du die natürlich nachbilden. Noch besser wird das Ganze wenn du UNIDS oder REF Felder zum Verbinden von dokumenten miteinander benutzt. Diese Strukturen musst du dann nachbilden. Solltest du Dokument wegziehen die du aus der Live Datenbank noch erreichen willst ,dann musst du ein Linkdokument mit in die aktive DB einbauen und das ist dann richtig lustig. Alles in allem ist Archivierung ein komplexes bis hochkomplexes Gebilde.

[Thomas Schulte]

Ach ja noch was. Wenn du die Datenbank von vorne herein so benennst das sie DBNameJJJJ heist, kannst du ganz einfach eine neue leere Datenbank erzeugen und nur die Konfigurationsdokumente kopieren.

[m3]

rar, was glaubst Du passiert, wenn der Domino-Server die Datenbank öffnet, den Agent liest und der Agent die Datenbank "unterm Hintern wegzieht" (auf OS-Ebene umbenennt), während sie öffen ist?
Das ist kein schöner Anblick, glaub es mir. Sowas macht man nur offline.

[rar]

Das mit meinem Datenbanken schaut so aus:

In der ersten DB werden die Dokumente erstellt und bearbeitet. Es liegt ein kleiner Workflow dahinter. In der Nacht läuft dann ein Agent in der DB, der alle erledigten Dokumente in ein eine 2te DB verschiebt. Diese 2te DB ist aber nicht nur ein Archiv. In dieser DB hat der User die Möglichkeit verschiedenste Auswertungen zu machen.
Und diese 2te DB wird zu groß.
Mein Ziel ist es jetzt in dem Agent, der in der ersten DB läuft, einmal jährlich die 2te DB umbenennen und dann eine neue 2te DB anzulegen.
Natürlich läuft der Code zum umbenennen bevor die 2te DB angegriffen wird.

-daniel

[m3]

Und Du kannst natürlich garantieren, dass kein anderer Agent, Indexer, Notes Client, ... zu der Zeit die DB offen hat, oder? 

[rar]

Naja.... der Agent läuft eh täglich. Wenn die DB neu angelegt wurde, schreib ich das Jahr in ein Profildokument. Wenn da ein falsches Jahr drin steht, probiert es der Agent am nächsten Tag nochmal.
Das ist meine Idee gewesen. Andere Agenten und Clients greifen nicht auf die Db zu. Die Clients werden in der Nacht herunter gefahren und der Agent läuft um 03:00.

Ich wollte einfach nicht die fast 400.000 Dokumente einzeln in einer DB kopieren, wenn es mit "Name AlterName as NeuerName" und "db.CreateCopy()" auch geht. Wenn ich die Wahl habe ob ein Agent 4 Sekunden läuft oder 4 Stunden, ist doch der kürzere besser. Oder?
Wenn es aber nicht so geht, wie ich es mir vorgestellt hab, muss ich es eh anders machen. Ich dachte nur nicht, dass ich schon am Pfad der DB scheiter 

Thomas, dein Tipp mit dem im vorhinein schon DBNameJJJJ zu nennen, gefällt mir ganz gut. Wenn das mit dem umbenennen nicht klappt, werd ich das wahrscheinlich so machen 

Danke euch
-daniel

[LN4ever]

Wenn es darum geht, eine einmal jährlich stattfindende Aktion nachzubilden, deren manuelle Ausführung weniger als 5% der Zeit kostet, die du investieren mußt, um ein Programm zu schreiben, würde ich es weiterhin manuell machen, denn glaub mir: du sitzst hinterher jedes zweite Jahr wieder da und schaust auf die Fehlermeldungen und programmierst dann die in der Zwischenzeit abgelaufenen Änderungen an der Umgebung nach. Und im schlimmsten Fall zerhaut dir dein Programm dabei das, was es eigentlich aufbewahren sollte.

Wo liegt der Spareffekt ? Wenn du einfach am zweiten Januar die Sicherung der DB vom 1. Januar unter dem Archivnamen zurückspielst und anschließend in der aktuellen Datenbank alle abgeschlossenen Datensätze des vergangenen Jahres löschst, bist du doch genau da, wo du hin willst. In der umbenannten Rücksicherung werden dann alle ACL-Einträge (außer den Servern - oder mindestens dem Admin-Server und dessen Clusterpartner ?) auf Leser gestellt.

[Driri]

Wo liegt der Spareffekt ? Wenn du einfach am zweiten Januar die Sicherung der DB vom 1. Januar unter dem Archivnamen zurückspielst und anschließend in der aktuellen Datenbank alle abgeschlossenen Datensätze des vergangenen Jahres löschst, bist du doch genau da, wo du hin willst. In der umbenannten Rücksicherung werden dann alle ACL-Einträge (außer den Servern - oder mindestens dem Admin-Server und dessen Clusterpartner ?) auf Leser gestellt.

Allerdings sollte dann eine Notes-Kopie erzeugt werden, andernfalls gibt es dank Replikation ggf. eine böse Überraschung.

[rar]

So,
obwohl ich den Pfad noch immer nicht richtig ermitteln konnte, habe ich mein Problem gelöst 
Nämlich so:

Ach ja noch was. Wenn du die Datenbank von vorne herein so benennst das sie DBNameJJJJ heist, kannst du ganz einfach eine neue leere Datenbank erzeugen und nur die Konfigurationsdokumente kopieren.

Danke Thomas bzw. danke euch allen fürs Kopfzerbrechen...

Die Lösung war zwar nicht so schnell gefunden, aber in 20 Minuten ausprogrammiert und getestet. So ist die DB jetzt abgeschlossen und ich muss keine jähliche manuelle Nachbearbeitung durchführen. Bin zufrieden so. 

lG
-daniel