Archive for: ‘Dezember 2010’

Wie bewältigen wir "Information overload"

28. Dezember 2010 Posted by Herbert Wagger

Ein interessanter Artikel von Thomas Pelkman (CIO.de) - siehe weiter unten. Dieser Zunahme der Datenflut (Verdoppelung innherhalb 18 Monaten) vor allem durch die neuen sozialen Netzwerke und andere W ...

dojo und Notes: Artikel 10 – dojo.dnd.Source – Drag\’n\’Drop mit drei Zeilen JavaScript

27. Dezember 2010 Posted by Bernd Hort

\"dojo-Logo\"/
Während der letzte Artikel in der dojo-Serie sich mit den dijit.Dialog beschäftigte, komme wir nun zu einem meiner Lieblingsthemen bei dojo: Drag & Drop. Es ist deswegen mein Lieblingsthema, weil es so unglaublich einfach zu benutzen ist. Wie wir gleich sehen werden, benötigen wir nur drei Zeilen JavaScript-Code, um unsere Session-Beschreibungen per Drag & Drop umsortieren zu können.
Für Drag & Drop gibt es bei dojo zwei Konzepte. Das eine Konzept bezieht sich auf das Verschieben von Elementen an eine beliebige Position auf der Webseite. Das andere Konzept ist für das Umsortieren von Elementen innerhalb eines Containers gedacht.

Für das Verschieben von Elementen wird lediglich das zugehörige Package benötigt und die Kennzeichnung des zu verschiebenden Elementes durch Angabe des dojo-Types.
//Package for moving elements
dojo.require("dojo.dnd.movable");

1. <div dojoType="dojo.dnd.Moveable"> Some Content</div>

Es kann ein Kindelement als "Handle" definiert werden, so dass dieses Element zum "Anfassen" benutzt werden kann. Das ist dann besonders wichtig, wenn der Inhalt selber editierbar ist. Ohne "Handle" könnte der Text nicht selektiert werden.
1. <div dojoType="dojo.dnd.Moveable" handle="dragHandle">
2. <div id="dragHandle"></div> <textarea>Dieser Text kann editiert werden
3. </textarea> </div>


Das Umsortieren von Elementen innerhalb eines Containers ist ebenfalls sehr praktisch und kann vielfältig eingesetzt werden. Als Container kann jedes HTML-Element dienen, das Kindelemente beinhaltet. Es ist also nicht nur auf ordered / unorderer lists beschränkt.

Neben dem obligatorischen Nachladen des Packages muss nun lediglich das Eltern-HTML-Element als Container und die Kindelemente als Drag&Drop Item gekennzeichnet werden. Es gibt die abstrakte Klasse dojo.dnd.Container und die zwei Implementierungen dojo.dnd.Source und dojo.dnd.Target. Wie die Namen vermuten lassen, dient die Source als Quelle und Target als Ziel.
//Package for sorting elements via Drag & Dropt
dojo.require("dojo.dnd.Source");

1. <div dojoType="dojo.dnd.Source">
2.  <div class="dojoDndItem">Item X</div>
3.  <div class="dojoDndItem">Item Y</div>
4.  <div class="dojoDndItem">Item Z</div>
5. </div>
Neben der Angabe des dojoType dojo.dnd.Source ist die Angabe der CSS Klasse "dojoDNDItem" der Schlüssel zum Erfolg. Der Name der CSS Klasse ist entscheidend.
\"A

In unserer Beispiel-Anwendung werden wir nun die Session-Beschreibungen als Drag & Drop Items kennzeichnen und das umschließende DIV mit der ID "Sessions" als Source definieren.
//Preparing Drag & Drop
dojo.require("dojo.dnd.Source");

dojo.query(".session").addClass("dojoDndItem");
var dndSource = new dojo.dnd.Source("sessions");
Wie versprochen nur drei Zeilen JavaScript-Code.

Es lohnt sich, das Beispiel selber ausprobieren. Halten Sie beim Verschieben auch einmal die <STRG>-Taste gedrückt.

In der zu dieser Artikelserien gehörenden Beispieldatenbank finden sie den Inhalt dieses Artikels in der Maske "webSpeedAgendaing-Step 8|SpeedAgendaing-8" und der JavaScript Bibliothek "SpeedAgendaing-Step8.js".

Im nächsten Artikel definieren wir ein passendes Ziel für unsere Sessions.

Wie funktioniert die "Client Aufrumfunktion" von Lotus Notes?

23. Dezember 2010 Posted by Manfred Meise

Vermeiden Sie den Verlust lokaler Daten (die nur hier existieren), indem Sie diese Konfiguration vollstndig verstehen, bevor Sie diese einsetzen.

Seit Einfhrung von Multi-User Installationen und Roaming Funktion in Release 6 knnen Administratoren die \”Client Aufrumfunktion\” nutzen, um die Flut lokaler Dateien verschiedener Benutzer einzudmmen, Hierzu ist bei z.B. der nachtrglichen Einrichtung der Roaming Funktion fr einen Benutzer diese Option auszuwhlen:

\"Image:Wie
Im Rahmen eines Kundenprojektes, wo man auf diese Option gesteigerten Wert legte, frage ich mich nun, wie diese Funktion genau arbeitet und wie sie gesteuert wird.

Rahmenbedingungen:

Damit die Aufrumfunktion lokal zur Verfgung steht, ist eine MultiUser Installation des Clients durchzufhren, um das notwendige Programm \”NtMulti.exe\” in das Programmverzeichnis installiert und als Windows Dienst eingerichtet zu bekommen.

Mit Einrichtung von Domino Roaming (bei der Registrierung oder nachtrglich) wird der Administrationsproze beauftragt, die Funktion zu parametrisieren (im obigen Beispiel mit 10 Tagen). Diese Daten werden im Personendokument des Benutzers hinterlegt.

Verhalten im Alltag:

