Tranx - Mi 11.03.15 08:50
Titel: Serveranwendung - EXE-Datei entsperren

---

Hallo, ich habe hier eine Frage, kurz erst einmal zur Situation:

Ich habe ein Programm, welches von allen Netzusern genutzt wird, auf dem Server. Nun möchte ich eine geänderte Version auf dem Server speichern. Doch leider ist die EXE-Datei gesperrt, solange ein einziger User diese nutzt. Ich muss also die Nutzer alle bitten, das Programm zu schließen. Kein Problem, ich habe ja nicht 100 Nutzer, sondern bloß 14, aber nervig ist es, wenn man einen vergisst oder an User-unabhängigen Rechnern das selbe Programm doch noch laufen hat.

Meine Frage: Wie kann ich das Programm entsperren und dann die Programmdatei ersetzen?

Eigentlich schreibt doch kein User etwas in die Programmdatei, oder? Wird das Programm nicht komplett in den Speicher geladen, beim Aufruf und man arbeitet dann mit der Netzwerkgespeicherten Datei? Das wäre m.E. doch unsinnig, da das ja dauernd eine Netzwerkaktivität erzeugen würde, neben der Datenbankanwendung, die dahinter noch vom Programm genutzt wird.

Aber in den Details kenne ich mich nur wenig aus. Daher frage ich Euch.

Der Neuaufruf des Programms zur Nutzung der aktuellen Version ist kein Problem, da ich im Betrieb nur einzelne Routinen ändere, die nur einzelne Nutzer verwenden, andere dahingehend gar nicht. So dass ich diesen Nutzer dann über einen notwendigen Neuaufruf des Programms informiere. Bisher nutze ich an gleicher Speicherstelle dazu verschieden Programm-Exe-Dateien, so dass die einen die alte Version nutzzen, und der Betreffende dann die neue. Das ist allerdings eine Krücke hoch 10.

Vielen Dank im voraus für Infos.

Liebe Grüße

Gunther Troost


Moderiert von Narses: Topic aus Sonstiges (Delphi) verschoben am Mi 11.03.2015 um 10:48

baumina - Mi 11.03.15 09:19

---

Das Problem kenn ich hier leider nur zu gut, alle behaupten aus dem Programm draußen zu sein, aber einer hängt trotzdem immer drin und der ist schwer ausfindig zu machen. Ich habe zusätzlich noch ein Phänomen, dass ich auf einem Windows2000-Server die exe ersetzen kann, obwohl ein Benutzer im Programm drin ist und das ist dann echt fatal, denn dieser Benutzer kann das Programm dann nicht mehr wirklich benutzen, beenden lässt es sich meist auch nicht mehr, außer über Taskmanager, weil Windows dann wahrscheinlich komplett irritiert ist. Tja, das ist Windows.

Gerd Kayser - Mi 11.03.15 09:34

---

1. AktuellesProgramm.EXE umbenennen in z. B. AltesProgramm.EXE
2. Neue Version als AktuellesProgramm.EXE bereitstellen

jasocul - Mi 11.03.15 09:37

---

Entweder früh aufstehen und das Update machen, bevor ein User im System ist oder spät Feierabend machen und warten, bis alle User sich abgemeldet haben.
Windows ist nun mal so.
Auch die Lösung von Gerd Kayser kann zu Problemen führen, wie ich aus Erfahrung weiß. Funktioniert aber meistens.

Nersgatt - Mi 11.03.15 09:56

---

Ich mach es auch so, dass ich vorher die Datei umbenenne. Das geht auch, wenn sie ein Benutzer noch geöffnet hat.

Auch da gibt es Fallstricke. Erst gestern. Abends um 19 Uhr will man "noch eben" das Update installieren. Gemacht wie immer. Beim Programmstart allerdings festgestellt, dass noch die alte Programmversion gestartet wird. Grübel - der Build war doch problemlos durchgelaufen. Dateiversion passt auch. Komische Sache, trotzdem wird die alte Version weiterhin gestartet, obwohl ich zu 100% weiß, dass nur die Neue auf dem Server liegt.

