Netzwerk-Unterbrechung

[Jan]

Wenn im Netzwerk die Verbindung zum Laufwerk mit den dbf unterbrochen wird, während eine dbf geöffnet ist, dann stürzt das betreffende Programm ohne jede Rückmeldung ab. Wie kann man sowas am Besten abfangen?

Das Problem ist, das sowas immer mal wieder vorkommt. Die Unterbrechungen sind offensichtlich nicht sehr lang, aber es reicht eben halt doch für den Absturz aus.

Jan

[brandelh]

während eine dbf geöffnet ist, dann stürzt das betreffende Programm ohne jede Rückmeldung ab. Wie kann man sowas am Besten abfangen?

Die EXE liegt auch auf dem Laufwerk, oder local ?
Hast du die Fehlerbehandlung geändert ?

Als wir früher (Win NT mit OS/2 Server) Clipperprogramme auf dem Netzwerk hatten und solche Störungen aufgetreten sind hat die EXE einen (Overlaynachladefehler gemeldet).
Eine fehlende Verbindung zu einer DBF sollte in einem Laufzeitfehler enden, daher meine Frage ob da was geändert wurde und ob die EXE lokal liegt.
Zumindest ein XppFatal.LOG müsste auftreten ... praktisch geprüft habe ich es aber nicht

[Jan]

Hubert,

sowohl dbf als auch exe liegen auf dem Server. Die xppfatal sehe ich nicht, weil die Mitarbeiter in dem exe-Verzeichnis nur Leserechte haben. Da kann also keine xppfatal geschrieben werden. Abgesehen davon - wohin soll der die xppfatal schreiben, wenn die Verbindung zu dem Verzeichnis weg ist?

Aber Du hast natürlich recht: Der Fehler muß nicht an der Unterbrechung zu den dbf liegen, das könnte auch die Unterbrechung zur exe sein.

Jan

[Koverhage]

Normalerweise wird die dann auf dem Desktop gespeichert.

[brandelh]

Ich habe darum gefragt, um sicher zu sein.

Die XppError() könnte man auch z.b. auf das lokale Temporäre Verzeichnis umlegen (dann hättest du zumindest die), vermutlich versucht er XppFatals zu erstellen, was fehl schlägt.
So auch bei WebServer von HostEurope, dort ist das CGI-BIN (mit der EXE) Verzeichnis auch schreibgeschützt und es knallt ohne Nachricht.

Ein modernes Windows sollte eigentlich die EXE und die (statischen) DLLs im lokalen Speicher halten,
dann könnte es gehen wenn man das aktuelle Verzeichnis auf ein lokales (Anwender Temp) Verzeichnis umlegt.

Falls ein XppError.LOG dort erzeugt wird, kann man es abfangen, wenn er das gar nicht versucht, sehe ich keine Chance weil die Fehlerstelle tiefer liegt.

Zum Test würde ich eine lokale EXE machen und auf ein Netzlaufwerk zugreifen lassen. Stecker ab und sehen was passiert

[brandelh]

Normalerweise wird die dann auf dem Desktop gespeichert.

das wäre mir neu !

Ich kenne nur ...

XppFatal.LOG immer im EXE Verzeichnis, nicht veränderbar !
XppError.LOG immer im aktuellen Verzeichnis, das bei mir (Citrix, Web-Anwendung etc.) immer das Daten-Verzeichnis ist.

Die XppError.LOG könnte nur dann auf dem Desktop liegen, wenn über eine Verknüpfung dieses beim Starten als "aktives Verzeichnis" einstellt ist (bzw. von Windows wird).

[Koverhage]

Hubert,

wenn ich die Anwendung starte (über Verknüfung) z.B Ausführen in (das Dataverzeichnis) und dieses auf einem Stick liegt, dieser aber noch nicht eingesteckt ist,
wird die XppError.log auf dem Desktop gespeichert. Habe vermutet das es bei einer Unterbrechung zum Laufwerk auch so ist.
Kann natürlich sein, dass wenn Du eine eigene Routine benutzt, diese prüft ob das Laufwerk verfügbar ist und dann die Log Datei z.B. in das TEMP
Verzeichnis speichert.

[Herbert]

Das Problem ist, das sowas immer mal wieder vorkommt. Die Unterbrechungen sind offensichtlich nicht sehr lang, aber es reicht eben halt doch für den Absturz aus.

