Inoffizielles deutsches Xbase-Forum

Hallo,
Derzeit liegen bei mir neben den Daten auch die Programme und Runtime-DLL's auf dem Server und werden dort gestartet.
Ist natürlich relativ einfach für die Updateinstallation.

ab welcher Programmgröße ist ein lokaler Start der Exe sinnvoll?
Wenn lokal, wie updated man diese am besten?

Gruß Stefan

Hi Stefan,
das hängt von mehreren Faktoren ab. Wie schnell ist das Netzwerk? Wie nervös ist der Anwender. Ich habe ein Programm von knapp 30MB Größe mit DLL usw. das starte ich aus dem Netzwerk. Ohne Probleme. Geht recht schnell. Ich mache das auch deshalb sehr gerne, weil es m.E. einfacher zu updaten ist. Aber das ist ja alles Geschmacksache

weil es m.E. einfacher zu updaten ist.

Warum ist das einfacher upzudaten?
Wenn ein Anwender die Applikation noch geöffnet kannst du nix austauschen/updaten.
Und was ist wenn die Applikation abgeschmiert ist und nur noch im Taskmanager "rumhängt"?

Ich mache es schon immer andersrum.
Meine Applikationen haben ein Starter-Programm (welches auf dem File-Server liegt) und als Link auf dem Desktop für den Anwender.
Dieses prüft ob es auf dem Server neue Programm-Dateien (EXE, DLL, Berichte, usw.) gibt.
Wenn ja, kopiert das Starter-Programm diese neuen Dateien ins lokale Programm-Verzeichnis und startet erst dann die lokale EXE.

Hans-Peter,
da hast Du aber reichlich doppelten Netzwerkverkehr beim Ausführen!
Du startest ein Programm, was woanders liegt, um ein Programm zu starten, das lokal liegt - bedeutet, alles was du in deinem eigentlichen Programm machst, läuft über die Verbindung zum Fileserver hin und zurück, bevor es ankommt.

Viele Grüße,
Martin

ich setze bei meinen Programmen ein temporäres File. Anhand dessen kann man feststellen, wer noch im Programm ist und dann entsprechende Maßnahmen ergreifen. Ich muß nur 1 Programm tauschen und alle haben den gleichen Stand. Keine Diskussion mit Usern, die das vergessen haben, oder keine Lust hatten, owwi.
Aber wie schon gesagt, ist alles reine Geschmacksache.

Ich habe früher auf dem Server die EXE (noch zu Clipper Zeiten) abgelegt, die am neuesten war.
Lokale Kopien wurden mit Batch gestartet.
Diese haben eine Datei mit Versionsinfos auf dem Server geladen und wenn die neuer waren, mit errorlevel 2 das Programm beendet.
Die Batch wusste wenn errorlevel 2, dann lade die EXE neu (copy ...).
Danach wurde wieder die EXE gestartet und alles war auf den neuesten Stand.

Hallo Martin !

da hast Du aber reichlich doppelten Netzwerkverkehr beim Ausführen!

Nö.
Die EXE auf dem Server hat 60 kB und neuere Dateien werden nur dann auf den lokalen PC kopiert wenn es neue gibt.
Eine auf einem anderen LW gestartet EXE kopiert doch keine daraus gestartete EXE auf dieses Laufwerk um diese dort zu starten.
Die Applikation(en) liegen immer im Speicher des lokalen PCs.
Wo soll da "reichlich doppelten Netzwerkverkehr" sein

Hallo Stefan

mini990 hat geschrieben: ↑Di, 12. Dez 2017 12:42ab welcher Programmgröße ist ein lokaler Start der Exe sinnvoll?

Aus meiner Sicht - IMMER

mini990 hat geschrieben: ↑Di, 12. Dez 2017 12:42Wenn lokal, wie updated man diese am besten?

Ich lade die neuen Programmdateien auf einen Server und ändere zum Schluss die Build-Nr., genauer gesagt, ich ändere einen Dateinamen. Z.B. heißt die Datei des aktuellen Builds 5678.upd. Die lokalen Kopien mit anderen Builds haben andere UPD-Dateienamen, z.b. 5677.upd.
Beim Start eines meiner lokalen Programme vergleiche ich den lokalen UPD-Dateinamen mit dem im Update-Verzeichnis. Wenn unterschiedlich startet eine BAT welche vom Server zum lokalen Verzeichnis alles rüberkopiert, auch die neue UPD-Datei.

