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

[dataspider]

Ich habe einen Kunden, bei dem ein Update immer ein Problem ist.
Trotz Ankündigung von Updates muss ich dann immer noch mindestens 10 User rauswerfen.

Jetzt würde ich gern z.B. 20:00 Uhr en alle EXE' n eine Nachricht senden, dass bis 20:15 Uhr das Programm zu verlassen ist.
20:15 Uhr folgt die zweite Nachricht, die die EXE' n hart beendet.

Mir geht es nur um die Nachricht an die EXE.

Momentan überlege ich, ob ich einfach die Events von Firebird benutze.
Wie kann man das eleganter lösen?

Die Anwendung liegt auf einem TS. Eine Gruppe Anwender startet die EXE lokal vom Server, die andere Gruppe aus der TS - Session.

Frank

[BUG]

Zitat:

Zitat von dataspider (Beitrag 1305286)

Wie kann man das eleganter lösen?

Wenn das momentan einzige Kanal ist, über die die Clients miteinander kommunizieren, dann würde ich das so machen. Dazu gibt es eine Nachrichten-Tabelle und wenn der Client das Signal erhält, guckt er nach was er machen muss; genauso beim Starten der Anwendung.

Was will man mehr? :mrgreen:

[mkinzler]

Da sich alle Instanzen Deiner Anwendung am FireBird Server anmelden müssen, wäre das aus meiner Sicht eine einfache Lösung.

[stahli]

Ich habe das vor Urzeiten mal so gelöst, dass ich eine "Beenden.txt" neben der Exe (die im Netzwerk von allen Usern erreichbar war) erzeugt habe.
Die Clients haben immer mal auf Existenz der txt geprüft und deren Inhalt dann in einem Editor ausgegeben und sich beendet.

Ob das besonders elegant ist, müsste man hier mal abstimmen... :duck:

[dataspider]

@stahli
Das war mein zweiter Ansatz, also ein Timer und dann nachsehen - wo auch immer.

Ich nehme das Event und eine Tabelle, wie BUG es vorgeschlagen hat.
Da kann ich auch alle Informationen wie Zeit Meldung, Zeit Beenden, Texte etc. unterbringen.

Vielen Dank

Frank

[Mikkey]

Du kannst doch die alte Exe umbenennen und die neue an deren Stelle hinstellen.

Bei nächster Gelegenheit wird dann die alte Exe weggeräumt.

Früher (tm) beim Mehrbenutzer-Unix konnte man die Binarys einfach so löschen, der Prozess ist dann bei der nächsten Gelegenheit, wenn irgendwelche Codeblöcke nachgeladen werden mussten abgeschmiert :thumb:

[dataspider]

Zitat:

Zitat von Mikkey (Beitrag 1305296)

Du kannst doch die alte Exe umbenennen und die neue an deren Stelle hinstellen.

Das ist schon richtig, aber manchmal ist es aber auch notwendig, dass keiner mehr an der DB angemeldet ist.

Frank

[mikhal]

Ich gebe aber noch etwas zu bedenken: Es wird ja normalerweise einen Grund haben, dass die Clients noch arbeiten. Wie willst du ausschließen, dass so ein Cleverle nicht einfach das Programm neu startet?

Auch darüber solltest du nachdenken. Du solltest im Vorfeld einen Reconnect mit der Datenbank verhindern.

Grüße
Mikhal

[Blup]

Verlass dich nicht nur auf die Events, die funktionieren nicht unbedingt in jeder Softwareumgebung.
Dafür muss der Client einen Port öffnen können, den der Server dann anspricht.
Manche Firewall oder Virenscan-Super-Komplettpakete mögen das garnicht.
Da ist es gut wenn man noch einen Alternative mit Timer und Abfrage im Programm vorgesehen hat.

Man kann übriegens jede Datenbankdatei einzeln als Db-Admin runterfahren, damit wird normalen Anwender der Zugriff entzogen.
Der Zugriff als Db-Admin z.B. für Update oder Wartungsarbeiten ist weiterhin möglich.

Im Idealfall werden die Sperrvermerke in einer separaten Datenbankdatei untergebracht.
So kann die Anwendung diese bei Start auch abfragen, wenn zur Zeit die gewünschte Datenbank gesperrt ist und den Anwender über Grund und voraussichtliche Dauer informieren.

[dataspider]

Zitat:

Zitat von mikhal (Beitrag 1305298)

Du solltest im Vorfeld einen Reconnect mit der Datenbank verhindern.

Danke, ein wertvoller Hinweis.
Da ich sowieso zu Beginn auf Wartung prüfen muss, kann ich das hier einbauen...

Frank

[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.

Delphi-Quellcode:

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:

Zitat von himitsu (Beitrag 1305302)

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:

Zitat von Dejan Vu (Beitrag 1305370)

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:

Zitat von dataspider (Beitrag 1305380)

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:

Zitat von mm1256 (Beitrag 1305383)

- 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:

Zitat von Mavarik (Beitrag 1305387)

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:

Zitat von mkinzler (Beitrag 1305517)

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