Jan, bist du in einer Citrix-Umgebung?

[Jan]

Herbert,

nein. Das ist Windows 2003 unter VMware und ESXi 5.5. Clients Windows 7.

Jan

[Tom]

Um zur Ausgangsfrage zurückzukommen: Wenn die Netzwerkverbindung unterbrochen wird, weil beispielsweise die Netzwerkkarte einschläft ("Energiespareinstellungen") oder Server oder Client meinen, dass das aufgrund irgendwelcher Timeouts nötig wäre, dann wird das Handle der Tabelle ungültig. Es gibt meines Wissens keine Bordmethoden, um ein ungültiges Handle durch ein gültiges zu ersetzen. Da man auch nicht an die Zugriffsschicht kommt, lässt sich das Problem nicht dadurch lösen, dass man die Tabelle einfach abermals öffnet; Handle und alle Pointer bleiben ungültig.
Wir melden in dieser Situation (Fehler wird in der Errorsys erkannt), dass die Netzwerkverbindung unterbrochen wurde und beenden das Programm. Zur Vorbeugung gibt es in der DBF-Version die Möglichkeit, ein regelmäßiges Anpingen des Servers einzuschalten, außerdem verweisen wir auf die üblichen Ursachen. In ADS-Versionen gibt es das Problem nicht, weil da keine Handles verwaltet werden.

Und übrigens liegt die XppError.log, wenn ich sie denn überhaupt erzeugen will, da, wo ich möchte. Nur die XppFatal kann man nicht steuern; PDR 5154 ist immer noch offen:
http://www.alaska-software.com/scripts/ ... PDRID=5154

[Jan]

Hallo Tom,

nach den Erklärungen leuchtet das ein. Da wir ohnehin gerade am Arbeiten sind, das auf ADS rüber zu schieben, sollte das dann hoffentlich besser laufen.

Bei dem PDR hab ich gerade mal die Priority increased. mal sehen, ob das was hilft. Man darf ja wohl noch träumen ...

Jan

[Koverhage]

Wenn ich das Datum sehe, habe ich relativ wenig Hoffnung,
obwohl die Lösung eigentlich relativ einfach sein dürfte.
Entweder per #define oder im User Ordner, etc.
Per #define wäre natürlich schicker

[Tom]

Das ist Stochern im Trüben. Die XppFatals enthalten ja nur sehr wenige Informationen, und es ist wahrscheinlich, dass sie an mehr Informationen nicht (mehr) herankämen, weil das gesamte System instabil und eben nicht mehr zuverlässig ist. Also wird ein Low-Level-Schreiben ausgelöst, genau dort, wo man gerade ist, nämlich im Arbeitsverzeichnis der Anwendung. Wäre das so leicht zu ändern, wäre das vermutlich längst passiert.

[Koverhage]

Natürlich wenn die ganze Kiste abschmiert, aber dann wird keine geschrieben.
Wenn die exe auf dem Netzlaufwerk liegt und die Verbindung unterbrochen ist, kann
die ja auch nicht geschrieben werden.
Lokal im User Ordner oder selbst gewählten lokaler Ordner macht eigentlich (meiner Meinung nach)
am meisten Sinn, es gibt ja auch XPPFATAL Fehler die nur einen Rechner betreffen.

[Tom]

Wenn die exe auf dem Netzlaufwerk liegt und die Verbindung unterbrochen ist, kann die ja auch nicht geschrieben werden.

Oder wenn Sie - windowskonform - im "Programme" bzw. "Program Files" liegt/ausgeführt wird, wo es grundsätzlich für "einfache Anwender" keine Schreibrechte geben dürfte.

Das Problem ist ja bekannt. Wie gesagt, wenn es so einfach zu lösen wäre, gäbe es diese Lösung wahrscheinlich längst.

[brandelh]

Ich habe hier im PEER Netz und mit USB Stick einige Tests gefahren, zunächst das Testprogramm:

Code: Alles auswählen

#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"
#include "Inkey.ch"