Im laufenden System vergleiche ich das auch immer wieder. Liegt ein Update vor bekommt der User eine Info und das Update startet automatisch.

Da gibt es aber sicher viele Update-Techniken die jeder so im EInsatz hat für lokale Updates...

Bei einem meiner Kunden liegen alle exe auf dem Server. Ob das einen Geschwindigkeitsnachteil beim Start gibt mag sein, ist aber gefühlstechnisch nicht messbar.

Aufgerufen wird dabei immer eine Batch. In der der Name der aktuellen exe-Version liegt. Die werden einfach durchnummeriert, also z. B. wawi12.exe. Sobald es eine neue Version gibt, wird dann die wawi13.exe in das Verzeichnis gelegt und die Batch angepasst. Bei jedem neuen Programmstart wird dann automatisch die aktuellste Version genommen. Bei wichtigsten Korrekturen wird dann eine Rundmail an alle Mitarbeiter geschickt, das die bitte alle offenen Programme schließen sollen, und die neu starten.

Das System ist zwar total primitiv, klappt aber sehr gut.

Problem sind aber die dll. Die kann man ja nicht einfach mal eben so umbenennen im laufenden Betrieb.

Jan

Jan hat geschrieben: ↑Di, 12. Dez 2017 15:33 Problem sind aber die dll. Die kann man ja nicht einfach mal eben so umbenennen im laufenden Betrieb.

Doch umbenennen kann man die schon, auch wenn sie geöffnet sind, denn die EXE ist nicht über den NAMEN verbunden, sondern ein handle.
Ich habe es sicherheitshalber nochmal lokal probiert

1. EXE mit DLL im Verzeichnis wird gestartet.
2. ren *.DLL *._DLL
3. neue DLL kopieren !!!
4. Beim nächsten Start werden die neuen DLL genutzt.

Ich würde sagen es kommt auf das Netzwerk an.
Das Starten der Exe ist auch nicht das Problem, Das Nachladen der DLL's und andere Faktoren
können schon störend sein.
Ich empfehle (wie Roland) das Programm lokal zu halten. Bei mir haben die Anwender die Ihr Programm lokal halten
eine Verknüpfung Update installieren. Der Link zeigt auf eine selbstentpackende EXE auf dem Server.
Auch wenn jetzt viele aufschreien, für mich ist ein Server grundsätzlich zunächst nur für die Daten.

Koverhage hat geschrieben: ↑Di, 12. Dez 2017 15:59..für mich ist ein Server grundsätzlich zunächst nur für die Daten.

genau

@ Roland:
Ich werde das mal so probieren...
Im Prinzip muss alles vollautomatisch laufen.
Meine Anwender bestehen zu 85% aus DAU, zu 10 % aus Super-DAU

Gruß Stefan

Hallo Hans-Peter,

HaPe hat geschrieben: ↑Di, 12. Dez 2017 15:05 Hallo Martin !

da hast Du aber reichlich doppelten Netzwerkverkehr beim Ausführen!

Nö.

Doch - zumindest, wenn du das so machst, wie ich es verstanden habe aus deinen Ausführungen!

HaPe hat geschrieben: ↑Di, 12. Dez 2017 15:05 Die Applikation(en) liegen immer im Speicher des lokalen PCs.
Wo soll da "reichlich doppelten Netzwerkverkehr" sein

Wenn Du von Deinem Rechner (PC) auf ein Laufwerk des Fileservers (FS) zugreifst, um dort ein Programm zu starten, das bei dir lokal auf dem PC nachschaut, ob die eigentliche EXE aktuell ist und sie dann startet, geht es mehrmals durch das Netz!
Du öffnest eine Session vom PC zum FS und startest dort im Kontext des FS ein Programm, das eine Session zu deinem PC öffnet, um darüber eine Datei zu kopieren (sofern notwendig) und dann zu starten. Session hat hier nichts mit Xbase++ zu tun.
Wie zwei getrennte Rohre, die die selben Enden verbinden.

Viele Grüße,
Martin

Koverhage hat geschrieben: ↑Di, 12. Dez 2017 15:59Das Starten der Exe ist auch nicht das Problem, Das Nachladen der DLL's und andere Faktoren können schon störend sein.

