Absturz in Sequence-Block

[Jan]

Ich bin gerade etwas irritiert. Ich habe diesen Block:

Code: Alles auswählen

bOldError := ErrorBlock( {|e| MyDbSeekErrorblock(e, @lExit)})

DO WHILE .T.
   BEGIN SEQUENCE
   lReturn := DbSeek(cSuchbegriff, lSoftSeek, cSuchIndex)

   // PDR 5022 abfangen
     IF "CDX" $ DbeSetDefault()
        IF ValType(cSuchbegriff) == "C" .AND. cSuchbegriff == ""   // nicht empty()!!!
           DbGoTop()
           DbSetFound(.T.)
           lReturn := .T.
        ENDIF
     ENDIF

    RECOVER USING bOldError
     lReturn := NIL
     nRetry ++
   END SEQUENCE
   ErrorBlock(bOldError)

   IF ValType(lReturn) <> "U"
      EXIT

    ELSEIF lExit == .T.
      lReturn := .F.
      EXIT

    ELSEIF nRetry > 10
      lReturn := .F.
      EXIT
   ENDIF

   Sleep(10)
ENDDO

und der stürzt mit einer Fehlermeldung auf der DbSeek-Zeile ganz am Anfang ab. Gibt mir einen Base/4 Betriebssystemfehler 1. Mal ganz abgesehen davon das ich mich frage, warum ein DbSeek() einen Betriebssystemfehler auslösen kann - warum gibt das überhaupt einen Laufzeitfehler? Dafür hab ich doch extra die Sequence-Schleife drumrum gebaut. Oder hab ich da einen Denkfehler drin?

Jan

[Martin Altmann]

Moin Jan,
wenn es die Indexdatei nicht gibt oder sie nicht für den User oder in dem Moment zugreifbar ist: Was soll es anderes geben als einen Betriebssystemfehler?

Viele Grüße,
Martin

[Tom]

OS-Fehler 1 (unzulässige Funktion) verweist in aller Regel auf eine Indexkorruption. Vor 1.9 waren die Fehlermeldungen in diesem Zusammenhang dezidierter.

[Jan]

Hallo Ihr beiden,

mir geht es jetzt im Moment nicht um den Betriebssystemfehler. Sondern darum, warum ich trotz Sequence-Schleife einen Laufzeitfehler bekomme. Ob ich da einen Umsetzungsfehler drin habe. Oder sonstwas.

Das mit dem Betriebssystemfehler liegt vermutlich an den nächtlichen Backups, wo kurzzeitig die Dateien aus dem Zugriff genommen werden.

Jan

[Martin Altmann]

Moin Jan,

mir geht es jetzt im Moment nicht um den Betriebssystemfehler...

das las sich hier aber noch anders:

Mal ganz abgesehen davon das ich mich frage, warum ein DbSeek() einen Betriebssystemfehler auslösen kann...

Die Ursache dafür hast Du ja in Deinem letzten Post genannt:

Das mit dem Betriebssystemfehler liegt vermutlich an den nächtlichen Backups, wo kurzzeitig die Dateien aus dem Zugriff genommen werden.

Das vermutlich kannst Du getrost streichen

Viele Grüße,
Martin

[brandelh]

Schau mal diese Zeilen an ....

Code: Alles auswählen

bOldError := ErrorBlock( {|e| MyDbSeekErrorblock(e, @lExit)}) // original Fehlerblock speichern 
...
   BEGIN SEQUENCE
...
   RECOVER USING bOldError // RECOVER USING oError !!! bOldError wird hier durch ein Error-Objekt ersetzt !
...
   END SEQUENCE
   ErrorBlock(bOldError)   // EIGENTLICH wieder alten Errorblock setzen, nach Recover ist das aber ein Error-Objekt

außerdem würde ein Fehler im RECOVER Block wieder MyDbSeekErrorBlock() aufrufen ...
hier mal das Beispiel aus der Hilfe:

Code: Alles auswählen

...
bSaveError := ErrorBlock() 
...  
   ErrorBlock( {|e| Break(e)} ) 
...
   BEGIN SEQUENCE 
...
   RECOVER USING oError 
      ErrorBlock( bSaveError ) // normale Fehlerbehandlung einschalten !
...
   END SEQUENCE 
...
   ErrorBlock( bSaveError )  

