Xbase++ Programm auf Server - Ermitteln Prozess [ERLEDIGT]

[Wolfgang_B]

Hallo Kollegen,
ich habe ein Xbase++ Programm auf einem WIN-Server installiert. Auf diesen greifen jetzt verschiedene Clients zu. Da ich auf diesen Server nur per Fernwartung zugreifen kann, möchte ich vor einer Änderung von Tabellen sicherstellen, daß keine Instanz des Programms mehr auf einem Client läuft. Hat jemand eine Ahnung, wie ich feststellen kann, daß nur noch meine Fernwartungsinstanz läuft, bzw. wie ich die anderen Instanzen zwangsweise beenden kann.

Gruß
Wolfgang

[Manfred]

Ich lege für die Programme eine eindeutige temp Datei an (schreibgeschützt und stets offen). Anhand derer kann ich sehen, wer wann und wo geöffnet hat. Weiterhin prüft in dem Fall das Programm ob es eine weitere Temp Datei "ähnlichen Namens" existiert (lege ich manuell an wenn benötigt.) und beendet dann nach einem Zeitintervall sich selbst. Sicherlich nur eine einfache Lösung, aber....

[Wolfgang_B]

Hallo Manfred, guter Tipp. ich schreibe ja sowieso jedes Login und Logout in eine Protokolltabelle. Da kann ich ja sehen, wer sich noch nicht ausgeloggt hat. Problem ist nur, wenn das Programm irgendwo abgestürzt ist, dann hab ich natürlich kein Logout. Das wäre meine nächste Frage. Ich kann mit Laufzeitfehlern nicht umgehen. Wie fange ich einen Laufzeitfehler in der Weise ab, daß zumindest noch ein Eintrag in meine Logtabelle geschrieben wird?

Hast Du noch einen Vorschlag, wie man noch laufende Instanzen auf irgendeinem Client von der Ferne abschießen kann?

Gruß Wolfgang

[Jan]

Wolfgang,

Du kannst das in die errorsys schreiben. Problem: Bei einem xppfatal läuft die nicht durch. Und wenn Du nicht aufpasst, dann macht die errorsys mehr Probleme als Dir lieb ist. Aber ich habe selber schon mal sowas gemacht, indem ich die errorsys in eine dbf geschrieben habe. Das funktioniert gut.

Der Weg von Manfred zum abschießen ist, daß das Programm regelmäßig nachsieht, ob die externe Datei existiert. Gibts die, schließt sich das geordnet. Den Intervall kann man sich dann selber einstellen. man könnte das auch erweitern, das man eine zweite Datei mit einem Text anlegt. Und der wird dann angezeigt ("Bitte zu 13:00 Uhr das Programm beenden"). Wer das dann nicht macht, bei dem greift die 1. Datei mit der rigorosen Methode.

Jan

[Tom]

Hallo, Wolfgang.

Wie fange ich einen Laufzeitfehler in der Weise ab, daß zumindest noch ein Eintrag in meine Logtabelle geschrieben wird?

Ein Laufzeitfehler, der (noch) dazu führt, dass das Fehlersystem aufgerufen wird, bedeutet letztlich, dass die Software eigentlich noch läuft. Theoretisch kann man Laufzeitfehler bis zu einem gewissen Grad auch völllig ignorieren, aber man hätte dann eine nicht sehr verlässliche Software.

Wie auch immer. Du kannst die ERRORSYS.PRG manipulieren bzw. anpassen, also in ihr auch Code hinterlegen, der die Logtabelle aktualisiert - vorausgesetzt, das Problem, das gerade aufgetreten ist, betrifft sie nicht direkt (etwa falsche Pfadeinstellungen, Rechtefehler o.ä.).

Ansonsten gibt es ein einfache Mittel, um solche Logtabellen halbwegs aktuell zu halten: Indem sie beispielsweise (in einem gesonderten Thread) offengehalten und auch gesperrt werden; mindestens das Record-Locking geht kurz nach einem Absturz verloren. Etwas eleganter ist es, die Logdatei (wiederum in einem Thread) etwa halbminütlich zu aktualisieren. Jemand, von dem eine Aktualisierung fehlt, ist sehr wahrscheinlich auch nicht mehr im Programm. Ergänzt um die Pflege der Logs in der Fehlerbehandlungsroutine hat man bereits ein recht verlässliches System, das nur bei Abschüssen via Taskmanager oder fatalen Fehlern nicht mehr ganz gültige Daten liefern würde.

