Programmfehler im Netzwerk mit DBF/NTX Dateien.

[Bernd Reinhardt]

Hallo.
Die Programmabstürze wurden schon öfter diskutiert. Eine allgemeine Lösung habe ich aber noch nicht gefunden.

Ich habe eine Mehrplatzapplikation bei einem Kunden im Netzwerk.
Das Netzwerk wird von Profis betreut und ist schnell und dauerhaft verfügbar. Die Rechner sind alle an der Domain angemeldet. Im Netzwerk konnte ich keinen Fehler erkennen. Ping reagiert auch immer schnell.
Und die erste Mehrplatzanwendung haben wir schon unter Clipper erstellt, so dass mir die prinzipiellen Abläufe schon klar sind.
Aber irgendwas muss doch noch falsch laufen.

Ein Teil der Daten hole ich mir aus dem SQL-Server (mit XBase 1.9 ohne externe Tools), und ein anderer Teil der Daten liegt auf dem Server als DBF/NTX Dateien.

Probleme habe ich beim Schreiben in DBF-Dateien.
Es werden teilweise mehrere Dateien upgedatet und mit close databases
beendet. Das Programm stürzt ab und zu mal ab. Teilweise mehrmals am Tage.
Ich habe auch schon öfter den Index erneuert, hat aber auch nichts bewirkt. Die Indexe sind nicht sehr groß, habe mir schon überlegt vor dem lesen/schreiben immer einen temporären Index lokal zu erstellen. Aber keine Ahnung ob das hilft.

Hier die Fehlermeldung:

------------------------------------------------------------------------------
FEHLERPROTOKOLL von "WAAGE.EXE" Datum: 12.10.06 14:24:46

Xbase++ Version : Xbase++ (R) Version 1.90.331
Betriebssystem : Windows XP 05.01 Build 02600 Service Pack 2
------------------------------------------------------------------------------
oError:args :
oError:canDefault : J
oError:canRetry : N
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Fehler beim Schreiben
oError:filename :
oError:genCode : 74
oError:operation : DbCloseAll
oError:osCode : 0
oError:severity : 2
oError:subCode : 8999
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von DATEN_ABSPEICHERN(1754)
Aufgerufen von VERLADE13_STELLE(1180)
Aufgerufen von FMAINPRG(1101)
Aufgerufen von MAIN(386)


Die Zeiten werden folgendermaßen beim Programmstart gesetzt.

/* zur Vermeidung bei Satzsperre */
DbeInfo( COMPONENT_DATA, DBFDBE_LOCKRETRY, 100000)
DbeInfo( COMPONENT_DATA, DBFDBE_LOCKDELAY, 20)
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKRETRY, 100000)
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKDELAY, 20)

Alle Dateien werden shared geöffnet. Keine Satzsperre kann länger sein als zum Update der Daten benötigt wird. Der Bediener kann im normalen Programmablauf keine Daten ändern.

Also:

Code: Alles auswählen

SELECT PARAME_D
loc_counter := 0
cDbfDatei := "\\servername\freigabe\dbfdateien\parameter.dbf"
cIndexDatei :=  "\\servername\freigabe\dbfdateien\parameter.ntx"
DO WHILE loc_counter++ <= 30
   USE (cDbfDatei) 
   IF !NETERR()
     SET INDEX TO (cIndexDatei)
      GO TOP
      par_lesen()  // datenfelder lesen
      lienr_dl  := LEFT(dp_lienr, LIE_LAENGE)
      REPLACE dp_lienr WITH RIGHT(REPLICATE("0",LIE_LAENGE) + ;
                            ALLTRIM(STR(VAL(dp_lienr) + 1)),;
                            LIE_LAENGE)
       EXIT
   ELSE
      SLEEP(50)
   ENDIF
ENDDO
// Weitere dbf-Dateien ändern
close Databases

Beim Lesen und Schreiben in die SQL-Datenbank fange ich die Fehler mit
Begin Sequence RECOVER ab. Beim Fehler versuche ich es erneut.
Muss ich dies beim Schreiben in dbf-Dateien auch machen?

Oder mache ich hier noch prinzipiell was falsch.

Gruß
Bernd

[Martin Altmann]