Ob danach dein Fehler weg ist weiß ich nicht, ich hatte in solchen Situationen (normaler Fehler in eigenem Errorhandler) schon die seltsamsten Meldungen ...

[Tom]

Du restaurierst die Standard-Fehlerbehandlung innerhalb der Sequenz, das ist der Fehler.

Quatsch. Machst Du ja überhaupt nicht, Lesefehler meinerseits.

[brandelh]

und wäre auch keiner, wie man in der Hilfe sehen kann.

[Tom]

Was geschieht in MyDbSeekErrorBlock?

[brandelh]

Nochmal der Hinweis, scheint untergegangen zu sein ...

RECOVER USING bOldError // RECOVER USING oError !!! bOldError wird hier durch ein Error-Objekt ersetzt !

das führt auf jeden Fall zu Problemen sobald ein Feher auftritt !

[Jan]

Code: Alles auswählen

FUNCTION MyDbSeekErrorblock(e, lExit)

DO CASE
   CASE e:genCode == 40 .AND. e:subcode == 4
        IF EoF()
           lExit := .T.
           BREAK(e)
        ENDIF
ENDCASE

RETURN NIL

Jan

[Tom]

Hubert hat recht. Du verwendest die Standardfehlerbehandlung, weil "bOldError" beim Recover eingesetzt wird. Das hier:

Code: Alles auswählen

bOldError := ErrorBlock( {|e| MyDbSeekErrorblock(e, @lExit)})

bedeutet, dass in bOldError der Standard-Errorblock gespeichert wird, während ab sofort als Errorblock "{|e| MyDbSeekErrorblock(e, @lExit)}" verwendet werden soll. Mit

Code: Alles auswählen

RECOVER USING bOldError

legst Du aber fest, dass der in "bOldError" gespeicherte Standard-Errorblock verwendet werden soll.

Tatsächlich müsstest Du das hier tun:

Code: Alles auswählen

bMyError := {|e| MyDbSeekErrorblock(e, @lExit)}
...
RECOVER USING bMyError

Ob das mit dem BREAK in einer aufgerufenen Funktion funktioniert, ist dann noch eine andere Frage.

[brandelh]

Hubert hat recht. Du verwendest die Standardfehlerbehandlung, weil "bOldError" beim Recover eingesetzt wird. Das hier:
...

Code: Alles auswählen

RECOVER USING bOldError

legst Du aber fest, dass der in "bOldError" gespeicherte Standard-Errorblock verwendet werden soll.
Tatsächlich müsstest Du das hier tun:

Code: Alles auswählen

bMyError := {|e| MyDbSeekErrorblock(e, @lExit)}
...
RECOVER USING bMyError

Ob das mit dem BREAK in einer aufgerufenen Funktion funktioniert, ist dann noch eine andere Frage.

nicht ganz richtig

so wie ich die Hilfe verstehe, wird nicht ein CODE-BLOCK als Fehlerbehandlung angeben, sondern der
Name der Variablen festgelegt der das ErrorObjekt von der Fehlerbehandlung bzw. BREAK oError übergeben wird.

Im Fehlerfall wird also der alte Errorhandler mit einem Error-Objekt überschrieben, das kann nicht gut ausgehen

[Tom]

Doch richtig.

Die Funktion Errorblock legt einen neuen Codeblock fest, der ab sofort zur Fehlerbehandlung verwendet werden soll. Ihre Rückgabe ist der bisherige Codeblock für die Fehlerbehandlung. Wenn bis dahin noch nichts daran geschraubt wurde, ist ihr Rückgabeblock also derjenige für die Standard-Fehlerbehandlung. "bOldError" enthält in Jans Beispiel also den Standardblock, aber ab dieser Zeile wird bei Laufzeitfehlern "MyDbSeekDingens" verwendet. RECOVER USING <xVar> legt fest, dass innerhalb der Sequenz im Fehlerfall auf das in "xVar" festgelegte Fehlerobjekt oder einen Codeblock in "xVar" zugegriffen werden soll. Dort hat Jan den in "bOldError" gesicherten Standard-Fehlerblock angegeben.

In der Doku kann man das im Beispiel 2 für BEGIN SEQUENCE sehr schön sehen:

Code: Alles auswählen