[brandelh]

Hi,

ich habe teilweise in meinen Programmen einen eigenen Thread (XbpCRT mit offenen Dateien), der in regelmäßigen Zeitabständen nach einer Datei sucht.
Bei denen die nur ab und zu die Dateien öffnen, erfolgt die Prüfung auf if Admin_Sperre_Aktiv() vor dem Öffnen der Dateien ( also vor Suchdialog, Daten laden oder nach speichern ).
Falls diese gefunden wird, erfolgt entweder ein Hinweis, dass z.B. in 10 Minuten das Programm beendet wird (also sie sollen speichern) oder wenn möglich (keine Dateien offen ...) nur ein kurzer Hinweis und das Programm wird gleich geschlossen. Kommt auf die Dringlichkeit an

Außerdem ist in der Main eine Prüfung auf diese Datei damit die EXE nicht neu gestartet werden kann.

Code: Alles auswählen

PROCEDURE Main ( uTest )
   ... hier muss das Datenverzeichnis ermittelt werden !

   #ifndef DEBUG
      if ! IsAdminSperre(.t.)  // dies ist ein XbpCRT Programm !
         SetTimerEvent( 6000 , {|| IsAdminSperre() } )  // jede Minute testen 60sec * 100 da 1/100
      endif
   #endif

   ...

   if Admin_Sperre_Aktiv() // dies ist ein GUI Programm, das Dateien nur kurz öffnet 
      InfoBox("Wegen Systemwartung muß das Programm beendet werden."+CRLF+CRLF+"Bei Fragen bitte an ... wenden.")
      AppQuit(.t.)
   endif
   ...

*------------------------------------------------------------- Admin_Sperre_Aktiv() -----------------
function Admin_Sperre_Aktiv()
   if ! file(DatenVerzeichnis()+"\XYZ_STOP.*") // XYZ ist für jedes Programm anders.
      memowrit(DatenVerzeichnis()+"\XYZ_STOP.NEIN",;
               "Wenn diese Datei auf XYZ_STOP.JA umbenannt wird, stopt das Programm !")
   endif
return file(DatenVerzeichnis()+"\XYZ_STOP.JA")

Wenn es nur auf einem Server läuft, musst du halt wissen, ob du einfach abschalten kannst (bzw. die Anwendung sich selbst beenden läßt) oder die Anwender warnen musst.

[AUGE_OHR]

Hat jemand eine Ahnung, wie ich feststellen kann, daß nur noch meine Fernwartungsinstanz läuft, bzw. wie ich die anderen Instanzen zwangsweise beenden kann.

auf dem Server (welche Version?) kannst du doch in der "Verwaltung" unter "freigegebene Ordner" und "geöffnete" Datei "sehen" was los ist.
du kannst, mit entsprechenden Rechten, den Zugriff "terminieren" ... wie die Daten dann aussehen ist eine andere Sache ( deine Application )

wenn du was mit den Clients "vom Server" aus machen willst müsstest du Zugriff auf die Clients haben. da fällt mir nur WMI ein.

bei solchen "externen" Eingriffen muss deine Application darauf reagieren wenn du z.b. mit WM_QUIT arbeitest.
du musst also deine Application so "präparieren" das sie auf "irgendwas reagiert".

in einem Thread könnte man jede Minute versuchen eine DBF im share Mode zu öffnen und gleich wieder schliessen.
Wenn du "die" DBF mit "original" DBU EXCLUSIVE öffnest können die Clients die nicht mehr öffnen ...

[Wolfgang_B]

der Vorschlag von Hubert ist glaub ich für mich am einfachsten. So ein Statement kann man einfach vor eine Suche hängen und einen entsprechenden Hinweis anzeigen. Mit Threats muß ich mich erst mal intensiver berfassen.

Das Problem ist aber eher das, daß ich nachts ein Programmupdate machen will, aber irgend ein Client hat das Programm noch laufen, sodaß ich die Programmdatei nicht überschreiben kann. Eine Möglichkeit wäre natürlich, auf jedem Client z.B. Teamviewer zu installieren, dann käme man ja an die Clients dran. Ist aber nicht überall zu verargumentieren ...

