Betriebssystemfehler

[henxl]

Hallo,

ich arbeite in einer "DO WHILE"-Scheife eine Datenbank Satz für Satz ab und sichere dabei die Datensatznummer mit nRec:=RECNO(). Später gehe ich die diesem Satz zurück: GO nRec.

Die Routine läuft seit Monaten ohne Fehler. Plötzlich tritt folgender Fehler auf:

Code: Alles auswählen

FEHLERPROTOKOLL     : 14.08.2006 10:23:42
*
Programm            : "C:\Gb\GB.EXE", Version 2.3.11 Build 288
*
Xbase++ Version     : Xbase++ (R) Version 1.90.331
Betriebssystem      : Windows XP 05.01 Build 02600 Service Pack 2
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: N VALUE: 141
oError:canDefault   : J
oError:canRetry     : N
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Betriebsystemfehler
oError:filename     : 
oError:genCode      :         40
oError:operation    : DbGoto
oError:osCode       :          1
oError:severity     :          2
oError:subCode      :          4
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von GB1_RVREAD(1189)
Aufgerufen von GB_BART(1513)
Aufgerufen von BW1_0(417)
Aufgerufen von GB_MENUSELECT(1248)
Aufgerufen von GB_BMPMENUSELECT(1358)
Aufgerufen von (B)GB_BMPMENU(1412)
Aufgerufen von GB_0(602)
Aufgerufen von GB(303)
Aufgerufen von MAIN(37)

Hat jemand eine Idee, was dieser Fehler bedeutet und wodurch er ausgelöst wird ?

Grüße

Heinz

[Gerd König]

Hallo Heinz, das kann alles mögliche sein

PC-Fehler (Speicher, Festplatte)
Netzwerkfehler (Keine Verbindung zum Server)
....

Viele Grüße
Gerd

[henxl]

Hallo Gerd,

um dem Fehler auf die Spur zu kommen, läuft die Anwendung auf einem Pentium 4, 3 GHz, 1 GB RAM, HDD üder 100 GB frei, als Einzelplatzversion, keine Netzverbindungen. Und trotzdem tritt der Fehler gelegentlich auf.

Mir ist klar, dass sich die Laufzeitbedingungen ändern müssen, damit der Fehler auftritt, zBsp. zu wenig Arbeitsspeicher, weil ein anderes Programm ...
Aber aus dem Fehlerprotokoll kann ich nichts Konkretes ableiten.

Vielleicht hat jemand ein ähnliches Problem und weiß Rat ...

Grüße

Heinz

[Tom]

Das kann - leider - auch ein Indexfehler (Korruption) sein, aber die möglichen Ursachen sind vielfältig. Seit der 1.82 reduziert das Fehlersystem fast alles, was mit Indexen zu tun hat, auf Betriebssystemfehler 1, "unzulässige Funktion", und da solche Fehler zumeist nicht nachstellbar sind, hat man große Probleme. In der Regel hilft aber eine Reindexierung der Datenbank. Die ganzen DBFNTX/1012 und Nachbarn habe ich jedenfalls seit der 1.82 nicht mehr gesehen; ich hatte auch diesbezüglich mit Alaska korrespondiert und gehofft, das würde in der 1.9 geändert sein, isses aber nicht.

[Manfred]

Hi Tom,

haben die Alaska Jungs wenigstens erklärt, warum das jetzt so ist?

[Tom]

Hallo, Manfred.

Nö.

[henxl]

Hallo Tom,

vielen Dank für den Hinweis.
An einen Indexfehler habe ich auch schon gedacht.

In vorliegenden Beispiel wurden bereits über 100 Datensätze abgearbeitet. Es wird nur aus der Datenbank gelesen. Bei den ersten 100 Datensätzen war die Indexdatei also in Ordnung.
Und nach dem Neustart läuft die Anwendung mit der selben Indexdatei einwandfrei. Deshalb schließe ich hier einen Indexfehler aus.

Nochmals danke.

Grüße

Heinz

[AUGE_OHR]

hi,