bSaveError := ErrorBlock() // in bSaveError die Standard-Fehlerbehandlung speichern
...
BEGIN SEQUENCE
...
ErrorBlock({|e|Break(e)}) // als Fehlerbehandlung festlegen, dass im Fehlerfall ein BREAK ausgeführt werden soll
RECOVER USING oError // oError enthält als ErrorBlock {|e|Break(e)}
...
ErrorBlock(bSaveError) // Standard-Fehlerbehandlung restaurieren
...
END SEQUENCE

Der Block oder das Objekt, der oder das bei RECOVER USING angegeben wird, ist der Ausnahmeblock. Jan hat hier den Standardblock angegeben. Deshalb bekommt er einen ganz normalen Laufzeitfehler; das BREAK in der Funktion wird nicht ausgeführt (die Funktion selbst auch nicht).

[brandelh]

Sorry, aber ihr solltet die Hilfe besser lesen

Ein CodeBlock wird festgelegt (da sind wir uns noch einig) um auf ein Ereignis zu reagieren...

[BREAK [<Expression>]]
<SourceCode>...
[RECOVER [USING <VarName>]]
<SourceCode>...

END [SEQUENCE]

Parameter

<Expression>

Mit der optionalen Anweisung BREAK wird die Ausführung eines Programms in der ersten ausführbaren Programmzeile fortgesetzt, die der Anweisung RECOVER folgt.
Falls RECOVER fehlt, verzweigt das Programm in die erste ausführbare Programmzeile, die der nächsten END SEQUENCE-Anweisung folgt.
Das optionale Argument <Expression> ist ein beliebiger Ausdruck, der der Variablen <VarName> zugewiesen wird, welche mit RECOVER USING spezifiziert wurde.

Also steht hinter RECOVER USING eine Variable, welcher der Ausdruck aus BREAK zugewiesen wird, aus der Fehlerbehandlung wird normalerweise BREAK e aufgerufen, wobei e das Error-Objekt ist...

Code: Alles auswählen

FUNCTION IsDriveReady( cDrive )        // Ist Laufwerk bereit ? 

      LOCAL nReturn   := 0 
      LOCAL cOldDrive := CurDrive()       // Aktuelles Laufwerk merken 
      LOCAL bError    := ErrorBlock( {|e| Break(e) } ) 
      LOCAL oError 
 
      BEGIN SEQUENCE 
 
         CurDrive( cDrive )               // Laufwerk ändern 
         CurDir( cDrive )                 // Verzeichnis abfragen  
 
      RECOVER USING oError                // Fehler ist aufgetreten  oError enthält Fehlerobjekt
 
         IF oError:osCode == DRIVE_NOT_READY  // oError ist ein Fehlerobjekt, kein ErrorHandler !
            nReturn := -1                 // Laufwerk nicht bereit 

         ELSE             
            nReturn := -2                 // Laufwerk nicht vorhanden 
         ENDIF 
  
      ENDSEQUENCE 
 
      ErrorBlock( bError )                // Fehler-Codeblock und      // alte Fehlerbehandlung im CodeBlock bError
      CurDrive( cOldDrive )               // Laufwerk zurücksetzen 
 

   RETURN nReturn 

[Jan]

Hallo Hubert und Tom,

da ich ja die Recover-Rückgabe überhaupt nicht auswerte, kann ich den "using oError" doch einfach weglassen, oder?

Den Code habe ich übrigens vor mehreren Jahren von einem anderen Vereinsmitglied bekommen, als ich mit dem DbSeek() Probleme mit Virenscannern (?) hatte. und das hat auch seitdem keine Probleme mehr damit gegeben.

Jan

[brandelh]

weglassen geht auch

Aber wie man am Alaska Beispiel sieht, im Recover sofort die normale Fehlerbehandlung einschalten, sonst wird die Fehlersuche hart.

[Jan]

Hallo Hubert,

was mich irritiert ist, das in dem übernommenen Code zwei Zeilen aus der Onlinehilfe fehlen:

Gleich als erste Zeile in der Do While-Schleife das "ErrorBlock( {|e| Break(e)} )", und direkt nach dem Recover das "ErrorBlock( bSaveError )".

Wobei das zweite daher kommen kann, das ich ja nach einem Recover garnicht den alten ErrorBlock zurück haben will. Ich will ja die Schleife notfalls mehrfach durchlaufen, und kann in der Zeit nur den neuen gebrauchen. Oder?

Jan

[Jan]

