Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Automatisiertes Updaten von Frontends in einem Netzwerk, wie?

Begonnen von Blümeli, Dezember 01, 2019, 20:47:40

⏪ vorheriges - nächstes ⏩

Blümeli

Hallo

Ich habe in einem Netzwerk Frontends (z.B. TEST) , auf vielen Maschinen gespeichert.
Wenn ich die eine Frontend ändern möchte, muss ich die neue Version auf vielen Rechnern manuell verbreiten.

Meine Idee war:

TEST-Frontend wird vom Benutzer lokal gestartet.
Prüfen ob es eine neuere Version gibt.
Wenn ja, dann aus der TEST-Frontend eine UPDATE-Frontend starten.
Mit der UPDATE-Frontend die TEST-Frontend schließen.
Mit der UPDATE-Frontend die TEST-Frontend löschen und die neue Version vom Server holen und lokal speichern.
Mit der UPDATE-Frontend die neue TEST-Frontend öffnen.

Damit hätte ich eine automatisierte Verbreitung von aktualisierten Frontends.

Probleme:
Wenn ich die UPDATE-Frontend aus der TEST-Frontend starte, kann ich die TEST-Frontend nicht beenden.

Ich habe versucht die Update mit   Applicaton.Followhyperlink zu starten, geht nicht, da die ausführende Instanz wartet bis die UPDATE fertig ist.

Application.FollowHyperlink "C:\BOSSDBC\BOSS_Update.accdb"
DoCmd.Quit

Gibt es Ideen wie eine Automatisierung von Updates von Frontends funktionieren könnte?

DF6GL

Hallo,

warum so kompliziert?

Lege das (Master-)FE auf ein Serververzeichnis, auf das alle User Zugriff haben.

Jeder User erhält einen Link auf eine CMD-Datei, die das Master-FE in den vorgesehene lokale FE kopiert (und überschreibt). Anschließend startet die CMD-Datei das lokale FE.


Die CMD-Datei kann auch eine VBS-Datei sein, die direkt ausgeführt werden kann.



Beaker s.a.

@Blümeli
Hier findest du ein Beispiel: https://www.ms-office-forum.net/forum/showthread.php?t=333912
Und mit dem AddIn in der Anlage kannst du ein .vbs-Script erstellen, das diese
Aufgabe übernimmt.
gruss ekkehard
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

Blümeli

@DF6GL Danke für den Vorschlag. Das Problem ist, dass ich dann vom User abhängig bin, ob der den Link auch wirklich startet. Um das zu verhindern könnte ich in den aufrufenden Windows-Button eine Batch.Datei hinterlegen, die das UPDATE Programm startet anstelle der Frontend. Das Update Programm würde dann nach erfolgreichem Update den Befehl zum Start des Update-Programms aus der Batch wieder heraus schneiden.

@Beaker s.a.  Danke für den Link. Die darin hinterlegte Datenbank ist fast identisch mit dem was ich bisher geschrieben habe. In meiner Access2010 Version funktioniert diese auch so wie es sein soll. Ich habe aber schamvoll verschwiegen, dass ich (aus komplizierten Gründen) vermutlich der Letzte bin, der Access97 programmiert (letzmalig, ich bin soeben in der Konversion auf Access 2010++). Ich brauche ein paar Tage bis ich das in 97 zum Laufen gebracht habt.

Momentan ist es so, dass die aufrufende Frontend das Updateprogramm startet mit (wie im Beispiel):

AppActivate Shell("MSACCESS.EXE " & "C:\BOSSDBC\BOSS_Update.mdb", vbNormalFocus)
Application.Quit

Wenn ich in der UPDATE die zu ersetztende FRONTEND killen möchte (Kill "path") dann geht das nicht, da die FRONTEND zum KillZeitpunkt noch nicht geschlossen ist.  Ich arbeite da noch dran und melde mich in ein paar Tagen.

Blümeli

So gehts. UPDATE löscht FRONTEND solange bis es funktioniert.

On Error Resume Next
Err.Clear

Do
     Kill (PfadAlt)
Loop While Err.Number = 70

On Error GoTo 0

FileCopy  PfadNeu , PfadAlt

MsgBox ("Update  erfolgreich abgeschlossen. " & PfadAlt & " kann neu gestartet werden.")

Offenbar braucht die primäre FRONTEND einige Zeit bis der Task geschlossen wird. Ich bin jedoch nicht glücklich. OnErrorResume ist nicht wirklich mein Favorite. Ich suche weiter.

ebs17

#5
Ich habe die vorangegangenen Beispiele nicht näher angesehen und weiß jetzt nicht, ob und was da bereits umgesetzt wurde, was ich nachfolgend ausführe.

Gedanken:

- Das Frontend könnte generell neu kopiert werden statt nur bei neuer Version. Dann muss man nicht beim Start vorher darauf zu greifen, ein Warten auf Schließen erübrigt sich. Wen der dabei auftretende Traffic stört, sollte sich vergewissern, was im laufenden Betrieb mit Daten so passiert.
Alternativ könnte man in einer zusätzlichen schlanken Textdatei die Versionsinformation hinterlegen und abfragen.

