beim öffnen einer Datenbank, abfragen ob Server erreichbar

[timo0815]

Guten Abend,

die meisten kennen sicher das Problem .. man zieht sich eine Datenbank-Replik lokal und schwupps, nach dem ersten Nutzen des Lesezeichens, wird die Datenbank (sofern keine Verbindung zum Server besteht) immer wieder lokal geöffnet, wenn man das Lesezeichen nutzt

Nun würde ich gerne in das QueryOpen (oder so) der Datenbank eine If-Abfrage (oder so) einbringen, um die Datenbank möglichst immer vom Server zu öffnen. Also so in die Richtung..

wenn server erreichbar dann
  öffne die Datenbank vom Server
ansonsten
  öffne die Datenbank lokal
ende

Sollte die Problematik doch lösen oder? Oder habt ihr andere Ideen? Wenn nicht, kann mir jemand meine Idee in Script umsetzen oder mir sagen welche Befehle ich dafür nutzen kann?

Danke, Timo

[Semeaphoros]

Naja, ob das wirklich zum Funktionieren gebracht werden kann, wage ich zu bezweifeln. Jedenfalls, Du müsstest die NotesDatabase, die NotesUIDatabase und die NotesUIWorkspace Klassen mal etwas genauer studieren.

[koehlerbv]

Ist der Code in der Datenbank selber untergebracht, kann das prinzipiell nicht funktionieren - entweder die DB wurde dann bereits geöffnet oder der Prozess des Öffnens läuft bereits. Die von Jens erwähnten Klassen (und alle anderen) nutzen Dir dann herzlich wenig, da Du die DB - sofern sie vom falschen Ort geöffnet wird - wieder schliessen müsstest und damit würde auch der Code beendet.

Lesezeichen sind für das gezielte Öffnen (durch "normale User") von Datenbanken leider nicht unbedingt eine gute Erfindung.

