Kacheln benutzerdefiniert splitten

[Skalden]

Hallo Notes-Gemeinde,

Wir haben in unserer Entwicklungs-Abteilung ein neues, gekapseltes Testsystem erhalten. Nun habe ich leider das Problem, das wenn ich in einer Replik einer Live-Datenbank auf dem Test-System arbeite, ich diese beiden nur schlecht auf meinem Workspace auseinander halten kann. Die Datenbank aus der Liveumgebung ist auf der gleichen Kachel wie jene aus der Testumgebung, obwohl sie vielleicht ganz andere Funktionen umfassen. Gibt es eine Möglichkeit diese Beiden/mehreren (bei mehr als einer Replik der Datenbank im Livesystem) auseinander zu halten? Ich verliere langsam den Überblick auf meinem Workspace, denn ich habe nun Datenbanken die noch in der Entwicklung sind in den Reitern die eigentlich für die Liveumgebung sind und umgekehrt.

Danke für eure Hilfe
Skalden

[umi]

Hallo

Eine möglichkeit wäre, in der Testumgebung mit Kopien anstatt repliken zu arbeiten.
Oder aber einen eigenen Testclient als VM zu verwenden.

[Klafu]

Du kannst die Repliksymbole ungestabelt anzeigen lassen, wenn dir das hilft. Das gilt dann aber für alle Datenbanken.
Rechtsklick auf den Arbeitsbereichtab > Repliksymbole stabeln - abhaken.

Chris

[Glombi]

Gleiche Repliken mit unterschiedlichen Funktionen halte ich für äußerst gefährlich, auch wenn sie sich in verschiedenen Umgebungen befinden. Daher würde ich auch dazu raten, Kopien anzulegen.

Es gibt auch Tools, mit denen man die Replik-IDs umbiegen kann.

Andreas

[Peter Klett]

Wie verhindert Ihr, dass versehentlich ein Mitarbeiter, der Zugriff auf beide Systeme hat (Testsystem und Produktivsystem), die Datenbanken miteinander repliziert? Wenn Ihr mit dem gleichen Client auf beide Systeme zugreifen könnt, seid Ihr weit entfernt von einem "gekapselten Testsystem".

Die Lösung kann nur lauten, keine Repliken auf Test- und Produktivsystem, sondern Kopien.

[Skalden]

Wie verhindert Ihr, dass versehentlich ein Mitarbeiter, der Zugriff auf beide Systeme hat (Testsystem und Produktivsystem), die Datenbanken miteinander repliziert? Wenn Ihr mit dem gleichen Client auf beide Systeme zugreifen könnt, seid Ihr weit entfernt von einem "gekapselten Testsystem".

Die Lösung kann nur lauten, keine Repliken auf Test- und Produktivsystem, sondern Kopien.

Auf die erste Aussage: Durch verschiedene IDs und verschiedene Locations. Sowie Angaben in den Server-Dokumenten welche Locations auf welche Server zugreifen dürfen. Die ACLs der replizierten Datenbanken werden natürlich entsprechend angepasst udn die Testumgebung ist auch entsprechend eingerichet, das sie nicht mit der Liveumgebung kommunizieren kann. Eine kleine Erläuterung, auch wenn das hier garnicht Thema seien sollte. der Fokus liegt auf der Frage: Kann ich die Kacheln benutzerdefiniert splitten?

Die Idee und der Beitrag von Klafu war schon in Wink in die richtige Richtung, aber wenn ich bedenke, das ich 13 mal das gleiche  Symbol auf dem Workspace habe, hilft mir das auch nicht viel weiter.

Mit einer Kopie kann ich nicht arbeiten, da ich dadurch die Verknüpfungen zwischen einzelnen Dokumenten zerstören würde, welche über die Unids verknüpft sind.

Zu Glombis Beitrag: Wie heißt denn das Tool womit man die Replika IDs umbiegen kann? Bleiben die Document-UNIDs dabei bestehen?

Nocheinmal: Hier soll nicht Thema werden wie sicher unsere Umgebung ist oder wie sicher nicht und was besser wäre und was nicht, sonder: Ob es eine Lösung für mein Problem gibt.

Danke an Glombi und Klafu für die sinnvollen Beiträge!

[Glombi]

Ich hätte ehrlich gesagt bedenken so zu arbeiten und würde mir 2 verschiedene desktop8.ndk.online und desktop8.ndk.develop zulegen und dann vor dem Notes Start jeweils die gewünschte in desktop8.ndk umbenennen und nach dem Beenden von Notes wieder umbenennen.

