Alle EXE' n einer Anwendung zum Zeitpunkt X beenden...

[himitsu]

Eventuell kann Firebird und deine DB-Komponenten auch mit Notification/Callbacks umgehen.

Sonst fragt der Client ja beim Server an, aber bei Notifications wendet sich der Server an einen/alle Clienten und schickt denen eine Nachricht.
Beim Empfang einer Nachricht kannst du das auswerten und z.B. auf den Text "Beenden" reagieren.

Ich hatte das letztens bei uns so umgesetzt, daß man z.B. eine MessageBox anzeigen kann (User+Message, bzw. All+Message) oder eben ein Shutdown-Befehl (Timeout+Message)
"Programm wird in 5 Mnuten beendet. Bitte speichern." oder Dregleichen.

Die Befehle sind einfach wie eine Stringliste hinterlegt, da die Notification ein String ist.
Command=Shutdown;Timeout=300;Message=Wartungsupdate

[edit]
Und ja, manchmal hängen die Events/Notifications etwas, oder arbeiten garnicht.

[mkinzler]

Bei Firebird Events benachrichtigt der Server die Clients, welche sich für dafür beim Server registriert haben.

[dataspider]

Zitat von himitsu:

Eventuell kann Firebird und deine DB-Komponenten auch mit Notification/Callbacks umgehen.

Ich denke - wie mkinzler auch - dass die Events (POST_EVENT) von Firebird vom Server ausgehen und damit wohl genau das tun, was du beschreibst.
Ich bin nun sowieso fast fertig und kann mit der Lösung gut leben...

Nochmals Danke

Frank

[Dejan Vu]

Ich habe dieses Problem so gelöst, das die Anwender die EXE einfach nicht direkt starten können. Sie starten eine Batch-Datei, die aus dem Netz die EXE lokal kopiert und dann ausführt. So kann ich Ruhe meine Updates einspielen und beim nächsten Start haben alle Anwender automatisch die aktuelle EXE.

Bei dieser Vorgehensweise reicht ein "Es ist eine neue Version verfügbar, welche beim nächsten Start automatisch geladen wird." als Nachricht. Alternativ kann man die Batch-Datei durch einen UI-gepimpten 'Loader' ersetzen, der irgendwelche Releasenotes anzeigt, sofern die EXE neueren Datums ist.

Nachrichten habe ich einmal über Mailslots verschickt. Ich fand es blöd, dafür eine Tabelle vorzuhalten. Für 'offline' und 'latest News' sowie eine History (wer wann gelesen) ist das aber durchaus sinnvoll.

[dataspider]

Zitat von Dejan Vu:

Ich habe dieses Problem so gelöst, das die Anwender die EXE einfach nicht direkt starten können. Sie starten eine Batch-Datei, die aus dem Netz die EXE lokal kopiert und dann ausführt. So kann ich Ruhe meine Updates einspielen und beim nächsten Start haben alle Anwender automatisch die aktuelle EXE.

Das hatte ich auch mal. Ich hatte dafür eine eigene AppStart.EXE und eine INI mit allen Parametern für den Abgleich.

Mein eigentliches Problem ist aber, dass ich zumindest bei diesem Projekt sicherstellen muss, dass während des DB-Updates alle Benutzer von der Datenbank getrennt sind.

Danke

Frank

[mm1256]

Zitat von dataspider:

Mein eigentliches Problem ist aber, dass ich zumindest bei diesem Projekt sicherstellen muss, dass während des DB-Updates alle Benutzer von der Datenbank getrennt sind.

....und während des Updatevorganges kein ReConnect eines Clients stattfinden darf.

Dieses Problem löse ich wie folgt: Auf dem Server liegt eine Tabelle mit Login-Logout-Informationen jedes Clients, physikalischer Dateiname "Logbuch". Darin wird protokolliert, wann User im Netzwerk ein Programm starten, und wann (und ob) sie es wieder ordnungsgemäß beenden. Bei einem Update ohne strukturelle Änderungen an der DB (ein quasi On-the-Fly-Update) bleibt die Struktur dieser Tabelle gleich. Wenn aber - so wie vermutlich auch bei dir - strukturelle Änderungen an den Datenbanken vorgenommen werden (müssen) gehe ich wie folgt vor:

- der DB-Server-Dienst wird beendet
- TCP/IP wird im DB-Server deaktiviert
- der DB-Server wird mit lokalem Zugriff (named Pipe) gestartet
- die Struktur der Logbuch-Tabelle wird geändert, d.h. das Feld bzw. der Feldname mit der Versionsnummer wird umbenannt
- weitere Strukturänderungen werden durchgeführt
- das Update (Programmdateien) wird installiert
- der DB-Server wird mit aktiviertem TCP/IP neu gestartet

Aufgrund Verwendung einer persistenten Feldliste können nun ältere Programmversionen generell nicht mehr am System angemeldet werden, weil ja das Feld (der Feldname) mit der neuen Versionsnummer bei der Anmeldung nicht gefunden wird. Die Exception wird behandelt und der User darauf hingewiesen, dass er versucht hat, sich mit einer alten Programmversion am neuen Datenbestand anzumelden. Das funktioniert immer, sowohl bei lokalen auf dem Client liegenden Programmdateien als auch bei shared auf dem Server liegenden Programmdateien.

[Mavarik]

Früher habe ich auch den Trick mit der Batch Datei gemacht...

Warum legst Du nicht einfach eine Datei hin DeinProgramm.Upd
Beim Start testest Du ab ob die Datei da ist und wenn ja starttest Du per Shellexecute ein Renamer der die aktuelle Version schließt und dann
DeinProgramm.exe löscht und DeinProgramm.Upd renamed auf *.exe.

Mavarik

[dataspider]

Zitat von mm1256:

- der DB-Server-Dienst wird beendet
- TCP/IP wird im DB-Server deaktiviert
...

Fehlt am Anfang als Erstes: Alle laufenden Anwendungen, die auf die Datenbank zugreifen, werden beendet.
Nur das war mein Problem.
Dann erfolgt ein ShutDown des Firebird - Servers...

Trotzdem Danke. Anregungen sind immer wertvoll!

Zitat von Mavarik:

Warum legst Du nicht einfach eine Datei hin DeinProgramm.Upd
Beim Start testest Du ab ob die Datei da ist und wenn ja starttest Du per Shellexecute ein Renamer der die aktuelle Version schließt und dann
DeinProgramm.exe löscht und DeinProgramm.Upd renamed auf *.exe.
Mavarik

siehe #15...
Ohne "Zwangstrennung" geht es nicht, dennoch soll diese "sanft" erfolgen

Frank

[mkinzler]

Ich würde nicht den Firebird Server beenden, sondern die Datenbank in den Wartungsmodus versetzen.

[dataspider]

Zitat von mkinzler:

Ich würde nicht den Firebird Server beenden, sondern die Datenbank in den Wartungsmodus versetzen.

Genau das macht ja ShutDown des Firebird Servers.
Ich will ja auch die Update - Scripts einspielen.

Frank