Was Du machen kannst (u.a.): Eine eigene Datenbank erstellen, die beim Notes-Start automatisch geöffnet wird (damit kann das durchaus die Bookmark sein, die dann anzupassen ist) und dann dort über Elemente (grafisch, Menü) das Öffnen der DB entsprechend vorbereiten und durchführen. Hierbei könntest Du sogar (mit Einschränkungen) mit Formelsprache arbeiten (@Command ([OpenDatabase] ...) und den Parameter ServerHint benutzen.

A propos "Server": Was ist bei Dir eigentlich "der Server" ? Zum einen können dies ja durchaus unterschiedliche in einem Unternehmen sein, zum anderen kann es erforderlich sein, eine Datenbank auf einem anderen Server als dem "üblichen" (MailDB-HomeServer) oder trotz Serververbindung eben durch lokal zu öffnen. Das wäre dann Dein nächsten Problem.

Langer Rede kurzer Sinn: Es ist noch viel mehr zu bedenken, um erstmal in die Richtung zu kommen, in die Du willst.

Bernhard

[timo0815]

hallo nochmals,

puuuh .. danke für eure Hinweise; da hab ich mir das wohl doch zu einfach vorgestellt. Ich werd mir mal die genannten Befehle und Co zur Gemüte führen, aber ich denke das wird wohl ziemlich aufwendig (um nicht zu sagen, zu aufwendig)

Aber eine Funktion á la "bevorzugter Server" oder "Reihenfolge fürs öffnen" fehlt mir in den Lesezeichen einfach irgendwie. Naja, wer weiß was IBM in Zukunft noch so bringen wird...

Danke auf jeden Fall an euch beide!

Gruß, Timo

ps:
"Der Server" sollte übrigens bedeuten, dass die Datenbank nur auf einem Server liegt.

[Semeaphoros]

Die Bedenken von Bernhard sind angebracht (daher ja auch meine zweifelnde Bemerkung). Das Problem, dass man sich beim Schliessen der lokalen DB den Stuhl unter dem eigenen Gesäss wegzieht, ist natürlich gegeben, mit etwas Glück könnte es allenfalls funktionieren, wenn diese Operation ganz am Schluss durchgeführt wird.

[koehlerbv]

@Timo: Ich denke, Lösungen findest Du hier eher im administrativen Bereich. Die gute, alte "Kacheloberfläche" (Desktop) bekommt recht sauber mit, wenn sich durch einen Wechsel der Arbeitsumgebung die DBs auf dem zugehörigen Server oder eben lokal befinden - ausserdem ist - im Gegensatz zu den Bookmarks - der Server auf dem DB-Icon angezeigt.

@Semeaphoros:

... mit etwas Glück könnte es allenfalls funktionieren, wenn diese Operation ganz am Schluss durchgeführt wird.

Auf das Glück sollte man sich bei der Programmierung niemals verlassen (obwohl es doch alle mehr oder weniger unbewusst tun  ). Das Verfahren klappt aber auf jeden Fall nicht - "zum Schluss" wird die die LS-Routine beherbergende DB terminiert und damit auch zwingend das LS-Modul. Das ist immer "aus die Maus". Bei einer eigenen DB (und sei es die Bookmarks) kann man das ganze aber in eine übergeordnete Instanz verschieben. Letztendlich befriedigend fand ich aber auch diese Lösungen bisher nicht wegen Risiken udn Nebenwirkungen.

Bernhard

[ctillmanns]

Und heute schiessen wir mal wieder mit Kanonen auf Spatzen, denn ich hätte da folgenden Vorschlag:

Wir hatten eine eigene DB für die Navigation durch die anderen DBs. Abgesehen von ein paar Berechtigungsanwendungen enthielt die DB eigentlich nur eine Outline, deren Einträge entweder auf den Server zeigten, oder auf die lokalen Repliken. Gesteuert wurde das ganze mit Umgebungsvariablen - bitte keinen Aufschrei wegen der Jungfäulichkeit der ini. Klappte wunderbar und die User konnten so steuern, auf welcher Replik sie gerade arbeiten wollten.

Aber eben, dass lohnt sich nur für wirklich grosse und komfortable Anwendungen.

[koehlerbv]

Das hatte ich so doch oben schon beschrieben, tillsche 

Bernhard

[ctillmanns]

@Bernhard
Hast ja recht. Wollte nur mal auf das Environment hinweisen.
Ich hatte nämlich schon den Fall, dass Benutzer im Büro auf dem Server gearbeitet und dann nicht repliziert haben. Die haben dann aufgeregt gemeldet, dass die ganzen Daten weg wären, als sie wieder ohne Verbindung waren. Mit dem Environment bleibt es bei den lokalen Datenbanken, auch wenn Sie Verbindung zum Server haben. Was ich wegen diesen Erfahrungen für besser halte.

Sorry

[TMC]

Hi,

ich zeige eigentlich in jeder DB an gut sichtbarer Stelle (auf einer Seite im Frameset) immer den aktuellen Servernamen an, also z.B. so:

_Server := @Subset(@DbName;1);
@If(_Server=""; "Local"; @Name([Abbreviate]; _Server))

Befindet sich in jeder DB an mehr oder weniger derselben Stelle, und die Notebook-User sind auch entsprechend geschult. Denn oft öffnen User ja auch unbewusst DBs lokal, obwohl der Server verfügbar ist.

Jetzt könnte man noch zusätzlich nach jedem Öffnen der DB z.B. eine Msgbox-Meldung anzeigen, wenn die DB lokal geöffnet wurde, um darauf explizit hinzuweisen: "Die Datenbank wurde lokal geöffnet, bitte vergessen Sie nicht, zu replizieren!" o.ä.

[TMC]

Ist der Code in der Datenbank selber untergebracht, kann das prinzipiell nicht funktionieren - entweder die DB wurde dann bereits geöffnet oder der Prozess des Öffnens läuft bereits. Die von Jens erwähnten Klassen (und alle anderen) nutzen Dir dann herzlich wenig, da Du die DB - sofern sie vom falschen Ort geöffnet wird - wieder schliessen müsstest und damit würde auch der Code beendet.

Hmm, sicher, Bernhard?

Folgender Ansatz:

Code

Sub Click(Source As Button)
	
	Const DESTINATION_SERVER$ = "SERVER"
	Const DESTINATION_PATH$ = "PFAD/DB"
	
	On Error Goto ErrorHandler
	
	Dim session As New NotesSession		
	Dim dbThis As NotesDatabase
	Dim uidbThis As NotesUIDatabase	
	Dim uiws As New NotesUIWorkspace	
	
	Set dbThis = session.CurrentDatabase
	
	If Not dbThis.Server = "" Then Goto GoOut	'Database has been opened on a server, so we go out here
	
	Msgbox "User arbeitet lokal, wir öffnen ein neues Fenster mit der Server-DB"
	
	Set uidbThis = uiws.CurrentDatabase
	Call uidbThis.Close
	
	Call uiws.OpenDatabase( DESTINATION_SERVER, DESTINATION_PATH, , , True)
	
GoOut:
	Exit Sub
ErrorHandler:
	ErrorMsg
	Resume GoOut
End Sub

Hab aber jetzt keinen Server hier, sondern konnte nur lokal mit einer 2. DB testen.

1. ist hier die OpenDatabase-Property newInstance = True interessant.
2. ist die Close Method der NotesUIDatabase-Klasse interessant.

Man könnte jetzt noch damit spielen, uiws.OpenDatabase VOR dem "Call uidbThis.Close" aufzurufen, falls da was nicht klappt.

Aber IMHO sollte das so gehen.

Matthias

[koehlerbv]

Matthias, keine Frage - sowas geht. Aber dann ist ja immer noch die "falsche" DB geöffnet und kann wieder verwechselt werden usw. Man würde aus der nun geöffneten DB auch die ursprüngliche "falsche" via WinAPI wieder schliessen können, aber auch das ist m.E. nicht der (sichere) Weisheit letzter Schluss. Es bleibt j auch immer die Frage: Was ist überhaupt der "richtige Server" - die Frage steht ja nach wie vor und ist m.E. nicht simpel zu beantworten.

So, wie von Dir vorher beschrieben (deutliche Anzeige des aktuell verwendeten Servers bzw. "local") zu verfahren und die Nutzer zu sensiblisieren, ist m.E. auch sehr gangbarer Weg (wozu ist der Mensch sonst noch da, als die Maschine zu kontrollieren. Naja, hier ein schwaches Argument).

Um versehentlich zu langes Arbeiten ohne Serverkontakt (sprich: Erfolgreiche Replizierung) arbeite ich bei in dieser Hinsicht kritischen DB mit einem TimeStamp in einem Setup-Dok, welches nur vom massgeblichen Server stammen kann. Ist dieser Wert zu niedrig (sprich: Es wurde nicht repliziert oder auf dem Server läuft etwas schief), dann werden alle entscheidenden Aktionen in der DB (im FrontEnd) nicht mehr zugelassen. Erst nach der Replikation passt der TimeStamp wieder.

Wie dem auch sei: Wir haben es mit einer verteilen Umgebung zu tun, und das ist bekanntermassen ein sehr weites Feld. Und die bookmarks.ntf ist sicherlich nicht DIE Antwort auf diese Problematik.

Bernhard

[TMC]

Aber dann ist ja immer noch die "falsche" DB geöffnet

Wie meinst Du das?

Die Help meint:

notesUIDatabase.Close
Closes all views and documents in the database, then closes the database.

Bei meinem Test war das auch so: in einem neuen Fenster öffnet sich eine neue DB (in meinem lokalen Test hab ich eine andere DB öffnen lassen), und die aktuell offene DB schließt sich komplett mit allen offenen Doks. Wie gesagt, auf einem Server hab ich das noch nicht getestet.

Ich denke so ist das Ziel erreicht. Jetzt nur noch eben die "Qual der Wahl": welchen Server nimmt man? Kann je nach Domino-Infrastruktur anders zu lösen sein.

Matthias

[koehlerbv]

Matthias, wenn das mit zwei lokalen DBs klappt, klappt das auch mit Repliken auf "local" und auf einem Server. Ich muss mir Deinen Weg unbedingt vornehmen - der funktionierte bei meinen letzten Tests nicht. Aber Schande über mich: Ich habe das wirklich lange nicht mehr ausprobiert (und bin eben immer andere Wege gegangen, die in der Regel auch notwendig waren wegen dem von Dir schon erwähnten Fakt: "Jetzt nur noch eben die "Qual der Wahl": welchen Server nimmt man?").

Ergo: Vielen Dank für Deine Mühen. Und das ganze Thema (mit allem Drumherum) sollte weiter diskutiert werden - das wird sicherlich viele interessieren. Ich bleib' da auch mit dran.

Bernhard

[TMC]

Kein Thema, gern geschehen. War nur so eine Idee die mir kam, daher hab ich mir das näher angesehen.

Gute Nacht,
Matthias