procedure main()
   local cWahl := " ", aStru := {{ "T1","C",40,0 },{ "N2","n",10,0 }}, cDBF, x
   @ 1,1 say "DBF auf USB=1 oder NETZ=2 wähle" get cWahl picture "!" VALID cWahl $ " 12"
   read
   if lastkey()=27 .or. empty(cWahl)
      quit
   endif

   do case

      case cWahl = "1"
        @ 3,2 say "USB Datei erstellen, öffnen und anzeigen"
        cDBF := "f:\test"
        dbcreate( cDBF, aStru )
        use (cDBF) alias DB shared
        if neterr()
           ? "NETERR() :..."
           inkey(10)
           quit
        endif
        index on n2 to (cDBF)

      case cWahl = "2"
        @ 3,2 say "NETZ Datei erstellen, öffnen und anzeigen"
        cDBF := "\\Fsa-dc\temp\Test\Test"
        dbcreate( cDBF, aStru )
        use (cDBF) alias DB shared
        if neterr()
           ? "NETERR() :..."
           inkey(10)
           quit
        endif
        index on n2 to (cDBF)


   end

   if lastrec() < 10000
      if flock()
         for x := 1 to 10000
             dbappend()
             replace T1 with "Zeile "+str(x,10)+"  "+cDBF
             replace N2 with recno()
         next
         unlock
      else
         ? "FLOCK Fehler bei dbAppend() ..."
         inkey(10)
         quit
      endif
   endif

   cls

   go Top

   do while .t.
      sleep(0.01)
      inkey()
      if lastkey()=27
         quit
      endif
      ? n2,t1
      if recno() % 100 = 0
         if dbrlock()
            replace T1 with "changed"
            unlock
         endif
      endif
      skip      // Fehlermeldung ist hier, falls vorhanden.
      if eof()
         go top
      endif
   enddo
return

Testrechner: Win 7 Pro startet die EXE von ...
A. lokaler Festplatte
B. USB Stick (lokal)
C. UNC-Pfad (Win XP Pro Rechner) - hier habe ich das Netzkabel meines Rechners aus dem Switch gezogen wärend das Programm lief !

Die Testdaten liegen ...
1: USB-Stick
2: UNC-Pfad (Win XP Pro Rechner)

Ergebnisse der Kombination ...

A1: wenn der USB Stick gezogen wird, kommt fast sofort eine Fehlermeldung:

Code: Alles auswählen

------------------------------------------------------------------------------
FEHLERPROTOKOLL von "D:\TEST\NetzErr\TEST.EXE" Datum: 16.03.2015 13:26:31

Xbase++ Version     : Xbase++ (R) Version 1.90.355
Betriebssystem      : Windows 7 06.01 Build 07601 Service Pack 1
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: N VALUE: 1
oError:canDefault   : J
oError:canRetry     : N
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Fehler beim Lesen
oError:filename     : 
oError:genCode      :         73
oError:operation    : DbSkip
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :       8999
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von MAIN(75)

B1: gleiche Fehlermeldung (am Bildschirm) wie A1, gefolgt von einer Meldung, das die Fehlerdatei nicht geschrieben werden konnte.

... soweit so gut ...

Bei A2: kam es vereinzelt zu einer Fehlermeldung wie bei A1 (Text identisch), aber meist zu gar keiner !
Das Programm ist einfach weitergelaufen und hat die Zeilen angezeigt, darum habe ich auch das mit den replace bei jedem 100. Satz nachträglich eingebaut, aber es bleibt so.

Bei C2: konnte ich keine Fehlermeldung erzwingen, obwohl Win 7 sofort den Verlust des Netzwerkkabels und des entfernten Rechners anzeigt ... die EXE läuft munter weiter.
Die EXE selbst ist somit wohl voll im Speicher (so groß ist sie ja nicht) und die Daten sind im Cache (welchem auch immer). Es mag sein, dass es mit viel größeren Dateien anders aussieht, aber ich bin irritiert

[brandelh]

Mit einer 360 MB großen DBF, friert das Programm sofort ein und nach einiger Zeit kommt die bekannte Fehlermeldung.
Ich konnte im Verhalten und in der Geschwindigkeit keinen Unterschied feststellen ob nun das NAS oder der PC bzw. UNC oder gemapptes Laufwerk als Netzwerk-Ziel verwendet wird.

- Kleine Dateien werden nicht zuverlässig als fehlend erkannt.
- Bei großen Dateien friert zunächst das Programm ein. Offensichtlich wird auf den TimeOut der Netzwerkverbindung gewartet.
- Nach einigen Sekunden kommt die Fehlermeldung, wenn möglich schreibt er die auf die Platte (aktuelles Verzeichnis).
- Wenn das aktuelle Laufwerk schreibgeschützt ist, kommt noch eine MsgBox() dass die Fehlermeldung nicht gespeichert werden konnte. Dieses Verzeichnis kann man aber ändern.
- XppFatal.LOG habe ich keine gefunden.