Auf dem jeweiligen Desktop dann nur die Kacheln vom "richtigen" Server anzeigen.

Besser wäre natürlich mit einer zweiten oder virtuellen Maschine zu arbeiten, das macht weniger Aufwand.

Andreas

[Wolfgang]

Zu Glombis Beitrag: Wie heißt denn das Tool womit man die Replika IDs umbiegen kann?

... Antrid - dazu findest Du bei Google und Co. etliche Infos.

Bleiben die Document-UNIDs dabei bestehen?

... ich vermute schon, aber das musst Du ausprobieren.

Gruß
Wolfgang

[it898ur]

Um hier zur Sicherheit gleich mal noch einen Denkfehler auszuräumen - durch das Kopieren einer ganzen Datenbank werden keine Dokument-UniqueIDs geändert.
D. h. wenn die Verknüpfung der Dokumente über Antworthierarchien oder Codeseitig über die reine UNID gelöst ist, kann man getrost eine Kopie machen.
Wenn die Verknüpfung aber über Dokumentenlinks erfolgt, sind in den Links auch die Replica-ID der Quell-Db enthalten - dann gehen die Verknüpfungen verloren (und nur dann).

Gruß

André

[Skalden]

Um hier zur Sicherheit gleich mal noch einen Denkfehler auszuräumen - durch das Kopieren einer ganzen Datenbank werden keine Dokument-UniqueIDs geändert.

Moin!

Das gilt doch aber nur, wenn ich die .nsf vom Dateisystem des einen in das Dateisystem eines anderen kopiere, oder? Sobald ich die Copytodatabase Funktion nutze, wird eine neue UNID angelegt.
Aber wenn ich den kompletten Datenbankcontainer von A nach B verschiebe, dann ändert sich auch nicht die Replika-ID der Datenbank, oder?

[Peter Klett]

Warum probierst Du das nicht einfach aus?

Kopiere eine Datenbank (Datei - Anwendung - Neue Kopie) und schau Dir danach die Dokumente an. Ist das Erstelldatum der Dokumente das gleiche, wie in der Quelldatenbank? Falls ja, bei mir ist das so und ein Test dauerte keine Minute, dann sind auch die UniversalIDs gleich, denn das Erstelldatum ist darin gespeichert (kannst natürlich auch die IDs direkt miteinander vergleichen und wirst zum gleichen Ergebnis kommen).

Eine Kopie auf Dateiebene hat natürlich die gleiche ReplikID, denn Windows, Linux & Co. verändern beim Kopieren nicht die Dateien (wär ja noch schöner).

Aber das ist ja eigentlich keine konkrete Antwort auf Deine Frage, Verzeihung daher für diesen weiteren sinnlosen Beitrag von mir ...

Konkret fragtest Du nach NotesDocument.CopyToDatabase. Auch das kann man ganz schnell mal ausprobieren. Denn was nützen Dir Antworten hier im Forum - die natürlich generell ein hohes Niveau haben, ich würde immer nur eigenen Tests trauen und Antworten - egal von wem - immer nur als Anregung nehmen, die auf jeden Fall zu prüfen wären. Du hältst schließlich den Kopf dafür hin, wenn es nicht stimmt. Meines Wissens (und auch hier im Forum schon öfter gelesen) bleibt bei NotesDocument.CopyToDatabase die UniversalID erhalten, wenn es die nicht schon in der Zieldatenbank gibt. D.h. wenn Du die Dokumente einmal kopiert hast, dann in der Zieldatenbank wieder löschst, und die Prozedur noch einmal ausführst, sind die UniversalIDs noch in den Deletion-Stubs enthalten und dann bekommen die Dokumente eine neue ID. Um mehrfach das Testumfeld mit den produktiven Daten zu bestücken, brauchst Du schon einen etwas intelligenteren Agenten, der nicht nur stumpf kopiert, sondern die bereits vorhandenen Dokumente aktualisiert. Löschen und neu Kopieren ist in Notes noch nie eine gute Idee gewesen.

[DerAndre]

Hi,

habe gerade Zufällig ein Beispiel zur Hand.

Original
C1256628002A23A8/85255E01001356A8852554C200753106/254743F088CD3E58C1256628002FB446

Kopie
C1257997003016B2/85255E01001356A8852554C200753106/254743F088CD3E58C1256628002FB446