Noch eine Frage zur ERRORSYS.PRG. Wenn ich die ins Programm mit einbinde, wird die bei jedem Laufzeitfehler aufgerufen oder muß ich da noch was drumrum programmieren?

Aber schon mal Danke für Eure Kommentare!!

Gruß Wolfgang

[UliTs]

...Das Problem ist aber eher das, daß ich nachts ein Programmupdate machen will, aber irgend ein Client hat das Programm noch laufen, sodaß ich die Programmdatei nicht überschreiben kann...

Ich habe das so gelöst, dass ich immer mehrere Exe habe: Programm1.exe,Programm2.exe,Programm3.exe.
Die Anwender starten dann immer ein Programm.exe, welches die einzige Aufgabe hat zu prüfen, welches der Programm1.exe, Programm2.exe, etc. das neueste Datum hat. Dieses wird dann durch Programm.exe gestartet.
So kann ich jederzeit die Exe -auch im laufenden Betrieb- austauschen.

Uli

[Jan]

Hallo Wolfgang,

wenn Du die errorsys einbindest, wird immer die genommen statt der Standardversion. Der Quellcode der Standardversion liegt ebenfalls in Deiner Installation. Nimm die, kopiere sie in Dein Entwicklungsverzeichnis, und modifiziere sie. Dann hast Du einen guten Start.

Jan

[brandelh]

einfache Anleitung zur Integration:

Die Vorgabe PRG zu den anderen PRG Dateien kopieren
...\XPPW32\source\SYS\ErrorSys.prg
Die Projektdatei anpassen:

Code: Alles auswählen

[xxx.EXE]
   ... am Besten am Ende anhängen
   ERRORSYS.PRG

PBUILD /G aufrufen um die Abhängigkeiten aufzulösen.

[Wolfgang_B]

Danke für die Tipps, muß ich jetzt der Reihe nach mal ausprobieren.
Viele Grüße
Wolfgang

[brandelh]

Angenommen du willst, dass die Software automatisch um 21:00 beendet wird und es ist eine GUI Anwendung (mit einem Thread), dann wäre das der einfachste Weg:

In der Eventloop():

Code: Alles auswählen

nEvent := xbe_None 
DO WHILE nEvent <> xbeP_Close    // Ereignis xbeP_Close ab 
      nEvent := AppEvent( @mp1, @mp2, @oXbp ) 
      if seconds() > 75600 .or. < seconds() < 18000 // Ende um 21 * 3600 + 00 * 60 , kein Start vor 5 * 3600
         quit()
      endif
      oXbp:handleEvent( nEvent, mp1, mp2 ) 
ENDDO 

So könnte man ein Wartungsfenster freihalten.

[AUGE_OHR]

In der Eventloop():

Code: Alles auswählen

      nEvent := AppEvent( @mp1, @mp2, @oXbp ) 
      if seconds() > 75600 .or. < seconds() < 18000 // Ende um 21 * 3600 + 00 * 60 , kein Start vor 5 * 3600

klar kann man das "so" manchen und "Hard-coden" , aber warum nicht den 4th Parameter von AppEvent() nutzen ?
gerade wenn ein User "nichts tut" benötigst du ein "Timeout" damit deine Application was macht sonst wird die Abfrage nie erreicht.

auf das gemeinsame "Daten" Verzeichniss haben die Clients "auf dem Server" ja Zugriff.
Wenn ich also "auf dem Server" arbeite kann ich die "SERVICE.DBF" Exclusiv öffnen
und damit den Client "mitteilen" das die beim "timeout" die Anwendung verlassen sollen.

[brandelh]

Mit dem 4. Parameter hast du natürlich recht, ohne wird sonst die Funktion AppEvent() bei "Ruhe" nicht beendet und somit das Programm am Leben gelassen ...

[Wolfgang_B]

Hallo,
ich hab mit dem 4. Parameter mal experimentiert. Mit mäßigem Erfolg. Mal beendet sich das Programm, mal nicht ... Mir ist nicht ganz klar geworden, wie ich nach der Zeit <TimeOut> * 0.01 lt. Handbauch das Programm beenden kann. Wenn noch ein Fenster z.B. für eine Eingabe offen ist, ist doch eine zweite Eventschleife aktiv?! Wahrscheinlich habe ich auch die Eventschleife noch nicht verstanden.