Wenn ein Benutzer an einem PC Lotus Notes eingerichtet hat, werden seine lokalen Daten nach 10 Tagen gelscht. Diese Lschung umfasst sein gesamtes lokales Notes Datenverzeichnis (somit z.B. auch lokale Mail-Archive, wenn Benutzer lokal archivieren !!!! (ACHTUNG: Gefahr des Verlustes von Unternehmensdaten!)

Nach Ablauf von 10 Tagen durchluft der Lotus Notes Client eine Konfiguration und repliziert seine Roaming Dateien von Roaming Server.

Offene Fragen und meine Erkenntnisse:

Um die Arbeitsweise der Aufrumfunktion nher zu ermitteln half nach einer ergebnislosen Recherche in den einschlgigen Quellen nur noch \”ausprobieren\” und \”selbst ermitteln\”. Hier der aktuelle Stand meiner Erkenntnisse (die ich erweitern werde, sofern neue Erkenntnisse hinzukommen):

Frage
Meine Erkenntnisse
Ab wann zhlen die 10 Tage? Ab Einrichtung von Lotus Notes fr den betroffenen Benutzer oder ab dem Zeitpunkt der letzten Nutzung?

Anders als viele Administratoren erwarten aktualisiert der Lotus Notes Client die Konfigurationsdaten fr die Aufrumdienst nicht. Somit zhlt das konfigurierte Aufrumintervall seit dem Zeitpunkt der ersten Konfiguration des Benutzers als Roaming User auf dem betroffenen Rechner. Anders als erwartet, oder? Htten Sie das vorab ohne Tests gewusst?
Hinweis: Durch den zustzlichen Notes.ini Eintrag \”Cleanup_Move=1\”, den man z.B. ber eine Desktop Richtlinie setzen kann, wird dieses Intervall nicht vom Zeitpunkt der Erstkonfiguration, sondern der letzten Verwendung (herunterfahren/replizieren) eines Roaming Clients gezhlt.

Wo sind die Konfigurationsdaten fr den Aufrumdienst \”NTMulti.exe\” gespeichert?

Mit Installation des MultiUser Clients wird das entsprechende Programm als Windows Dienst eingerichtet:

Mit Abschluss der ersten Replikation (z.B. beim Beenden von Lotus Notes) mit Roaming Konfiguration schreibt der Lotus Notes Client eine lokale Datei \”.cln\” in \”C:\\Dokumente und Einstellungen\\All Users\\Dokumente\” an dem sich der Aufrumdienst orientiert.
Diese Datei enthlt den Verzeichnisnamen des zu lschenden Benutzerprofiles sowie die Zeitangabe, wann dieses zu lschen ist. Ist der Client so konfiguriert, dass das Aufrumzeitintervall ab der letzten Verwendung zhlt, so wird dieses Datei beim Herunterfahren von Lotus Notes erneut geschrieben.

Kann die Aufrumperiode nachtrglich gendert werden?

Nein und ja. Eine nderung des Aufrumzyklus im Personendokument wirkt sich NICHT auf bereits konfigurierte Clients aus. Jedoch werden die Daten aus dem Personendokument interpretiert, wenn der betroffene Benutzer an einen anderen Rechner roamt (und dort die Erstkonfiguration durchluft).

Wie funktioniert die “Client Aufräumfunktion” von Lotus Notes?

23. Dezember 2010 Posted by Manfred Meise

Vermeiden Sie den Verlust lokaler Daten (die nur hier existieren), indem Sie diese Konfiguration vollständig verstehen, bevor Sie diese einsetzen.

Seit Einführung von Multi-User Installationen und Roaming Funktion in Release 6 können Administratoren die "Client Aufräumfunktion" nutzen, um die Flut lokaler Dateien verschiedener Benutzer einzudämmen, Hierzu ist bei z.B. der nachträglichen Einrichtung der Roaming Funktion für einen Benutzer diese Option auszuwählen:

Image:Wie funktioniert die "Client Aufräumfunktion" von Lotus Notes?
Im Rahmen eines Kundenprojektes, wo man auf diese Option gesteigerten Wert legte, frage ich mich nun, wie diese Funktion genau arbeitet und wie sie gesteuert wird.

Rahmenbedingungen:


Damit die Aufräumfunktion lokal zur Verfügung steht, ist eine MultiUser Installation des Clients durchzuführen, um das notwendige Programm "NtMulti.exe" in das Programmverzeichnis installiert und als Windows Dienst eingerichtet zu bekommen.

Mit Einrichtung von Domino Roaming (bei der Registrierung oder nachträglich) wird der Administrationsprozeß beauftragt, die Funktion zu parametrisieren (im obigen Beispiel mit 10 Tagen). Diese Daten werden im Personendokument des Benutzers hinterlegt.

Verhalten im Alltag:


Wenn ein Benutzer an einem PC Lotus Notes eingerichtet hat, werden seine lokalen Daten nach 10 Tagen gelöscht. Diese Löschung umfasst sein gesamtes lokales Notes Datenverzeichnis (somit z.B. auch lokale Mail-Archive, wenn Benutzer lokal archivieren !!!! (ACHTUNG: Gefahr des Verlustes von Unternehmensdaten!)

Nach Ablauf von 10 Tagen durchläuft der Lotus Notes Client eine Konfiguration und repliziert seine Roaming Dateien von Roaming Server.

Offene Fragen und meine Erkenntnisse:


Um die Arbeitsweise der Aufräumfunktion näher zu ermitteln half nach einer ergebnislosen Recherche in den einschlägigen Quellen nur noch "ausprobieren" und "selbst ermitteln". Hier der aktuelle Stand meiner Erkenntnisse (die ich erweitern werde, sofern neue Erkenntnisse hinzukommen):
Frage
Meine Erkenntnisse
Ab wann zählen die 10 Tage? Ab Einrichtung von Lotus Notes für den betroffenen Benutzer oder ab dem Zeitpunkt der letzten Nutzung? Anders als viele Administratoren erwarten aktualisiert der Lotus Notes Client die Konfigurationsdaten für die Aufräumdienst nicht. Somit zählt das konfigurierte Aufräumintervall seit dem Zeitpunkt der ersten Konfiguration des Benutzers als Roaming User auf dem betroffenen Rechner. Anders als erwartet, oder? Hätten Sie das vorab ohne Tests gewusst?
Hinweis: Durch den zusätzlichen Notes.ini Eintrag "Cleanup_Move=1", den man z.B. über eine Desktop Richtlinie setzen kann, wird dieses Intervall nicht vom Zeitpunkt der Erstkonfiguration, sondern der letzten Verwendung (herunterfahren/replizieren) eines Roaming Clients gezählt.
Wo sind die Konfigurationsdaten für den Aufräumdienst "NTMulti.exe" gespeichert? Mit Installation des MultiUser Clients wird das entsprechende Programm als Windows Dienst eingerichtet:

Mit Abschluss der ersten Replikation (z.B. beim Beenden von Lotus Notes) mit Roaming Konfiguration schreibt der Lotus Notes Client eine lokale Datei ".cln" in "C:\Dokumente und Einstellungen\All Users\Dokumente" an dem sich der Aufräumdienst orientiert.
Diese Datei enthält den Verzeichnisnamen des zu löschenden Benutzerprofiles sowie die Zeitangabe, wann dieses zu löschen ist. Ist der Client so konfiguriert, dass das Aufräumzeitintervall ab der letzten Verwendung zählt, so wird dieses Datei beim Herunterfahren von Lotus Notes erneut geschrieben.
Kann die Aufräumperiode nachträglich geändert werden? Nein und ja. Eine Änderung des Aufräumzyklus im Personendokument wirkt sich NICHT auf bereits konfigurierte Clients aus. Jedoch werden die Daten aus dem Personendokument interpretiert, wenn der betroffene Benutzer an einen anderen Rechner roamt (und dort die Erstkonfiguration durchläuft).


Wie funktioniert die “Client Aufräumfunktion” von Lotus Notes?

23. Dezember 2010 Posted by Manfred Meise

Vermeiden Sie den Verlust lokaler Daten (die nur hier existieren), indem Sie diese Konfiguration vollständig verstehen, bevor Sie diese einsetzen.

Seit Einführung von Multi-User Installationen und Roaming Funktion in Release 6 können Administratoren die "Client Aufräumfunktion" nutzen, um die Flut lokaler Dateien verschiedener Benutzer einzudämmen, Hierzu ist bei z.B. der nachträglichen Einrichtung der Roaming Funktion für einen Benutzer diese Option auszuwählen:

Image:Wie funktioniert die "Client Aufräumfunktion" von Lotus Notes?
Im Rahmen eines Kundenprojektes, wo man auf diese Option gesteigerten Wert legte, frage ich mich nun, wie diese Funktion genau arbeitet und wie sie gesteuert wird.

Rahmenbedingungen:


Damit die Aufräumfunktion lokal zur Verfügung steht, ist eine MultiUser Installation des Clients durchzuführen, um das notwendige Programm "NtMulti.exe" in das Programmverzeichnis installiert und als Windows Dienst eingerichtet zu bekommen.

Mit Einrichtung von Domino Roaming (bei der Registrierung oder nachträglich) wird der Administrationsprozeß beauftragt, die Funktion zu parametrisieren (im obigen Beispiel mit 10 Tagen). Diese Daten werden im Personendokument des Benutzers hinterlegt.

Verhalten im Alltag:


Wenn ein Benutzer an einem PC Lotus Notes eingerichtet hat, werden seine lokalen Daten nach 10 Tagen gelöscht. Diese Löschung umfasst sein gesamtes lokales Notes Datenverzeichnis (somit z.B. auch lokale Mail-Archive, wenn Benutzer lokal archivieren !!!! (ACHTUNG: Gefahr des Verlustes von Unternehmensdaten!)

Nach Ablauf von 10 Tagen durchläuft der Lotus Notes Client eine Konfiguration und repliziert seine Roaming Dateien von Roaming Server.

Offene Fragen und meine Erkenntnisse:


Um die Arbeitsweise der Aufräumfunktion näher zu ermitteln half nach einer ergebnislosen Recherche in den einschlägigen Quellen nur noch "ausprobieren" und "selbst ermitteln". Hier der aktuelle Stand meiner Erkenntnisse (die ich erweitern werde, sofern neue Erkenntnisse hinzukommen):
Frage
Meine Erkenntnisse
Ab wann zählen die 10 Tage? Ab Einrichtung von Lotus Notes für den betroffenen Benutzer oder ab dem Zeitpunkt der letzten Nutzung? Anders als viele Administratoren erwarten aktualisiert der Lotus Notes Client die Konfigurationsdaten für die Aufräumdienst nicht. Somit zählt das konfigurierte Aufräumintervall seit dem Zeitpunkt der ersten Konfiguration des Benutzers als Roaming User auf dem betroffenen Rechner. Anders als erwartet, oder? Hätten Sie das vorab ohne Tests gewusst?
Hinweis: Durch den zusätzlichen Notes.ini Eintrag "Cleanup_Move=1", den man z.B. über eine Desktop Richtlinie setzen kann, wird dieses Intervall nicht vom Zeitpunkt der Erstkonfiguration, sondern der letzten Verwendung (herunterfahren/replizieren) eines Roaming Clients gezählt.
Wo sind die Konfigurationsdaten für den Aufräumdienst "NTMulti.exe" gespeichert? Mit Installation des MultiUser Clients wird das entsprechende Programm als Windows Dienst eingerichtet:

Mit Abschluss der ersten Replikation (z.B. beim Beenden von Lotus Notes) mit Roaming Konfiguration schreibt der Lotus Notes Client eine lokale Datei ".cln" in "C:\Dokumente und Einstellungen\All Users\Dokumente" an dem sich der Aufräumdienst orientiert.
Diese Datei enthält den Verzeichnisnamen des zu löschenden Benutzerprofiles sowie die Zeitangabe, wann dieses zu löschen ist. Ist der Client so konfiguriert, dass das Aufräumzeitintervall ab der letzten Verwendung zählt, so wird dieses Datei beim Herunterfahren von Lotus Notes erneut geschrieben.
Kann die Aufräumperiode nachträglich geändert werden? Nein und ja. Eine Änderung des Aufräumzyklus im Personendokument wirkt sich NICHT auf bereits konfigurierte Clients aus. Jedoch werden die Daten aus dem Personendokument interpretiert, wenn der betroffene Benutzer an einen anderen Rechner roamt (und dort die Erstkonfiguration durchläuft).


Wie funktioniert die “Client Aufräumfunktion” von Lotus Notes?

23. Dezember 2010 Posted by Manfred Meise

Vermeiden Sie den Verlust lokaler Daten (die nur hier existieren), indem Sie diese Konfiguration vollständig verstehen, bevor Sie diese einsetzen.

Seit Einführung von Multi-User Installationen und Roaming Funktion in Release 6 können Administratoren die "Client Aufräumfunktion" nutzen, um die Flut lokaler Dateien verschiedener Benutzer einzudämmen, Hierzu ist bei z.B. der nachträglichen Einrichtung der Roaming Funktion für einen Benutzer diese Option auszuwählen:

Image:Wie funktioniert die "Client Aufräumfunktion" von Lotus Notes?
Im Rahmen eines Kundenprojektes, wo man auf diese Option gesteigerten Wert legte, frage ich mich nun, wie diese Funktion genau arbeitet und wie sie gesteuert wird.

Rahmenbedingungen:


Damit die Aufräumfunktion lokal zur Verfügung steht, ist eine MultiUser Installation des Clients durchzuführen, um das notwendige Programm "NtMulti.exe" in das Programmverzeichnis installiert und als Windows Dienst eingerichtet zu bekommen.

Mit Einrichtung von Domino Roaming (bei der Registrierung oder nachträglich) wird der Administrationsprozeß beauftragt, die Funktion zu parametrisieren (im obigen Beispiel mit 10 Tagen). Diese Daten werden im Personendokument des Benutzers hinterlegt.

Verhalten im Alltag:


Wenn ein Benutzer an einem PC Lotus Notes eingerichtet hat, werden seine lokalen Daten nach 10 Tagen gelöscht. Diese Löschung umfasst sein gesamtes lokales Notes Datenverzeichnis (somit z.B. auch lokale Mail-Archive, wenn Benutzer lokal archivieren !!!! (ACHTUNG: Gefahr des Verlustes von Unternehmensdaten!)

Nach Ablauf von 10 Tagen durchläuft der Lotus Notes Client eine Konfiguration und repliziert seine Roaming Dateien von Roaming Server.

Offene Fragen und meine Erkenntnisse:


Um die Arbeitsweise der Aufräumfunktion näher zu ermitteln half nach einer ergebnislosen Recherche in den einschlägigen Quellen nur noch "ausprobieren" und "selbst ermitteln". Hier der aktuelle Stand meiner Erkenntnisse (die ich erweitern werde, sofern neue Erkenntnisse hinzukommen):
Frage
Meine Erkenntnisse
Ab wann zählen die 10 Tage? Ab Einrichtung von Lotus Notes für den betroffenen Benutzer oder ab dem Zeitpunkt der letzten Nutzung? Anders als viele Administratoren erwarten aktualisiert der Lotus Notes Client die Konfigurationsdaten für die Aufräumdienst nicht. Somit zählt das konfigurierte Aufräumintervall seit dem Zeitpunkt der ersten Konfiguration des Benutzers als Roaming User auf dem betroffenen Rechner. Anders als erwartet, oder? Hätten Sie das vorab ohne Tests gewusst?
Hinweis: Durch den zusätzlichen Notes.ini Eintrag "Cleanup_Move=1", den man z.B. über eine Desktop Richtlinie setzen kann, wird dieses Intervall nicht vom Zeitpunkt der Erstkonfiguration, sondern der letzten Verwendung (herunterfahren/replizieren) eines Roaming Clients gezählt.
Wo sind die Konfigurationsdaten für den Aufräumdienst "NTMulti.exe" gespeichert? Mit Installation des MultiUser Clients wird das entsprechende Programm als Windows Dienst eingerichtet:

Mit Abschluss der ersten Replikation (z.B. beim Beenden von Lotus Notes) mit Roaming Konfiguration schreibt der Lotus Notes Client eine lokale Datei ".cln" in "C:\Dokumente und Einstellungen\All Users\Dokumente" an dem sich der Aufräumdienst orientiert.
Diese Datei enthält den Verzeichnisnamen des zu löschenden Benutzerprofiles sowie die Zeitangabe, wann dieses zu löschen ist. Ist der Client so konfiguriert, dass das Aufräumzeitintervall ab der letzten Verwendung zählt, so wird dieses Datei beim Herunterfahren von Lotus Notes erneut geschrieben.
Kann die Aufräumperiode nachträglich geändert werden? Nein und ja. Eine Änderung des Aufräumzyklus im Personendokument wirkt sich NICHT auf bereits konfigurierte Clients aus. Jedoch werden die Daten aus dem Personendokument interpretiert, wenn der betroffene Benutzer an einen anderen Rechner roamt (und dort die Erstkonfiguration durchläuft).


Enterprise Software more like Facebook (#safebook)

20. Dezember 2010 Posted by Herbert Wagger

Facebook is easy to use, as well as being a robust tool. Grandparents can pick up enough to browse pictures of their grandchildren in a matter of minutes, while teenagers can manage their entire soci ...

Wie kann ich Dialoge und Code in einer anderen Datenbank nutzen?

20. Dezember 2010 Posted by Manfred Meise

Dieses Codebeispiel zeigt die Bearbeitung von Dokumenten einer Datenbank mit bestehendem Code in der anderen Datenbank.

Umfangreichere Anwendungen bestehen oftmals aus mehreren Datenbanken. Wie kann man nun whrend der  Arbeit in einer Datenbank dort Dokumente auswhlen, die durch einen Dialog und damit verbundenen Funktionen einer anderen Datenbank bearbeitet werden?

Hierzu kann z.B. ein Agent eingesetzt werden, der auf selektierte Dokumente arbeitet und nachfolgenden Code ausfhrt:

 
Sub
Initialize
     
      Dim uiws         As New NotesUIWorkspace
      Dim s         As New NotesSession
      Dim col         As NotesDocumentCollection
     
      Dim docThis        As NotesDocument        
      Dim docThat        As NotesDocument
     
      Dim dbThis        As NotesDatabase
      Dim dbThat        As NotesDatabase
     
      Dim vArray() As variant
      Dim i         As integer
     
      Const strDatabaseToCall = \"develop/mm/r82spielwiese\"
     
      Set dbThis = s.Currentdatabase
      Set dbThat = s.Getdatabase(dbThis.Server, strDatabaseToCall)
     
      Set col = dbThis.Unprocesseddocuments
      ReDim vArray(col.Count) As Variant
     
      Set docThis = col.Getfirstdocument()
      i = 0
     
      While Not docThis Is Nothing
              vArray(i) = docThis.Universalid
             
              Set docThis = col.Getnextdocument(docThis)
              i = i + 1
             
      Wend
     
      Set docThat = dbThat.Createdocument()
     
      docThat.OtherDBServer         = dbThis.server        
      docThat.OtherDBPath                = dbThis.Filepath
      docThat.OtherDocs                 = vArray
     
      Call uiws.Dialogbox(\"Dialog\", true, true,,,,, \"Dialogaufruf aus einer fremden DB\", docThat, true)
     
      MessageBox (\"Getroffene Auswahl in Fremddialog: \" & cstr(docThat.Selection(0)))
     
End
Sub

In der anderen Datenbank muss eine Maske \”Dialog\” existieren, die z.B. lokale Scriptbibliotheken rufen kann und (fr die Funktion des obigen Beispieles) auch Rckgabewerte anbieten kann.

Hintergrundinformation:
Diese Beispiel funktioniert deshalb, weil die \”DialogBox\”-Funktion ein vordefiniertes Dokument bentigt und abhngig davon, in welcher Datenbank dieses Dokument besteht, diese Datenbank verwendet, um bentigte Gestaltungselemente zu laden. Da der aufgerufene Dialog modal ist, kann diese Werte setzen, welche vom aufrufenden Code (in der Ursprungsdatenbank) verarbeitet werden kann.

Wie kann ich Dialoge und Code in einer anderen Datenbank nutzen?

20. Dezember 2010 Posted by Manfred Meise

Dieses Codebeispiel zeigt die Bearbeitung von Dokumenten einer Datenbank mit bestehendem Code in der anderen Datenbank.

Umfangreichere Anwendungen bestehen oftmals aus mehreren Datenbanken. Wie kann man nun während der  Arbeit in einer Datenbank dort Dokumente auswählen, die durch einen Dialog und damit verbundenen Funktionen einer anderen Datenbank bearbeitet werden?

Hierzu kann z.B. ein Agent eingesetzt werden, der auf selektierte Dokumente arbeitet und nachfolgenden Code ausführt:

 
Sub
Initialize
     
      Dim uiws         As New NotesUIWorkspace
      Dim s         As New NotesSession
      Dim col         As NotesDocumentCollection
     
      Dim docThis        As NotesDocument        
      Dim docThat        As NotesDocument
     
      Dim dbThis        As NotesDatabase
      Dim dbThat        As NotesDatabase
     
      Dim vArray() As variant
      Dim i         As integer
     
      Const strDatabaseToCall = "develop/mm/r82spielwiese"
     
      Set dbThis = s.Currentdatabase
      Set dbThat = s.Getdatabase(dbThis.Server, strDatabaseToCall)
     
      Set col = dbThis.Unprocesseddocuments
      ReDim vArray(col.Count) As Variant
     
      Set docThis = col.Getfirstdocument()
      i = 0
     
      While Not docThis Is Nothing
              vArray(i) = docThis.Universalid
             
              Set docThis = col.Getnextdocument(docThis)
              i = i + 1
             
      Wend
     
      Set docThat = dbThat.Createdocument()
     
      docThat.OtherDBServer         = dbThis.server        
      docThat.OtherDBPath                = dbThis.Filepath
      docThat.OtherDocs                 = vArray
     
      Call uiws.Dialogbox("Dialog", true, true,,,,, "Dialogaufruf aus einer fremden DB", docThat, true)
     
      MessageBox ("Getroffene Auswahl in Fremddialog: " & cstr(docThat.Selection(0)))
     
End
Sub


In der anderen Datenbank muss eine Maske "Dialog" existieren, die z.B. lokale Scriptbibliotheken rufen kann und (für die Funktion des obigen Beispieles) auch Rückgabewerte anbieten kann.


Hintergrundinformation:

Diese Beispiel funktioniert deshalb, weil die "DialogBox"-Funktion ein vordefiniertes Dokument benötigt und abhängig davon, in welcher Datenbank dieses Dokument besteht, diese Datenbank verwendet, um benötigte Gestaltungselemente zu laden. Da der aufgerufene Dialog modal ist, kann diese Werte setzen, welche vom aufrufenden Code (in der Ursprungsdatenbank) verarbeitet werden kann.

Wie kann ich Dialoge und Code in einer anderen Datenbank nutzen?

20. Dezember 2010 Posted by Manfred Meise

Dieses Codebeispiel zeigt die Bearbeitung von Dokumenten einer Datenbank mit bestehendem Code in der anderen Datenbank.

Umfangreichere Anwendungen bestehen oftmals aus mehreren Datenbanken. Wie kann man nun während der  Arbeit in einer Datenbank dort Dokumente auswählen, die durch einen Dialog und damit verbundenen Funktionen einer anderen Datenbank bearbeitet werden?

Hierzu kann z.B. ein Agent eingesetzt werden, der auf selektierte Dokumente arbeitet und nachfolgenden Code ausführt:

 
Sub
Initialize
     
      Dim uiws         As New NotesUIWorkspace
      Dim s         As New NotesSession
      Dim col         As NotesDocumentCollection
     
      Dim docThis        As NotesDocument        
      Dim docThat        As NotesDocument
     
      Dim dbThis        As NotesDatabase
      Dim dbThat        As NotesDatabase
     
      Dim vArray() As variant
      Dim i         As integer
     
      Const strDatabaseToCall = "develop/mm/r82spielwiese"
     
      Set dbThis = s.Currentdatabase
      Set dbThat = s.Getdatabase(dbThis.Server, strDatabaseToCall)
     
      Set col = dbThis.Unprocesseddocuments
      ReDim vArray(col.Count) As Variant
     
      Set docThis = col.Getfirstdocument()
      i = 0
     
      While Not docThis Is Nothing
              vArray(i) = docThis.Universalid
             
              Set docThis = col.Getnextdocument(docThis)
              i = i + 1
             
      Wend
     
      Set docThat = dbThat.Createdocument()
     
      docThat.OtherDBServer         = dbThis.server        
      docThat.OtherDBPath                = dbThis.Filepath
      docThat.OtherDocs                 = vArray
     
      Call uiws.Dialogbox("Dialog", true, true,,,,, "Dialogaufruf aus einer fremden DB", docThat, true)
     
      MessageBox ("Getroffene Auswahl in Fremddialog: " & cstr(docThat.Selection(0)))
     
End
Sub


In der anderen Datenbank muss eine Maske "Dialog" existieren, die z.B. lokale Scriptbibliotheken rufen kann und (für die Funktion des obigen Beispieles) auch Rückgabewerte anbieten kann.


Hintergrundinformation:

Diese Beispiel funktioniert deshalb, weil die "DialogBox"-Funktion ein vordefiniertes Dokument benötigt und abhängig davon, in welcher Datenbank dieses Dokument besteht, diese Datenbank verwendet, um benötigte Gestaltungselemente zu laden. Da der aufgerufene Dialog modal ist, kann diese Werte setzen, welche vom aufrufenden Code (in der Ursprungsdatenbank) verarbeitet werden kann.

Wie kann ich Dialoge und Code in einer anderen Datenbank nutzen?

20. Dezember 2010 Posted by Manfred Meise

Dieses Codebeispiel zeigt die Bearbeitung von Dokumenten einer Datenbank mit bestehendem Code in der anderen Datenbank.

Umfangreichere Anwendungen bestehen oftmals aus mehreren Datenbanken. Wie kann man nun während der  Arbeit in einer Datenbank dort Dokumente auswählen, die durch einen Dialog und damit verbundenen Funktionen einer anderen Datenbank bearbeitet werden?

Hierzu kann z.B. ein Agent eingesetzt werden, der auf selektierte Dokumente arbeitet und nachfolgenden Code ausfĂĽhrt:

 
Sub
Initialize
     
      Dim uiws         As New NotesUIWorkspace
      Dim s         As New NotesSession
      Dim col         As NotesDocumentCollection
     
      Dim docThis        As NotesDocument        
      Dim docThat        As NotesDocument
     
      Dim dbThis        As NotesDatabase
      Dim dbThat        As NotesDatabase
     
      Dim vArray() As variant
      Dim i         As integer
     
      Const strDatabaseToCall = "develop/mm/r82spielwiese"
     
      Set dbThis = s.Currentdatabase
      Set dbThat = s.Getdatabase(dbThis.Server, strDatabaseToCall)
     
      Set col = dbThis.Unprocesseddocuments
      ReDim vArray(col.Count) As Variant
     
      Set docThis = col.Getfirstdocument()
      i = 0
     
      While Not docThis Is Nothing
              vArray(i) = docThis.Universalid
             
              Set docThis = col.Getnextdocument(docThis)
              i = i + 1
             
      Wend
     
      Set docThat = dbThat.Createdocument()
     
      docThat.OtherDBServer         = dbThis.server        
      docThat.OtherDBPath                = dbThis.Filepath
      docThat.OtherDocs                 = vArray
     
      Call uiws.Dialogbox("Dialog", true, true,,,,, "Dialogaufruf aus einer fremden DB", docThat, true)
     
      MessageBox ("Getroffene Auswahl in Fremddialog: " & cstr(docThat.Selection(0)))
     
End
Sub


In der anderen Datenbank muss eine Maske "Dialog" existieren, die z.B. lokale Scriptbibliotheken rufen kann und (fĂĽr die Funktion des obigen Beispieles) auch RĂĽckgabewerte anbieten kann.


Hintergrundinformation:

Diese Beispiel funktioniert deshalb, weil die "DialogBox"-Funktion ein vordefiniertes Dokument benötigt und abhängig davon, in welcher Datenbank dieses Dokument besteht, diese Datenbank verwendet, um benötigte Gestaltungselemente zu laden. Da der aufgerufene Dialog modal ist, kann diese Werte setzen, welche vom aufrufenden Code (in der Ursprungsdatenbank) verarbeitet werden kann.

Die "Goldenen Regeln" der Lotus Domino Administration

20. Dezember 2010 Posted by Manfred Meise

Um einen mglichst strungsfreien Betrieb der Lotus Notes/Domino Infrastruktur zu gewhrleisten, sind lediglich ein paar Grundregeln zu beachten und einzuhalten. Oder anders formuliert: wer gegen eine dieser Grundregeln verstt oder sie missachtet, schafft sich unntigen zustzlichen (potentiellen) rger.

Die Liste erhebt keinen Anspruch auf Vollstndigkeit und wird (angereichert aus negativen Projekterfahrungen) erweitert werden.

Als verantwortungsvoller Lotus Domino Administrator werde ich …..

1.

Niemals zwei Repliken einer Datenbank auf dem gleichen Server ablegen

2.

Niemals Datenbankdateien eines Dominoservers auf Betriebssystemebene manipulieren (erstellen, umbenennen, lschen, kopieren)

3.

Rcksicherungen von Datenbanken aus Datensicherungen nicht auf den gleichen Domino-Server legen, von dem die Datenbank stammt (siehe Pkt 1)

4.

Auerplanmige Replikationen zwischen Servern stets ber einen Konsolenbefehl (z.B. Serverkonsole im Lotus Domino Administrator, nicht Replikatorseite des Lotus Notes Clients) anstoen

5.

Bei Einsatz von Transaktionsprotokollierung stets eine separate Festplatte (physikalisches Device)  einsetzen und ausreichend Platz fr die Transaktionsprotokollierung anbieten

6.

Transaktionsprotokollierung von Typ „archivierend“ nur einsetzen, wenn auch eine Datensicherungssoftware eingesetzt wird, die dieses untersttzt.

7.

Um aus Schablonen eigene Datenbanken zu erstellen: „Datei -> Datenbank neu“ verwenden, und nicht auf Betriebssystemebene den Dateinamen umbenennen oder kopieren.

8.

Verzeichnisverknpfungen (DIR-Links) stets so einrichten, dass das Ziel der Verknpfung auerhalb des Notes/Domino Datenverzeichnisses zeigt. Nicht verschiedene DIR-Links auf das gleiche Ziel verweisen lassen.

9.

Auf dem System des IBM Domino Servers keinen Lotus Notes/Domino Client installieren, oder den Client-Teil des Servers starten

10.

 Datum/Uhrzeit auf allen Servern/Clients auf Betriebssystemebene und in Lotus Notes/Domino (Server und Client) auf „Sommerzeit gilt hier“ bzw. „von OS bernehmen stellen“ und nach Inbetriebnahme der Software nicht mehr ndern (auch die Uhrzeiten nicht vor-/zurckstellen)

11.

Stets alle Server physikalisch sichern, da Replikationen (auch ClusterReplikationen) niemals eine physikalische Datensicherung ersetzen.

12.

Server stets durchgehend laufen lassen (besonders: Nachts nicht wegen eine OffLine Datensicherung ausschalten) um Housekeeping Functions durchzufhren zu lassen

13.

Server, die lngere Zeit nicht am Netz waren bzw. regelmig repliziert haben (z.B. lnger als 6 Wochen) nicht wieder ans Netz (Replikationen) nehmen, sondern Datenbankreplikate neu holen.

14.

Regelmig (mindestens 1/Tag) alle Systemdatenbanken replizieren.

15.

Servern fremder Domino Domnen NICHT Manager-Berechtigung auf Datenbanken auf eigenen Servern einrumen.

16.

Bei Verwendung verschiedener Releases auf verschiedenen Servern stets die Schablonen der hchsten Release fr Systemdatenbanken einsetzen (Abwrtskompatibilitt ist gegeben).

17.

Bei Einsatz von Betriebssystem-Virenscannern (speziell auf Domino Servern) mindestens das Datenverzeichnis von einer Prfung ausschlieen. Bei Multiuser Installationen von Clients die Datenverzeichnisse aller Benutzer oder (wenn nicht mglich, mindestens *.nsf, *.ntf, *.box) ausnehmen, um korrupte Datenbanken zu vermeiden.

18.

Jeden Domino Server mit einem spezialisierten Virenscanner ausstatten, der die Datenbankinhalte prft.

19.

Nur die Servertasks aktivieren, die auch bentigt und sauber konfiguriert sind

20.

Fr ausscheidende Benutzer nicht lediglich das Personendokument lschen, sondern die dafr vorgesehene \”Benutzer lschen\” verwenden, um den Administrationsprozess mit einer vollstndigen Lschung des Benutzers und Eintrag in eine negativ-Gruppe zu beauftragen

21.

Benutzer im Falle von vergessenen Kennwrtern keine ID  (aus \”alten Zeiten\”) zur Verfgung stellen, sondern den ID-Vault oder Kennwortwiederherstellung verwenden

22

keine Netzwerkfreigaben auf Serverfestplatten erlauben/konfigurieren, auf denen das Domino Directory (oder andere Datenbanken) des Servers gespeichert sind

Die “Goldenen Regeln” der Lotus Domino Administration

20. Dezember 2010 Posted by Manfred Meise

Um einen möglichst störungsfreien Betrieb der Lotus Notes/Domino Infrastruktur zu gewährleisten, sind lediglich ein paar Grundregeln zu beachten und einzuhalten. Oder anders formuliert: wer gegen eine dieser Grundregeln verstößt oder sie missachtet, schafft sich unnötigen zusätzlichen (potentiellen) Ärger.

Die Liste erhebt keinen Anspruch auf Vollständigkeit und wird (angereichert aus negativen Projekterfahrungen) erweitert werden.

Als verantwortungsvoller Lotus Domino Administrator werde ich .....
1. Niemals zwei Repliken einer Datenbank auf dem gleichen Server ablegen
2. Niemals Datenbankdateien eines Dominoservers auf Betriebssystemebene manipulieren (erstellen, umbenennen, löschen, kopieren)
3. Rücksicherungen von Datenbanken aus Datensicherungen nicht auf den gleichen Domino-Server legen, von dem die Datenbank stammt (siehe Pkt 1)
4. Außerplanmäßige Replikationen zwischen Servern stets über einen Konsolenbefehl (z.B. Serverkonsole im Lotus Domino Administrator, nicht Replikatorseite des Lotus Notes Clients) anstoßen
5. Bei Einsatz von Transaktionsprotokollierung stets eine separate Festplatte (physikalisches Device)  einsetzen und ausreichend Platz für die Transaktionsprotokollierung anbieten
6. Transaktionsprotokollierung von Typ „archivierend“ nur einsetzen, wenn auch eine Datensicherungssoftware eingesetzt wird, die dieses unterstützt.
7. Um aus Schablonen eigene Datenbanken zu erstellen: „Datei -> Datenbank neu“ verwenden, und nicht auf Betriebssystemebene den Dateinamen umbenennen oder kopieren.
8. Verzeichnisverknüpfungen (DIR-Links) stets so einrichten, dass das Ziel der Verknüpfung außerhalb des Notes/Domino Datenverzeichnisses zeigt. Nicht verschiedene DIR-Links auf das gleiche Ziel verweisen lassen.
9. Auf dem System des IBM Domino Servers keinen Lotus Notes/Domino Client installieren, oder den Client-Teil des Servers starten
10.  Datum/Uhrzeit auf allen Servern/Clients auf Betriebssystemebene und in Lotus Notes/Domino (Server und Client) auf „Sommerzeit gilt hier“ bzw. „von OS übernehmen stellen“ und nach Inbetriebnahme der Software nicht mehr ändern (auch die Uhrzeiten nicht vor-/zurückstellen)
11. Stets alle Server physikalisch sichern, da Replikationen (auch ClusterReplikationen) niemals eine physikalische Datensicherung ersetzen.
12. Server stets durchgehend laufen lassen (besonders: Nachts nicht wegen eine OffLine Datensicherung ausschalten) um Housekeeping Functions durchzuführen zu lassen
13. Server, die längere Zeit nicht am Netz waren bzw. regelmäßig repliziert haben (z.B. länger als 6 Wochen) nicht wieder ans Netz (Replikationen) nehmen, sondern Datenbankreplikate neu holen.
14. Regelmäßig (mindestens 1/Tag) alle Systemdatenbanken replizieren.
15. Servern fremder Domino Domänen NICHT Manager-Berechtigung auf Datenbanken auf eigenen Servern einräumen.
16. Bei Verwendung verschiedener Releases auf verschiedenen Servern stets die Schablonen der höchsten Release für Systemdatenbanken einsetzen (Abwärtskompatibilität ist gegeben).
17. Bei Einsatz von Betriebssystem-Virenscannern (speziell auf Domino Servern) mindestens das Datenverzeichnis von einer Prüfung ausschließen. Bei Multiuser Installationen von Clients die Datenverzeichnisse aller Benutzer oder (wenn nicht möglich, mindestens *.nsf, *.ntf, *.box) ausnehmen, um korrupte Datenbanken zu vermeiden.
18. Jeden Domino Server mit einem spezialisierten Virenscanner ausstatten, der die Datenbankinhalte prüft.
19. Nur die Servertasks aktivieren, die auch benötigt und sauber konfiguriert sind
20. Für ausscheidende Benutzer nicht lediglich das Personendokument löschen, sondern die dafür vorgesehene "Benutzer löschen" verwenden, um den Administrationsprozess mit einer vollständigen Löschung des Benutzers und Eintrag in eine negativ-Gruppe zu beauftragen
21. Benutzer im Falle von vergessenen Kennwörtern keine ID  (aus "alten Zeiten") zur Verfügung stellen, sondern den ID-Vault oder Kennwortwiederherstellung verwenden
22 keine Netzwerkfreigaben auf Serverfestplatten erlauben/konfigurieren, auf denen das Domino Directory (oder andere Datenbanken) des Servers gespeichert sind
23. Wenn Benutzer mit falschem Namen angelegt wurden (noch bevor ein Client in Betrieb genommen wurde), diesen nicht umbenennen, sondern entweder vollständig löschen oder eine Umbenennung erst nach der Client Inbetriebnahme anstoßen.



Die “Goldenen Regeln” der Lotus Domino Administration

20. Dezember 2010 Posted by Manfred Meise

Um einen möglichst störungsfreien Betrieb der Lotus Notes/Domino Infrastruktur zu gewährleisten, sind lediglich ein paar Grundregeln zu beachten und einzuhalten. Oder anders formuliert: wer gegen eine dieser Grundregeln verstößt oder sie missachtet, schafft sich unnötigen zusätzlichen (potentiellen) Ärger.

Die Liste erhebt keinen Anspruch auf Vollständigkeit und wird (angereichert aus negativen Projekterfahrungen) erweitert werden.

Als verantwortungsvoller Lotus Domino Administrator werde ich .....
1. Niemals zwei Repliken einer Datenbank auf dem gleichen Server ablegen
2. Niemals Datenbankdateien eines Dominoservers auf Betriebssystemebene manipulieren (erstellen, umbenennen, löschen, kopieren)
3. Rücksicherungen von Datenbanken aus Datensicherungen nicht auf den gleichen Domino-Server legen, von dem die Datenbank stammt (siehe Pkt 1)
4. Außerplanmäßige Replikationen zwischen Servern stets über einen Konsolenbefehl (z.B. Serverkonsole im Lotus Domino Administrator, nicht Replikatorseite des Lotus Notes Clients) anstoßen
5. Bei Einsatz von Transaktionsprotokollierung stets eine separate Festplatte (physikalisches Device)  einsetzen und ausreichend Platz für die Transaktionsprotokollierung anbieten
6. Transaktionsprotokollierung von Typ „archivierend“ nur einsetzen, wenn auch eine Datensicherungssoftware eingesetzt wird, die dieses unterstützt.
7. Um aus Schablonen eigene Datenbanken zu erstellen: „Datei -> Datenbank neu“ verwenden, und nicht auf Betriebssystemebene den Dateinamen umbenennen oder kopieren.
8. Verzeichnisverknüpfungen (DIR-Links) stets so einrichten, dass das Ziel der Verknüpfung außerhalb des Notes/Domino Datenverzeichnisses zeigt. Nicht verschiedene DIR-Links auf das gleiche Ziel verweisen lassen.
9. Auf dem System des IBM Domino Servers keinen Lotus Notes/Domino Client installieren, oder den Client-Teil des Servers starten
10.  Datum/Uhrzeit auf allen Servern/Clients auf Betriebssystemebene und in Lotus Notes/Domino (Server und Client) auf „Sommerzeit gilt hier“ bzw. „von OS übernehmen stellen“ und nach Inbetriebnahme der Software nicht mehr ändern (auch die Uhrzeiten nicht vor-/zurückstellen)
11. Stets alle Server physikalisch sichern, da Replikationen (auch ClusterReplikationen) niemals eine physikalische Datensicherung ersetzen.
12. Server stets durchgehend laufen lassen (besonders: Nachts nicht wegen eine OffLine Datensicherung ausschalten) um Housekeeping Functions durchzuführen zu lassen
13. Server, die längere Zeit nicht am Netz waren bzw. regelmäßig repliziert haben (z.B. länger als 6 Wochen) nicht wieder ans Netz (Replikationen) nehmen, sondern Datenbankreplikate neu holen.
14. Regelmäßig (mindestens 1/Tag) alle Systemdatenbanken replizieren.
15. Servern fremder Domino Domänen NICHT Manager-Berechtigung auf Datenbanken auf eigenen Servern einräumen.
16. Bei Verwendung verschiedener Releases auf verschiedenen Servern stets die Schablonen der höchsten Release für Systemdatenbanken einsetzen (Abwärtskompatibilität ist gegeben).
17. Bei Einsatz von Betriebssystem-Virenscannern (speziell auf Domino Servern) mindestens das Datenverzeichnis von einer Prüfung ausschließen. Bei Multiuser Installationen von Clients die Datenverzeichnisse aller Benutzer oder (wenn nicht möglich, mindestens *.nsf, *.ntf, *.box) ausnehmen, um korrupte Datenbanken zu vermeiden.
18. Jeden Domino Server mit einem spezialisierten Virenscanner ausstatten, der die Datenbankinhalte prüft.
19. Nur die Servertasks aktivieren, die auch benötigt und sauber konfiguriert sind
20. Für ausscheidende Benutzer nicht lediglich das Personendokument löschen, sondern die dafür vorgesehene "Benutzer löschen" verwenden, um den Administrationsprozess mit einer vollständigen Löschung des Benutzers und Eintrag in eine negativ-Gruppe zu beauftragen
21. Benutzer im Falle von vergessenen Kennwörtern keine ID  (aus "alten Zeiten") zur Verfügung stellen, sondern den ID-Vault oder Kennwortwiederherstellung verwenden
22 keine Netzwerkfreigaben auf Serverfestplatten erlauben/konfigurieren, auf denen das Domino Directory (oder andere Datenbanken) des Servers gespeichert sind
23. Wenn Benutzer mit falschem Namen angelegt wurden (noch bevor ein Client in Betrieb genommen wurde), diesen nicht umbenennen, sondern entweder vollständig löschen oder eine Umbenennung erst nach der Client Inbetriebnahme anstoßen.



Die “Goldenen Regeln” der Lotus Domino Administration

20. Dezember 2010 Posted by Manfred Meise

Um einen möglichst störungsfreien Betrieb der Lotus Notes/Domino Infrastruktur zu gewährleisten, sind lediglich ein paar Grundregeln zu beachten und einzuhalten. Oder anders formuliert: wer gegen eine dieser Grundregeln verstößt oder sie missachtet, schafft sich unnötigen zusätzlichen (potentiellen) Ärger.

Die Liste erhebt keinen Anspruch auf Vollständigkeit und wird (angereichert aus negativen Projekterfahrungen) erweitert werden.

Als verantwortungsvoller Lotus Domino Administrator werde ich .....
1. Niemals zwei Repliken einer Datenbank auf dem gleichen Server ablegen
2. Niemals Datenbankdateien eines Dominoservers auf Betriebssystemebene manipulieren (erstellen, umbenennen, löschen, kopieren)
3. RĂĽcksicherungen von Datenbanken aus Datensicherungen nicht auf den gleichen Domino-Server legen, von dem die Datenbank stammt (siehe Pkt 1)
4. Außerplanmäßige Replikationen zwischen Servern stets über einen Konsolenbefehl (z.B. Serverkonsole im Lotus Domino Administrator, nicht Replikatorseite des Lotus Notes Clients) anstoßen
5. Bei Einsatz von Transaktionsprotokollierung stets eine separate Festplatte (physikalisches Device)  einsetzen und ausreichend Platz fĂĽr die Transaktionsprotokollierung anbieten
6. Transaktionsprotokollierung von Typ „archivierend“ nur einsetzen, wenn auch eine Datensicherungssoftware eingesetzt wird, die dieses unterstĂĽtzt.
7. Um aus Schablonen eigene Datenbanken zu erstellen: „Datei -> Datenbank neu“ verwenden, und nicht auf Betriebssystemebene den Dateinamen umbenennen oder kopieren.
8. VerzeichnisverknĂĽpfungen (DIR-Links) stets so einrichten, dass das Ziel der VerknĂĽpfung auĂźerhalb des Notes/Domino Datenverzeichnisses zeigt. Nicht verschiedene DIR-Links auf das gleiche Ziel verweisen lassen.
9. Auf dem System des IBM Domino Servers keinen Lotus Notes/Domino Client installieren, oder den Client-Teil des Servers starten
10.  Datum/Uhrzeit auf allen Servern/Clients auf Betriebssystemebene und in Lotus Notes/Domino (Server und Client) auf „Sommerzeit gilt hier“ bzw. „von OS ĂĽbernehmen stellen“ und nach Inbetriebnahme der Software nicht mehr ändern (auch die Uhrzeiten nicht vor-/zurĂĽckstellen)
11. Stets alle Server physikalisch sichern, da Replikationen (auch ClusterReplikationen) niemals eine physikalische Datensicherung ersetzen.
12. Server stets durchgehend laufen lassen (besonders: Nachts nicht wegen eine OffLine Datensicherung ausschalten) um Housekeeping Functions durchzufĂĽhren zu lassen
13. Server, die längere Zeit nicht am Netz waren bzw. regelmäßig repliziert haben (z.B. länger als 6 Wochen) nicht wieder ans Netz (Replikationen) nehmen, sondern Datenbankreplikate neu holen.
14. Regelmäßig (mindestens 1/Tag) alle Systemdatenbanken replizieren.
15. Servern fremder Domino Domänen NICHT Manager-Berechtigung auf Datenbanken auf eigenen Servern einräumen.
16. Bei Verwendung verschiedener Releases auf verschiedenen Servern stets die Schablonen der höchsten Release für Systemdatenbanken einsetzen (Abwärtskompatibilität ist gegeben).
17. Bei Einsatz von Betriebssystem-Virenscannern (speziell auf Domino Servern) mindestens das Datenverzeichnis von einer Prüfung ausschließen. Bei Multiuser Installationen von Clients die Datenverzeichnisse aller Benutzer oder (wenn nicht möglich, mindestens *.nsf, *.ntf, *.box) ausnehmen, um korrupte Datenbanken zu vermeiden.
18. Jeden Domino Server mit einem spezialisierten Virenscanner ausstatten, der die Datenbankinhalte prĂĽft.
19. Nur die Servertasks aktivieren, die auch benötigt und sauber konfiguriert sind
20. Für ausscheidende Benutzer nicht lediglich das Personendokument löschen, sondern die dafür vorgesehene "Benutzer löschen" verwenden, um den Administrationsprozess mit einer vollständigen Löschung des Benutzers und Eintrag in eine negativ-Gruppe zu beauftragen
21. Benutzer im Falle von vergessenen Kennwörtern keine ID  (aus "alten Zeiten") zur VerfĂĽgung stellen, sondern den ID-Vault oder Kennwortwiederherstellung verwenden
22 keine Netzwerkfreigaben auf Serverfestplatten erlauben/konfigurieren, auf denen das Domino Directory (oder andere Datenbanken) des Servers gespeichert sind
23. Wenn Benutzer mit falschem Namen angelegt wurden (noch bevor ein Client in Betrieb genommen wurde), diesen nicht umbenennen, sondern entweder vollständig löschen oder eine Umbenennung erst nach der Client Inbetriebnahme anstoßen.