Des Rätsels Lösung: mein Programm wird auch von ein paar externen Benutzern über einen Terminalserver verwendet. Die haben sich - wie immer :roll: - nicht abgemeldet, sondern nur das Remote Desktop-Fenster geschlossen. Ich vermute einer der Benutzer hatte die EXE noch offen. Und da ich auch über den Terminalserver zugreife, hat der die alte Exe noch gestartet.
Nachdem ich die beiden Benutzer nicht abgemeldeten Benutzer rausgeworfen hatte, funktionierte es dann. Und schwupps, war es 20:15 Uhr und die Tagesschau verpasst. :bawling:

Tranx - Mi 11.03.15 11:45

---

jasocul hat folgendes geschrieben :

Entweder früh aufstehen und das Update machen, bevor ein User im System ist oder spät Feierabend machen und warten, bis alle User sich abgemeldet haben. Windows ist nun mal so. Auch die Lösung von Gerd Kayser kann zu Problemen führen, wie ich aus Erfahrung weiß. Funktioniert aber meistens.

Das mache ich normalerweise auch. Ich bin immer der Erste in der Firma. Aber manchmal muss man einen Bug in einem Programmbereich beseitigen, den nur ein User nutzt. Das ist dann nervig, wenn ich deswegen immer alle User abmelden lassen muss. Aber wahrscheinlci hwerde ich wegen Windows da nichts machen können. Versteh das Ganze allerdings nicht so ganz. Was macht denn Windows mit der Datei, wenn sie als Programm in Benutzung ist? Werden da doch irgendwelche Daten in den Code geschrieben (z.B. beim Start, beim Benutzen, oder beim Verlassen)?

Moderiert von Narses: Beiträge zusammengefasst

Gerd Kayser hat folgendes geschrieben :

1. AktuellesProgramm.EXE umbenennen in z. B. AltesProgramm.EXE 2. Neue Version als AktuellesProgramm.EXE bereitstellen

Das verstehe ich nicht. Das hat bisher nie funktioniert, weil Windows da gemeckert hat. Aber Du hast Recht, das ist der Weg.

Narses - Mi 11.03.15 11:51

---

Moin!

Es gibt noch den Ansatz: lokaler Cache. :idea: Starte die EXE nicht direkt aus der Freigabe, sondern lege da einen Bootloader hin, der kopiert die EXE irgendwo lokal auf die Maschine und startet sie dann (klar, nur kopieren, wenn neuer, blah blub...). Dann ist kein Handle auf der Datei im Share. :nixweiss:

cu
Narses

Tranx - Mi 11.03.15 12:12

---

Narses hat folgendes geschrieben :

Moin! Es gibt noch den Ansatz: lokaler Cache. :idea: Starte die EXE nicht direkt aus der Freigabe, sondern lege da einen Bootloader hin, der kopiert die EXE irgendwo lokal auf die Maschine und startet sie dann (klar, nur kopieren, wenn neuer, blah blub...). Dann ist kein Handle auf der Datei im Share. :nixweiss: cu Narses

Dann funktionieren aber Dateizugriffe nicht mehr so, wie gehabt, weil in der Datei der Programmpfad für Dateizugriffe abgefragt wird. Zusätzliche Dateien müsste ich dann ebenfalls lokal kopieren, das macht aber wenigh Sinn. Die Datenbanken werden mit absolutem Pfad abgefragt, die wären nicht betroffen.

Narses - Mi 11.03.15 13:05

---

Moin!

Tranx hat folgendes geschrieben :

Dann funktionieren aber Dateizugriffe nicht mehr so, wie gehabt, weil in der Datei der Programmpfad für Dateizugriffe abgefragt wird.

Du möchtest mir doch jetzt nicht als gestandener Delphi-Entwickler dieses Detail als "Problem" verkaufen, oder? :zwinker: Das kann man alles sicher elegant lösen, ohne weitere Dateien lokal abzulegen (wenn man das nicht möchte). :nixweiss: (z.B. könnte der Bootloader seinen Programmpfad als Parameter an die EXE weiterreichen :idea:)

Abgesehen davon: es ist nur ein Lösungsansatzvorschlag. :idea: :beer:

cu
Narses