Bitte nicht lachen

Code: Alles auswählen

DO WHILE .T.
    nEvent := AppEvent( @mp1, @mp2, @oXbp, 1000 )
    IF nEvent = 0
      AppQuit()
    ENDIF
    oXbp:handleEvent( nEvent, mp1, mp2 )
  ENDDO

Gruß Wolfgang

[AUGE_OHR]

ich hab mit dem 4. Parameter mal experimentiert...

Wird für <nTimeOut> ein Wert größer als 0 angegeben, gibt die Funktion spätestens nach Ablauf dieses Zeitintervalls einen Ereigniscode zurück. Falls innerhalb dieser Zeitspanne kein Ereignis eingetreten ist, wird xbe_None zurückgegeben und alle per Referenz übergebenen Parameter haben den Wert NIL.

du musst also, wenn du den 4th Parameter verwendest, als erstes den

Code: Alles auswählen

      DO WHILE !lExit
         nEvent := AppEvent( @mp1, @mp2, @oXbp, nTimeout) 
         DO CASE
              CASE nEvent  = xbe_None
                 // Aktion bei "kein Ereigniss"

              CASE nEvent  = xbeP_Quit
                 ...

xbe_None prüfen ... und nicht mit der Maus rumspielen

[Werner_Bayern]

Ich habe das so gelöst, dass ich immer mehrere Exe habe: Programm1.exe,Programm2.exe,Programm3.exe.
Die Anwender starten dann immer ein Programm.exe, welches die einzige Aufgabe hat zu prüfen, welches der Programm1.exe, Programm2.exe, etc. das neueste Datum hat. Dieses wird dann durch Programm.exe gestartet.
So kann ich jederzeit die Exe -auch im laufenden Betrieb- austauschen.Uli

Geile Idee! =D>

Bleibt nur noch das Problem der DLL-Updates.

[UliTs]

Bleibt nur noch das Problem der DLL-Updates.

Du kannst zusätzlich ein oder mehrere Unterverzeichnisse anlegen, in denen die Exe mit zugehörigen DLLs liegen.
Uli

[Werner_Bayern]

Danke.

Im Hinblick auf PDR 6289 hab ich mich für die lokale Version entschieden. Programm wird wie bisher vom Netzlaufwerk gestartet, schaut, ob es lokal läuft, wenn nicht, kopiert es sich selbst und alle DLLs lokal und startet sich von dort. Damit ist die Update-Problematik auch erschlagen, weil die App auf dem Netzlaufwerk nie wirklich in Benutzung sein und der PDR mit den XPPFATAL-Abstürzen nicht mehr auftreten dürfte.

[brandelh]

DLL-Update ... hatten wir schon

1. aktuelle DLL umbenennen, das geht auch bei offenen und da jedes laufende Programm über den (unveränderten) handle zugreift, geht das.
2. neue DLL installieren
3. beim nächsten Programmstart wird die neue gestartet.

[Werner_Bayern]

Danke Hubert, das war mir neu.

[brandelh]

Ich habe vor Jahren einen "Internetupdate" für eines meiner Programme geschrieben, da muss man das so machen

[Werner_Bayern]

Hätte es gerade probiert, aber eine DLL, die auf einem 2008er Server in Benutzung ist, lässt sich nicht umbennen.

Die Aktion kann nicht abgeschlossen werden, da die Datei in einem anderen Programm geöffnet ist.

[Tom]

Nicht ganz ungefährlich ist diese Vorgehensweise auch, wenn DLLs dynamisch geladen und/oder wieder entladen werden, oder wenn DLLs einander aufrufen, was bei komplexen Tools wie Reportgeneratoren, aber auch Zusatzprodukten wie eXpress++ der Fall sein kann. Aus diesem Grund werden bei uns die Namen aller ausführbaren Dateien in dieser Updatevariante mit einem vorangestellten Unterstrich "_" versehen. Beim Programmstart - bevor also irgendwas über die Standards hinaus geladen wird - prüfen wir, ob solche Dateien vorliegen, benennen dann um (alte Versionen bekommen "$" als Präfix), löschen im Erfolgsfall die alten Dateien und starten das Programm neu. Windows macht das mit seinen eigenen Updates übrigens ganz ähnlich.