ich arbeite in einer "DO WHILE"-Scheife eine Datenbank Satz für Satz ab und sichere dabei die Datensatznummer mit nRec:=RECNO(). Später gehe ich die diesem Satz zurück: GO nRec.

Die Routine läuft seit Monaten ohne Fehler. Plötzlich tritt folgender Fehler auf:

Code: Alles auswählen

Xbase++ Version     : Xbase++ (R) Version 1.90.331
Betriebssystem      : Windows XP 05.01 Build 02600 Service Pack 2
oError:genCode      :         40
oError:operation    : DbGoto

1.) tritt der "Fehler" erst seit v1.9x auf ?
2.) hat du eine eigene DBESYS ?

DBClose/DbGoto/OrdlistAdd "Fehler" haben meistens was mit dem
"Timeing" zu tun die in der v1.9x "leicht" verändert wurde (meine ich
jedenfalls festgestellt zu haben wärend der beta Phase). Nachdem
ich dann meine "eigene" DBESYS mit "optimierten" Werten benutzt habe
gab es das Problem nicht mehr :

Code: Alles auswählen

  /*
   *   DBF und NTX Database-Engine werden "hidden" geladen
   *   und zu der neuen abstrakten DBFNTX Database-Engine verbunden.
   */
   IF ! DbeLoad( "DBFDBE", .T.)
      Alert( MSG_DBFDBE_NOT_LOADED , {"OK"} )
   ENDIF
   IF ! DbeLoad( "NTXDBE",.T.)
      Alert( MSG_DBFDBE_NOT_LOADED , {"OK"} )
   ENDIF
   IF ! DbeBuild( "DBFNTX", "DBFDBE", "NTXDBE" )
      Alert( MSG_DBFNTX_NOT_CREATED , {"OK"} )
   ENDIF
   // now DBFNTX / NTXDBE is active
   // set some new value
   DbeInfo( COMPONENT_DATA , DBFDBE_LOCKRETRY, 100000 ) 
   DbeInfo( COMPONENT_DATA , DBFDBE_LOCKDELAY,     20 ) 
   DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKRETRY, 100000 )
   DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKDELAY,     20 )

   DbeSetDefault( "DBFNTX" )

gruss by OHR
Jimmy

[henxl]

Hallo Jimmy,

danke für die Antwort.
Ich habe erst seit 2 Wochen auf 1.9 umgestellt. Der Fehler trat vorher auch schon auf.

Hier ein Auszug aus meiner DBESYS (nach Deinem Änderungsvorschlag):

Code: Alles auswählen

  // siehe Alaska News Auge_Ohr 15.11.2005 in BugReport:
  DbeInfo( COMPONENT_DATA , DBFDBE_LOCKRETRY, 20000000 )
  DbeInfo( COMPONENT_DATA , DBFDBE_LOCKDELAY,       10 )
  DbeInfo( COMPONENT_ORDER, DBE_LOCKMODE,LOCKING_EXTENDED) 
  DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKRETRY, 20000000 )
  DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKDELAY,       10 )

Grüße

Heinz

[AUGE_OHR]

hi,

Code: Alles auswählen

  DbeInfo( COMPONENT_ORDER, DBE_LOCKMODE,LOCKING_EXTENDED) 

hat jemand mit LOCKING_EXTENDED gute/schlechte Erfahrung ?

unter welchen Umständen bringt es was ?
(schneinbar nicht unter Novell ...)

gruss by OHR
Jimmy

[Bertram Hansen]

Hallo,

hierzu habe ich auch eine Frage.

Darf ich die neue Einstellung

Code: Alles auswählen

DbeInfo( COMPONENT_ORDER, DBE_LOCKMODE,LOCKING_EXTENDED)

auch verwenden, wenn auf die selben dBase Tabellen mit einem unter Clipper 5.2e erstellten Programm und einem unter xBase++ Version 1.9 erstelltem Programm zugegriffen (schreiben, lesen, Indexfelder verändern, Index erstellen, etc.) wird?

[Tom]

Nein.

[Bertram Hansen]

Danke Tom für die schnelle und kurze Antwort