Softwareverteilung

[MartinHan]

Hallo,

mit meiner Anwendung (Access-FE und MS Sqldb-BE) läuft alles bestens, nur hin un wieder sind kleine Anpassungen notwendig, wie bei jeder Software.
Sind die Anpassungen bei den Daten, sind die schnell mit SSMS behoben und greifen sofort.
Sind die Anpassungen im VBA-Code oder in einem Formular oder Bericht, dann mass auf allen Rechnern, von denen aus mit der DB-gearbeitet wird, eine neue Version der Access Anwendung (nennen wir sie adcdb) eingespielt werden.
Ich habe mir dazu folgende Lösung gebastelt:
Es gibt ein eine separate zentrale Datenbank mit 3 Tabellen: DB-version, DB-User und DB-User-version.
In DB-Version stehen die Versionen von adcdb mit Versionsnummer (aufsteigend) und Datum. DB-user sind die zugelassenen User und in DB-User-Version steht, welche Version welcher User z.Z. nutzt.
Will er mit dem System arbeiten, meldet er sich über eine separate Access-Anwendung an, die prüft, ob der User die aktuelle Version hat. Falls nicht, wird zunächst die aktuelle Version von einem zentralen Laufwerk, auf das alle zugreifen können, in sein lokales Verzeichnis kopiert. Danach erfolgt dann der Aufruf der eigentlichen Anwendung adcdb. Hat er die aktuelle Version, entfällt der Kopierschritt und der Aufruf kann direkt erfolgen.
Das klappt bis jetzt soweit ganz gut...

Es gibt sicher noch andere Ansätze, hat da jemand schon Erfahrung mit? Man kann immer alles verbessern...

Martin

[mmarschner]

Hallo Martin,

ich habe das anders gelöst.

Die Anwender (bis zu 250 User) haben eine Batchdatei auf ihrem Desktop, mit der das aktuelle Frontend bei jedem Start auf den lokalen PC kopiert wird.

Dabei wird ggf. das Verzeichnis für das Frontend angelegt, eine vorhandene DB gelöscht und bei dem Kopiervorgang wird - im Gegensatz zu Deiner Lösung - bei jedem Start ausgeführt, was auch den Vorteil hat, dass bei einer defekten DB auf dem PC diese immer wieder ersetzt wird, was bei Dir ja nicht der Fall ist.

So kann ich im laufenden Betrieb eine Änderung einspielen und teilen den Anwendern nur kurz mit, dass sie die DB neu starten sollen. Das könnte man auch mit einem Flag (setzte ich dann manuell) erledigen, das über einen Timer regelmäßig abgefragt wird und dann bei Bedarf eine Meldung am PC des Mitarbeiters erzeugt, falls dieser in der DB angemeldet, aber nicht am Arbeitsplatz ist.

So mache ich das schon seit mehreren Jahren und habe damit immer gute Erfahrungen gemacht, aber wie Du schon schreibst, gibt es sicher noch viele andere Möglichkeiten.

Michael

[Bitsqueezer]

Hallo Martin,

die Lösung von Michael ist eine gangbare Variante, kann man aber auch ohne Extra-Batchdatei lösen. Ich habe das beispielsweise schon mal so gemacht, daß ich ein Flag in einer SQL Server Tabelle eingebaut habe, das ich als Admin/Developer einfach nur auf 1 setzen muß, um das Starten aller Frontends zu verhindern.

Das Frontend startet, liest als erstes das Flag und meldet dann dem User, daß gerade Änderung/Wartung am Server stattfindet und das Frontend beendet sich dann selbst, entweder durch OK-Button oder durch meine Timer-gesteuerte Messagebox (falls der User partout nicht reagiert).

In diesem Szenario befinden sich alle Frontends nicht lokal auf dem User-Desktop, sondern zentral auf einem Terminalserver mit User-Ordner. Für das Deployment eines neuen Frontends wird die neue Version einfach in jeden Benutzerordner kopiert. Ist ein Frontend noch geöffnet, wartet man in einer Schleife einfach auf die Timer-Messagebox (die auch bei bereits gestarteten Frontends aufpoppt), nach Ablauf der eingestellten Zeit beenden sich alle Frontends auch ohne User an der Tastatur und man kann die Datei überschreiben.

Im Notfall kann man auch die Remoteverwendung am Windows Server deaktivieren, so daß nur noch Admins draufkommen, dann kann man alle Dateien überschreiben.

Der Vorteil des Terminalservers: Der User bekommt sie als RemoteApp eingerichtet (geht ab Windows Server 2008 R2), womit die Anwendung lokal bei ihm so aussieht wie ein lokal gestartetes Access. Es ist lediglich eine Windows-Anmeldung vorgeschaltet, wenn nicht per Domänenanmeldung diese auch hier eh schon gültig ist.

Damit ist die Anwendung maximal schnell, so daß auch eine Remoteverwendung im Homeoffice keinen Unterschied ausmacht. Dazu gehen keine Daten über das Internet, alles bleibt auf den Firmenservern, weil nur Terminal Server und Datenbankserver Daten austauschen.

Darüber hinaus hat man keinen Stress mit lokalen Installationsunterschieden, womit ich in dem Projekt auch noch lange A2010-ADPs auf dem TS weiterbetreiben konnte, was ab A2013 ja nicht mehr ging. Keinen Stress mit irgendwelchen fehlenden DLLs oder falschen Versionen, keinen 32/64Bit-Stress, usw.

Neuer User heißt, neuen Ordner einrichten, Remote-Zugriff freischalten und als RemoteApp-User dieser Anwendung freigeben - fertig.

Maximale Performance, absolute Versionssicherheit, keine Möglichkeit des Users, das Frontend zu kopieren oder abzuändern (war ohnehin immer als ACCDE bzw. ADE deployt).

Ansonsten, wenn man keinen TS hat, ist die Version von Michael sicher im Allgemeinen die praktikabelste.
Ich würde allerdings zu Bedenken geben, daß das nur funktioniert, wenn man keine lokalen Tabellen im Frontend hat, die z.B. individuelle Benutzereinstellungen beinhaltet, die dann jedesmal überschrieben werden.

Gruß

Christian

[mmarschner]

Hallo Christian,

Ich würde allerdings zu Bedenken geben, daß das nur funktioniert, wenn man keine lokalen Tabellen im Frontend hat, die z.B. individuelle Benutzereinstellungen beinhaltet, die dann jedesmal überschrieben werden.

Da hast Du natürlich recht und genau das versuche ich immer zu vermeiden. Lokale Tabellen gibt es wenn, dann nur temporär für z.B. einen Im- oder Export, oder für eine Berechnung.

Und individuelle Benutzereinstellungen brauchte ich zum Glück noch nicht, würde das dann aber ggf. auf dem Backend mit speichern.

Michael