Gerade wegen den Timeout ist eine schnelle "Lösung" nicht möglich, zumindest kann man aber erkennen dass etwas schief gelaufen ist.
Eigentlich müsste man nun einen Neuaufbau der Indexdateien erzwingen

[Tom]

Eine XppFatal wäre in dieser Situation auch nicht zu erwarten. Die gibt es schließlich nur, wenn das Fehlersystem versagt, es sich also um eine Fehlerklasse handelt, die darin nicht mehr ausgewertet werden kann, oder wenn im Fehlersystem selbst ein Fehler auftritt (Rekursion, "Error within the error handling"). Eine XppFatal kannst Du also dadurch erzwingen, dass Du z.B. in der Funktion "StandardEH" eine Variable auszuwerten versuchst, die es nicht gibt.

Ich glaube nicht, dass eine Reindexierung erzwungen werden müsste, weil es Korruptionen nur geben kann, wenn zwar das Schreiben in der Tabelle gelingt, aber nicht mehr das Schreiben im Index. In den von Dir gebauten Szenarien versagt beides. Es wäre ein sehr großer Zufall, wenn Du genau den Zeitpunkt zwischendrin erwischen würdest.

Und das richtige(re) Testszenario wäre dies hier: 1. Mehrere Tabellen öffnen, ggf. mit Indexen. 2. Auf einen Datensatz navigieren, Feldinhalte auslesen. 3. Warten (währenddessen Netzwerk- oder Laufwerkverbindung trennen). 4. Zum nächsten Datensatz gehen und Feldinhalte auslesen.

[brandelh]

Ich glaube nicht, dass eine Reindexierung erzwungen werden müsste, weil es Korruptionen nur geben kann, wenn zwar das Schreiben in der Tabelle gelingt, aber nicht mehr das Schreiben im Index. In den von Dir gebauten Szenarien versagt beides. Es wäre ein sehr großer Zufall, wenn Du genau den Zeitpunkt zwischendrin erwischen würdest.

ich habe die Erfahrung gemacht lieber einmal mehr als einmal weniger den Index NEU zu erzeugen, reindex nutze ich nie.
Und wie war das nochmal mit den völlig unwahrscheinlichen Problemen moderner Technik ?

Ich hatte ein Auto mit Turboladerschaden bei 160000 KM, Elektronikprobleme beim Vorgänger ... solche Probleme hatte der Händler (mein Onkel) noch nie erlebt ...

Im Übrigen steht es jedem frei zu testen was immer er will, ich wollte nur prüfen was passiert wenn die Leitung weg ist ... auch nicht an den Haaren herbeigezogen.

Ende der 90 hat ein Bagger unsere Fernverbindung im laufenden Betrieb gekappt ... Mein Clipperprogramm war das das kleinste Übel (nur 2 Anwender),
die 50 Großrechneruser die einige Tage nichts machen konnten ohne unser Hostprogramm hatten mehr Stress (beim Nacharbeiten)

[Tom]

Nutzt überhaupt jemand "Reindex"? Ich meine natürlich die Neuerzeugung.

Im Worst-Case-Scenario könntest Du übrigens auch Korruptionen auf Datensatzebene haben, oder unvollständige/unzuverlässige FAT-Einträge. Eine Neuindexierung wäre dann höchstens Kosmetik.

[AUGE_OHR]

Das ist Windows 2003 unter VMware und ESXi 5.5. Clients Windows 7.

es wundert mich das ihr alle um das Problem herum redet ... die Frage ist doch wieso eine (angebliche) Unterbrechung auftaucht.

Tom hatte ja schon angesprochen das die Netzwerkkarte einschläft ("Energiespareinstellungen") ... schon mal geprüft ?
btw. wie "schnell" verliert der die Verbindung ?
wurde vorher was gemacht ?
bei wie vielen Workstationen tritt das Problem auf ?
wie viele Workstationen waren "online" ?
was sagt das Ereignis-Logbuch des W2K3 Server ?

überhaupt W2K3 : welche Registry Einstellungen hast du vorgenommen ?

[Tom]