Eine Ergänzung zu dem MyDbSeekErrorblock(): Es gibt da von dem Entwickler einen Kommentar zu:

Code: Alles auswählen

/* Suchen in pysikalisch leerer Datenbank liefert seit dem Hotfix CDXDBE vom 21.09.2010 einen Runtime-Error */
/* dieser Fehler kann lt. Alaska aber auch bei Netzwerk-/Index-/Hibernate-Problemen austreten */

Nun, das mit den Latenzen ist exakt das, was hier das Problem ist.

Jan

[brandelh]

Hallo Hubert,

was mich irritiert ist, das in dem übernommenen Code zwei Zeilen aus der Onlinehilfe fehlen:

Gleich als erste Zeile in der Do While-Schleife das "ErrorBlock( {|e| Break(e)} )", und direkt nach dem Recover das "ErrorBlock( bSaveError )".

Wobei das zweite daher kommen kann, das ich ja nach einem Recover garnicht den alten ErrorBlock zurück haben will. Ich will ja die Schleife notfalls mehrfach durchlaufen, und kann in der Zeit nur den neuen gebrauchen. Oder?

Jan

In dem Beispiel wird in einer Schleife vor dem problematischen Zugriff die Fehlerbehandlung auf den speziellen geändert
und im RECOVER sofort auf den Standard gesetzt (der wird nur einmalig ermittelt) um normale Tippfehler etc. abzufangen.

Ich habe z.B. wegen einem Fehler in einer solchen Situation schon erlebt, dass mein Programm einfach weg war,
ohne XPPERROR.LOG (die wird ja in der Standard Fehlerbehandlung erstellt)
ohne XPPFATAL.LOG oder sonst irgendwas ...
bis ich drauf kam dass ich eine Abfrage in der eigenen Fehlerbehandlung vergessen hatte.

Das Zurückschalten auf den Standarderrorhandler verhindert das

Man kann den eigenen sooft einschalten wie man will, es gilt immer die letzte Zuweisung.

[AUGE_OHR]

Nun, das mit den Latenzen ist exakt das, was hier das Problem ist.

dann würde ich die "Ursache" beheben statt die "Wirkung" abzufangen ...
du hast offensichtlich ein SMB Problem ...

[Jan]

Jimmy,

1) Auf allen "Rechnern" ist der Alaska-SMB2-Patch aufgespielt

2) An den "Latenzen" kann ich "nichts" machen. Nur wegen ein paar querschießenden "Xbase++"-Prorgammen werden die ihr "Backup" nicht beenden.

Soll heißen: Doch, ich muß daran arbeiten, das meine "Programme" mit den "Gegebenheiten" vor Ort klar kommen.

Jan

[brandelh]

Frage, warum kommen deine Programme Nachts mit der Datensicherung in Konflikt ?
Gibt es ein Zeitfenster in dem du einfach die DBFs nicht anfasst ?
etc.

[Jan]

Moin Hubert,

nachts läuft die Datensicherung. Was so auch sinnvoll ist, weil dann eben am wenigsten User im Netz sind - wer malocht schon morgens um halb 2?

Was aber natürlich läuft ist die KNX-Steuerung. Muß sie auch, weil darüber die nächtliche Bewässerung, das Einbruchmeldesystem mit Bewegungsmeldern etc, Strom- und Wasserverbrauch, usw. laufen. Du hast Recht, das man gewisse Dinge einfach abschalten kann für den Backup-Zeitraum. Machen wir mit zwei 7/24-Programmen auch (z. B. den Mailversand). Was in den Bereichen auch den erwünschten Effekt gebracht hat. Aber bei der KNX-Steuerung ist das halt nicht möglich.

Das Problem mit der KNX-Steuerung ist, das die eben nicht nur den Datenstrom ausließt. Sondern die Protokolle in dbf schreibt Und in Abhängigkeit von in einer dbf hinterlegten Regeln eventuell Aktionen durchführen muß wie einen automatisierten Anruf beim Geschäftsführer absetzen, weil irgendwo ein Alarm ausgelöst wurde. Oder ein Fenster im Gewächshaus schließen weil es anfängt zu regnet.

Jan

[Koverhage]

Wie wäre es, wenn Du im betreffenden Zeit die Daten in eine Array speicherst und nach dem "Halt" Zeitraum Deine Datenbanken aktualisierst ?