Hallo Bernd,
was für Rechner (OS) sind das denn?
Läuft Deine Anwendung z.B. auf einem Terminalserver, der über das Netz auf einen Fileserver zugreift, auf dem die Datenbanken liegen?
Wenn ja, hast Du dann ein Problem: Sobald ein User in seiner Terminalserversession eine geöffnete Datenbank auf dem Fileserver schließt, wird die Verbindung getrennt (da der Fileserver mitbekommen hat, dass der Terminalserver die Datei wieder geschlossen hat) und alle anderen Terminalservernutzer hängen "in der Luft" (nur in Bezug auf die geöffneten DBF-Dateien).

Viele Grüße,
Martin

[AUGE_OHR]

hi,

Und die erste Mehrplatzanwendung haben wir schon unter Clipper erstellt, so dass mir die prinzipiellen Abläufe schon klar sind.
...
Ein Teil der Daten hole ich mir aus dem SQL-Server (mit XBase 1.9 ohne externe Tools), und ein anderer Teil der Daten liegt auf dem Server als DBF/NTX Dateien.

Ich würde mal behaupten das "op´s lock" nicht gesetzt ist. Den braucht
vermutlich dein (M$) SQL Server ...

Das Cl*pper keine Probleme machte ist klar, der kennt kein "op´s lock"

... Probleme habe ich beim Schreiben in DBF-Dateien.
...
oError:description : Fehler beim Schreiben
oError:filename :
oError:genCode : 74
oError:operation : DbCloseAll

sorry aber in der Zeile 1754 steht doch wohl "close Databases" ?!

Das REPLACE wird wohl noch funktioniert haben (leider ohne COMMIT)
aber das "close Databases" = "close all" mag Xbase++ gar nicht ...

immer erst in die "richtige" WorkArea per SELECT() und dann ein
CLOSE ohne Alias() verwenden.

Code: Alles auswählen

SELECT PARAME_D
loc_counter := 0
cDbfDatei := "\\servername\freigabe\dbfdateien\parameter.dbf"
cIndexDatei :=  "\\servername\freigabe\dbfdateien\parameter.ntx"
DO WHILE loc_counter++ <= 30
   USE (cDbfDatei) 
   IF !NETERR()
     SET INDEX TO (cIndexDatei)
      GO TOP
      par_lesen()  // datenfelder lesen
      lienr_dl  := LEFT(dp_lienr, LIE_LAENGE)
      REPLACE dp_lienr WITH RIGHT(REPLICATE("0",LIE_LAENGE) + ;
                            ALLTRIM(STR(VAL(dp_lienr) + 1)),;
                            LIE_LAENGE)
       EXIT
   ELSE
      SLEEP(50)
   ENDIF
ENDDO
// Weitere dbf-Dateien ändern
close Databases

wie schon gesagt würde ich vor dem EXIT ein COMMIT setzten und mir
eine eigene Funktion "CloseDB" schreiben wo man mit WorkSpaceList()
nacheinander die DBF schliesst wobei man vorher evtl. SET RELATION
(einzeln) lösen muss !

gruss by OHR
Jimmy

[Manfred]

Hi Jimmy,

verstehe ich das richtig? Wieso mag Xbase++ ein DbcloseAll() nicht? Ich benutze das die ganze Zeit. Woran merke ich, dass es nicht "erwünscht" ist?

[brandelh]

Läuft Deine Anwendung z.B. auf einem Terminalserver, der über das Netz auf einen Fileserver zugreift, auf dem die Datenbanken liegen?
Wenn ja, hast Du dann ein Problem:

Hallo Martin,

wir haben auch alles über 3 Terminalserver 2000 (mit Citrix) laufen, die die DBFs auf einem Fileserver öffnen und schließen.
Bisher hatte ich nie ein Problem damit.

PS: Ich würde gleich nach dem letzten REPLACE jeder DBF einen COMMIT setzen, bzw. ich nutze sogar dbSkip(0).

[Martin Altmann]

Hallo Hubert,
dann sei froh! So wie ich Steffen damals in Venlo auf der DevCon verstanden habe, gibt es da wohl Probleme.
Aber vielleicht war das dann auch noch eine ältere Version vom Terminalserver...

Viele Grüße,
Martin

[brandelh]

Hi Jimmy,
verstehe ich das richtig? Wieso mag Xbase++ ein DbcloseAll() nicht? Ich benutze das die ganze Zeit. Woran merke ich, dass es nicht "erwünscht" ist?

Hi Manfred,