ich meine gelesen zu haben das Xbase++ mit v1.9x Probleme mit dem "nachladen" hatte und deshalb bei v2.x eine andere Strategie verwendet wird.

das funktioniert z.b. bei Wifi NICHT denn da kommt es durchaus zu "Unterbrechungen" und wenn die auch nur 10ms sind aber genau "dann" stören.

ich speichere meine Version auf dem Server aber die Clients holen sich die dann per Batch auf die lokale SSD.
... noch besser wäre die RAMdisk aber dazu mache ich einen neuen Thread auf.

p.s. um an einen Server zu kommen muss man sich ja anmelden. der Anmelde Server muss aber nicht der Daten-Server sein wo der User durch die App "angemeldet" wird ...

@Stefan

Das Verfahren verwende ich schon weit über 10 Jahre. Läuft automatisch.
a)
ich kann jederzeit ein Update auf den Kunden-Server laden und auf einzelnen PCs testen. Dazu gibt es in den Programm-Menüs einen mauellen Update-Start.
Läuft alles aktiviere ich abends oder in der Mittagspause das Update für alle - oder der entsprechende Admin macht das.
b)
Wenn man vor dem Transfer der neuen Update-Dateien die vorherigen auf dem Kunden-Server sichert (copy), kann man mit wenigen Handgriffen wieder zurück zur vorherigen Version.
c)
habe auf die selbe Weise die Möglichkeit eine Beta-Version anzubieten. Ausgewählte User können dann mit der Beta-Version arbeiten. Beide Versionen stehen dann Online zur Verfügung.
Da muss man dann aber aufpassen dass man dann selber nicht durcheinander kommt, ich verwende das nicht oft...
d)
Das Ganze funktioniert entweder so, dass ich über VPN die neue Version auf direkt auf den Kundenserver lade, oder ich erstelle eine ZIP, kopiere die auf meinen FTP-Server, der Kunden-Server holt sich die ZIP und aktiviert Netzwerkweit das Update. Oder auch jede Einzelplatz-Applikation welche Internet-Updates bekommt.
Alles automatisch.
e)
Umfang des Updates beliebig - eine Datei bis alle Dateien.
(und weitewre Punkte...)

Hinweise:
- Wenn aus der EXE heraus die Update.bat gestartet wird muss eine kurze Wartezeit eingebaut werden (5-10 Sek.) damit der PC zeit hat die EXE und alle verwendeten DLLs zu entladen. -> sleep.exe 5
- Wenn mehrere meiner Applikationen gleichzeitig laufen werden diese autom. heruntergefahren oder der User bekommt die Info seine Arbeit kurz zu unterbrechen. Das lokale Update wartet dann bis alle meine EXE geschlossen sind.
- Bei zentralen Änderungen an DBFs müssen natürlich alle EXE zugemacht werden. Das lässt sich nur begrenzt automatisieren - aber das wisst Ihr ja alle selbst.

Sollte der User das Update zum ungüstigen Zeitpunkt abbrechen und das EXE startet nicht mehr bibt es eine einfache reparatur.bat und alles läuft wieder

Bei Fragen können wir da schon ins Detail gehen...

Wir haben das damals gemacht, weil die LAN (logisch) eine WAN Verbindung mit 128 KBit war.
Der Update der lokalen EXE (alle paar Monate) führte zu einem verlängerten Frühstück ...
aber die Datenzugriffe auf die DBF auf dem zentralen Server gingen schnell genug, allerdings durften diese Clients,
weder Indexe neu aufbauen noch mit locate die komplette Datei durchsuchen, nur mit limitierendem Index.

Es war Welten besser als der Disketten Update mit lokalen Daten davor (Dubletten ...)

Hallo Martin !

Wenn Du von Deinem Rechner (PC) auf ein Laufwerk des Fileservers (FS) zugreifst, um dort ein Programm zu starten, das bei dir lokal auf dem PC nachschaut, ob die eigentliche EXE aktuell ist und sie dann startet, geht es mehrmals durch das Netz!

Ich habe das mit CommView nachgeprüft ob das so ist.
Ich kann das damit aber nicht feststellen. Zusammen waren es beim Start der Test-Applikation ca. 10 MB Netzwerk-Traffic wobei mein Programm eine Katalog-Datei für die dynamische Feldliste des Cursor-Adapters erstellt. Dieser Cursor hat alleine schon 2 MB.