- Im FE könnte man über ein gesetztes Flag steuern, dass es sich bei False sofort wieder schließt. Schließen des FE => False, Starten mit Starter => True.
So kann man dem User etwas erziehen.

- Als Startprogramm + Updater ein VBScript verwenden. VBScript kann ja sehr vieles auch, was VBA leistet, ist also ein guter Ersatz. Als ausführbare Textdatei ist das auch sehr schlank und muss nicht extra geschlossen werden (kein Zeitverzug).

- Ein Versionen-Ablauf könnte folgender sein: Der VBS-Starter enthält selber als Konstante die Versionsinformation. Beim Ausführen wird eine zentrale version.txt abgefragt. Abhängig wird kopiert oder gleich gestartet. Ein FE mit neuer Version schreibt nach Start die starter.vbs um auf die neue Version (ist ja auch nur eine Textdatei).

- Selbstredend bietet man als Link auf dem Desktop die starter.vbs an, gerne mit einem schönen Anwendungs-Icon.
Mit freundlichem Glück Auf!

Eberhard

Xoar

Hi,

wie schon erwähnt, falls die Rechner immer herunter gefahren werden kann man die batch dabei einfach in den Autostart ziehen, dann kopiert er immer die server frontend Datei.

So hab ich es laufen und das funktioniert super.

Grüße

oliver3370

Hallo zusammen,
hätte eine Batch Lösung anzubieten. Auf einem Fileserver liegt immer die zentrale frisch programmierte Version des Programm Frontends oder der Daten-DB. Beim Start des Systems und wenn die Version auf Server höher als lokal, dann wird die neue Version kopiert.
Die Versionsbatches..... (für Server und Client)
Version_Prog.cmd:
@Echo off
SET Version_Prog=2_2

Version_Daten.cmd:
@Echo off
SET Version_Daten=1_72

Diese beiden Dateien sind auch lokal auf den Rechnern.

Diese Batchdatei auf den Rechnern mit Desktop Icon verlinken....
Start_KuB-Management-System.cmd:
@Echo off
echo ******************************************************************************
echo *AUTOMATISCHES UPDATE SYSTEM    für KuB-Management-System                    *
echo *Dieses Fenster schliesst automatisch, wenn das                              *
echo *Update System korrekt beendet wird.                                         *
echo ******************************************************************************
SET Lokale_Software=C:\KuB-Management-System\
SET Server_Software=Q:\KuB-Management-System\
SET Batch_Prog=Version_Prog.cmd
SET Batch_Daten=Version_Daten.cmd
SET Programmname_Anfang="KuB-ManagementSystem_v_"
SET Datenname_Anfang="KuB-MS_Daten_v_"
echo ******************************************************************************
REM Laufwerk Q Mappen
Net use q: /delete >Nul >Nul
Net use q: \\NAS1B8CA0\Daten\Labor /persistent:No
echo ******************************************************************************
REM Version auf Server auslesen
call "%Server_Software%%Batch_Prog%"
call "%Server_Software%%Batch_Daten%"

REM Merken in interne Variablen
SET Version_Prog_Server=%Version_Prog%
SET Version_Daten_Server=%Version_Daten%

echo Auf dem Server ist fuer das Programm die Version %Version_Prog_Server%.
echo Auf dem Server ist fuer die Daten die Version %Version_Daten_Server%.

REM Version auf Station auslesen
call "%Lokale_Software%%Batch_Prog%"
call "%Lokale_Software%%Batch_Daten%"

echo Auf dem Client ist fuer das Programm die Version %Version_Prog%.
echo Auf dem Client ist fuer die Daten die Version %Version_Daten%.

REM Wenn Programm Version kleiner, dann kopieren
IF %Version_Prog% LSS %Version_Prog_Server% GOTO KOPIERE_PROGRAMM
:WEITER
REM Wenn Programm Version kleiner, dann kopieren
IF %Version_Daten% LSS %Version_Daten_Server% GOTO KOPIERE_DATEN
GOTO EXIT

:KOPIERE_PROGRAMM
echo Programm Version wird kopiert.
COPY "%Server_Software%%Programmname_Anfang%%Version_Prog_Server%.accdb" "%Lokale_Software%"
echo Versionsdateien werden kopiert.
COPY "%Server_Software%%Batch_Prog%" "%Lokale_Software%"
GOTO WEITER

:KOPIERE_DATEN
echo Daten Version wird kopiert.
COPY "%Server_Software%%Datenname_Anfang%%Version_Daten_Server%.mdb" "%Lokale_Software%"
echo Versionsdateien werden kopiert.
COPY "%Server_Software%%Batch_Daten%" "%Lokale_Software%"
GOTO EXIT

:EXIT
REM Version auf Station auslesen
call "%Lokale_Software%%Batch_Prog%"
call "%Lokale_Software%%Batch_Daten%"

REM START Eigentliche Software
"%Lokale_Software%%Programmname_Anfang%%Version_Prog%.accdb"

echo ******************************************************************************

Die Batch Lösung finde ich im Einsatz sehr robust. Und für 97 erst recht geeignet....
Viele Grüße Oliver