es ist völlig OK, solange alles glatt geht.

Ab und zu treten beim Speichern unerklärliche Probleme auf
und dann wird versucht Konflikt Situationen zu umgehen.
Vermutlich ist das Problem bei mehreren Threads auch größer.

Wenn du keinen Ärger damit hast, einfach ignorieren.
Ansonsten bringt der explizite CLOSE Befehl in der jeweiligen Select Area dem Rechner mehr zeit die Puffer zu schreiben.

[Bernd Reinhardt]

Hallo.
Alle Rechner WIN XP SP2, Hersteller HP.
OS vom Server kenne ich nicht, glaube aber 2003.
Das Programm läuft lokal, und greift nur auf die dbf-Dateien zu.
Ich mache auch mehrere Workareas auf und schließe dann alle mit
close databases. Das geht normal doch?
Ich kann nach dem Absturz das Programm sofort wieder starten und
es läuft auch.
Die Trennung der offenen dbf-Dateien müsste also dann im Millisekundenbereich sein, und dann aber sofort wieder verfügbar.

Der Absturz bezieht sich nur auf dbf/ntx Dateien.
Relationen sind keine, dies mache ich quasi selbst. Ich öffne eine Datei, suche dann in der anderen Datei nach dem entsprechenden Satz.

Filter sind auch keine gesetzt.

Also nichts was in irgend einer Weise verdächtig wäre.

Gruß
Bernd

[AUGE_OHR]

hi,

verstehe ich das richtig? Wieso mag Xbase++ ein DbcloseAll() nicht?
Ich benutze das die ganze Zeit. Woran merke ich, dass es nicht "erwünscht" ist?

wie hubert schon sagte, solange nichts passiert ...

Probleme kann es geben :
a.) wenn man nicht im "richtigen" SELECT ist
b.) wenn noch eine SET RELATION offen ist
c.) ... meistens das ganze im Netzwerk

Ich benutze seit dem eine eigene Funktion "CloseDB" wobei ich WorkSpaceList() benutze.

gruss by OHR
Jimmy

[AUGE_OHR]

hi,

OS vom Server kenne ich nicht, glaube aber 2003.
Das Programm läuft lokal, und greift nur auf die dbf-Dateien zu.

der Server ist aber auch der SQL-Server ?! "op´s lock" ?

Ich mache auch mehrere Workareas auf und schließe dann alle mit
close databases. Das geht normal doch?

jein, nur unter "optimalen" Bedingungen d.h. mit den für Xbase++
notwendigen gesetzten "op´s lock" Schaltern auf dem W2003 Server.

gruss by OHR
Jimmy

[Tom]

Hallo, Bernd.

Nimm diese Einstellungen:

DbeInfo( COMPONENT_DATA, DBFDBE_LOCKRETRY, 100000)
DbeInfo( COMPONENT_DATA, DBFDBE_LOCKDELAY, 20)

mal raus. Das hat mir jedenfalls der Alaska-Support bei ähnlich gelagerten Problemen empfohlen. Die 1.9 unterstützt das ohnehin nicht, aber es kann erstaunlicherweise trotzdem zu Fehlverhalten führen. Interessant sind nur die Einstellungen für die NTX-Komponente. Die Empfehlung, immer ein Commit einzufügen, halte ich für überflüssig; DbCloseAll() führt das nämlich implizit aus.

[brandelh]

Die Empfehlung, immer ein Commit einzufügen, halte ich für überflüssig; DbCloseAll() führt das nämlich implizit aus.

Der Unterschied könnte sein (woher soll ich das genau wissen ), dass ein sofortiges commit früher ausgeführt wird und somit die Daten auf der Platte sind.

Eigentlich müsste DbCloseAll() völlig ausreichen und einwandfrei funktionieren, genauso wie der Rest von Xbase++ und anderer Software

[Josef]

Nimm diese Einstellungen:
DbeInfo( COMPONENT_DATA, DBFDBE_LOCKRETRY, 100000)
DbeInfo( COMPONENT_DATA, DBFDBE_LOCKDELAY, 20)

Hallo Tom,
diese Einstellungen hab ich auch irgendwann rausgenommen. Warum bei meinem Programm momentan alles gut läuft weiß ich nicht. Liegt es an diesen Einstellungen oder der neuen xBase 1.9 Version. Ich schätze, dass beide "schuld" sind.