Wenn es dennoch so sein sollte wie du schreibst, wundert es mich dass ich das Starter-Programm (die EXE) nach dem Start der Applikation löschen/verschieben kann
Das sagt mir dass da bezüglich lokaler EXE nix mehr übers Netz läuft.

Hallo Hans-Peter,
dann wäre es ja gut - nutzt Du keine eigenen DLLs die ggf. bei Bedarf nachgeladen werden müssen?
Dein Starterprogramm startet Deine Anwendung asynchron?

Viele Grüße,
Martin

Hallo Martin !

Dein Starterprogramm startet Deine Anwendung asynchron?

Ja, mittels RUN /N (VFP) was das gleiche ist wie RunShell mit lAsync = .T. (Xbase++)
Das Starter-Programm läuft nach dem Startaufruf der Applikation weiter und beendet sich dann während die Applikation startet ...
Also zwei getrennte eigenständige Prozesse.

Hallo Hans Peter

ich empfehle dir die Programme und alle DLL's im Programmordner (c:\Programme x86) unterzubringen. Und beim Programmstart kannst prüfen ob auf dem Server ein Installationspacket für eine neue Version liegt und dann dieses mit erhöhten Rechten zum Update ausführen. Wenn du Programme aus dem LAN startest wird dies als grobes Sicherheitsproblem betrachtet z.B. bei Zertifzierungen oder ist in vielen Betrieben generell verboten.

Gruss Carlo

ramses hat geschrieben: ↑Mi, 13. Dez 2017 10:22 Wenn du Programme aus dem LAN startest wird dies als grobes Sicherheitsproblem betrachtet z.B. bei Zertifzierungen oder ist in vielen Betrieben generell verboten.

Ich kenne das aber genau gegensätzlich ebenso. Einige meiner Kunden sind ISO-zertifizert und im Zuge der Zertifizerung wurde darauf bestanden, dass die Xbaseprogramme (Lagerverwaltung, Auftragsverwaltung, Fakturierung, Terminverwaltung, Mitarbeiter und Arbeitszeiten) vom Fileserver aus gestartet werden.

Ein schreibgeschütztes Serverlaufwerk ist vom Prinzip her sicherer als ein lokales Laufwerk, da man auf dem Server normalerweise weniger Rechte hat und normalerweise dort keiner mit höheren Rechten arbeitet.
Für die XppFatal.log muss man dann aber intern das aktuelle Verzeichnis auf ein beschreibbares legen, aber das ist bei "richtiger" lokaler Installation ja auch so.

Leon hat geschrieben: ↑Mi, 13. Dez 2017 11:07ISO-zertifizert

Das heißt ja nur, dass die Firma nach festen, weitgehend selbst vorgegebenen Regeln, nachprüfbar arbeitet/organisiert ist. Nicht dass alle ISO-Betriebe nach dem selben Verfahren arbeiten.

Einfache Administration + stärker belastetes Netz => EXE und Co. auf dem Server
Aufwendige Administration - maximale Geschwindigkeit => EXE und Co. lokale PC-Verzeichnisse

Oft sind es auch die Programm-Hersteller welche es sich bei Netzwerkinstallationen einfach machen und den Endkunden eine Installation auf dem Server empfehlen oder das sogar selbst dort einrichten.
(Ich meine damint natürlich nicht uns Xbase-Entwickler).

Habe das gerade erst bei einem Updae erlebt (ca. 50 Plätze). Das Update macht Probleme mit Win 10. Der Hersteller beharrte darauf, die EXE+DLL aus dem Server heraus zu starten, sonst würde das mit Win10 nicht funktionieren

Hallo Leon

ein ISO-Zertifizierung des Arbeitsablaufs z.B. ISO-9000 besagt ja nur dass etwas immer gleich (falsch) gemacht wird und es versucht Fehlerquellen zu vermeiden. Ob dies dann auch "Sicherheitsrichtlinien" berücksichtigt ist eine andere Frage. Ich vermute du hast sicher auch deine Erfahrungen gesammelt.

Aus Sicht der IT-Sicherheit darf/sollte ein Programm nicht vom Netzwerk gestartet werden!
In den Betrieben in denen ich Arbeite ist dies jedenfalls verboten und ist auch ein Punkt des Sicherheitskonzepts.

Gruss Carlo