Da stimme ich Jimmy zu. Das eigentliche Problem muss eingegrenzt werden. Für eine dateibasierte Datenbankanwendung ist das nahe am WC*, wenn die Netzwerkverbindung - wenn auch nur vorübergehend - getrennt wird und dadurch Handles unwiderruflich ungültig werden. Einfachste Ursache sind tatsächlich die einschlafenden Netzwerkkarten (ich weiß nicht, welche Energie durch diese Option eingespart werden kann, aber wahrscheinlich ist das kaum messbar), andere werden komplizierter. Wenn das geschieht, während eine Anwendung läuft, gibt es innerhalb dieser Anwendung keine Möglichkeit, den Zustand vor der Kappung zu restaurieren. Man kann nur auf den Fehler reagieren, und man kann darauf hoffen, dass nichts kaputtgegangen ist. Das ist glücklicherweise relativ wahrscheinlich, wenn die Energiespareinstellungen oder irgendwelche Verbindungstimeouts zugeschlagen habe, weil das nicht innerhalb einer aufwendigen Transaktion geschehen wird, sondern nur nach einer gewissen Zeit der Untätigkeit.

* worst case

[brandelh]

Die Ursache der Netzwerkstörungen zu beseitigen ist natürlich der wichtigste Schritt.
Die Erkennung dass etwas in diese Richtung schief gegangen ist, ist aber auch wichtig und sei es zu Dokumentationszwecken.
Das Abziehen eines Kabels (ob mit der Hand oder durch den Bagger) ist natürlich schon extrem, aber es kann vorkommen und was haben wir gelernt ?

Murphys Gesetz lautet:
„Whatever can go wrong will go wrong.“
„Alles, was schiefgehen kann, wird auch schiefgehen.“

Im Betrieb hatten wir den Bagger und einen Mitarbeiter der es nicht lassen konnte den RESET Button am Großrechner ab und an mal zu drücken.
Es hat einiges gekostet bis das geklärt und der überführt wurde. Teilweise hatten wir IBM Supportmitarbeiter aus den USA im Hause um dem "seltsamen Abschieren" der 390 auf den Grund zu gehen.
Wahrscheinlicher ist sicherlich eine fehlerhafte Verkabelung (wieso soll man die Kat-Kabel nicht so rollen dürfen ...) oder mit der Zeit verschleißende Netzwerktechnik (läuft doch schon ewig, warum soll da was nicht OK sein ?) oder fehlerhafte Treiber oder Einstellungen ...

Die Auswirkungen von diesen Störungen (DBSKIP() Lesefehler) sollten wenn möglich als Fehler protokolliert werden.
Sonst kann man nicht wissen ob es eine Netzstörung oder ein Programmfehler oder schlichte Fehlbedienung ist.

[brandelh]

Nutzt überhaupt jemand "Reindex"? Ich meine natürlich die Neuerzeugung.
Im Worst-Case-Scenario könntest Du übrigens auch Korruptionen auf Datensatzebene haben, oder unvollständige/unzuverlässige FAT-Einträge. Eine Neuindexierung wäre dann höchstens Kosmetik.

natürlich können auch die DBF Daten als solche nur teilweise oder gar fehlerhaft geschrieben worden sein, bzw. die Daten gerade noch, aber die Kenngrößen im Header nicht mehr.
Meine größten Probleme hatte ich aber immer wegen fehlerhafter Indexdateien, denn ein vermurkster Datensatz (irgendwas sinnloses in den Eingabefeldern) oder ein Laufzeitfehler wegen fehlender Verknüpfung zur Memofeld wird vom Anwender meist sofort als Problem erkannt.

Ein vermeintlich nicht vorhandener Dateieintrag wegen defektem Index ist einfach nicht da ... das fällt Anfangs keinem auf.

Genau dies ist auch der Grund dafür, dass ich bei den geläufigen Dateigrößen gerne auf Indexdateien verzichten würde, oder aber eine DBE die sofort erkennt, dass es ein Index Problem geben könnte.
Sowas gibt es ja, vermutlich mit Zeitstempel bei jedem Schreiben. Leider hat Alaska immer nur an "Kompatibilität" gedacht und nicht eine Xbase++ ONLY but SECURE and FAST Lösung erstellt.

[Herbert]

Das ist Windows 2003 unter VMware und ESXi 5.5. Clients Windows 7.

Was sagt der Netzwerkmonitor? Vmware/esxi merken selber auch nichts?