Datensatzsperre geht verloren?

[Werner_Bayern]

Servus,

was könnte die Ursache sein, dass ein gesperrter Datensatz plötzlich die Sperre verliert?
Wir haben immer die gleiche Vorgehensweise: Ein Satz wird vor dem Editieren gesperrt, dann wird der Dialog angezeigt, jeder Xbase-Part in aEditControls aufgenommen und wenn der Benutzer auf speichern klickt, wird folgende Funktion aufgerufen:

Code: Alles auswählen

static function speicher_formeintrag(aEditControls)
local nControls := len(aEditControls), i, lGeandert := .f.

for i := 1 to nControls
   if aEditControls[i]:changed
      aEditControls[i]:getData()   ==> SPEICHER_FORMEINTRAG(1765)
      aEditControls[i]:changed := .f.
      lGeandert := .t.
   endif
next i

Bei einem Datensatz, wo mehrere Felder geändert wurden, ist das getData beim vorherigen Feld noch ok, dann beim Feld vk_summe knallt es plötzlich:

Xbase++ Version : Xbase++ (R) Version 1.90.355
Betriebssystem : Windows 7 06.01 Build 07601 Service Pack 1
------------------------------------------------------------------------------------------
oError:args :
-> VALTYPE: N VALUE: 0.00
oError:canDefault : N
oError:canRetry : N
oError:canSubstitute: J
oError:cargo : NIL
oError:description : Datei oder Datensatz muß für Operation gesperrt sein
oError:filename :
oError:genCode : 76
oError:operation : <VK_SUMME>:=<0.00>
oError:osCode : 0
oError:severity : 2
oError:subCode : 8043
oError:subSystem : BASE
oError:thread : 4
oError:tries : 0
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Aufgerufen von (B)EDIT_FORMEINTRAG(1419)
Aufgerufen von SLEPIC:GETDATA(650)
Aufgerufen von SPEICHER_FORMEINTRAG(1765)

Der Fehler ist nicht reproduzierbar, tritt aber sporadisch auf bei versch. Feldern des Datensatzes.
Server ist Win2008 R2 (aktueller Stand), Workstation ist Win7 SP1, DBF ist mit UNC-Pfad geöffnet.
Nirgends ein unlock.
Kann mir das nicht erklären...

[ramses]

Servus Werner

solche Sorgen hatte ich auch schon, Ursache auch nach langem Suchen nicht gefunden, danach habe ich mir eine Funktion geschrieben die ich nun grundsätzlich immer zum Schreiben eines geänderten Wertes verwende, diese prüft jeweils vor dem Schreiben mit DbRLockList() ob der Datensatz gesperrt ist. wenn nein wird nochmals gesperrt und zusätzlich ein Log mit Zeilennummern usw. für evtl. Nachforschungen und Korrekturen angelegt. Tut mit leid bessere Idde habe ich auch nicht, mit der beschriebenen Vorgehensweise wird wenigstens der Kunde nicht mehr mit Fehlermeldungen und Programmabbruch bemüht.

Cu Carlo

[Werner_Bayern]

Servus Carlo,

danke, mach ich jetzt auch mal so, obwohl völlig unerklärlich...
Macht das ganze natürlich nicht schneller...

Code: Alles auswählen

static function speicher_formeintrag(aEditControls)
local nControls := len(aEditControls), i, lGeandert := .f., nSatznr := formular->(recno())
local aSaetzegesperrt := formular->(DbRLockList())

if empty(aSaetzegesperrt) .or. .not. aSaetzegesperrt[1] == nSatznr
   fehler("Satzsperre von Formulareintrag ging verloren, es wird neu versucht zu sperren. Satznr: " +;
   ltrim(str(nSatznr)) + ", aktuell gesperrt: " + if(empty(aSaetzegesperrt), "NICHTS!",;
   ltrim(str(aSaetzegesperrt[1]))))
   if .not. formular->(rec_lock())
      fehler("Satz konnte nicht erneut gesperrt werden bei Formulareintrag, Satznr: " +;
      ltrim(str(formular->(recno()))))
      return .f.
   endif
endif

for i := 1 to nControls
   if aEditControls[i]:changed
      aSaetzegesperrt := formular->(DbRLockList())
      if empty(aSaetzegesperrt) .or. .not. aSaetzegesperrt[1] == nSatznr
         fehler("Satzsperre von Formulareintrag ging NACHTRÄGLICH verloren, es wird neu versucht zu sperren. Satznr: " +
         ltrim(str(nSatznr)) + ", aktuell gesperrt: " + if(empty(aSaetzegesperrt), "NICHTS!",;
         ltrim(str(aSaetzegesperrt[1]))) + LF + " " + aEditControls[i]:editBuffer())
         if .not. formular->(rec_lock())
            fehler("Satz konnte nicht erneut gesperrt werden bei Formulareintrag, Satznr: " +;
            ltrim(str(formular->(recno()))))
            return .f.
         endif
      endif
      aEditControls[i]:getData()
      aEditControls[i]:changed := .f.
      lGeandert := .t.
   endif
next i

[AUGE_OHR]

oError:subCode : 8043

der 804x ist ein "Database Order Component" Problem.
hast du eine "eigene DBESYS.PRG" ? wenn ja zeigen !

[Werner_Bayern]

Servus Jimmy,
nein, Standard-dbesys.
Order-Komponente ist Index-Datei?

[AUGE_OHR]

nein, Standard-dbesys.
Order-Komponente ist Index-Datei?

Ja ein Index gehört zur ORDER Komponente.

Frage : wo bist du "vor" deinem "edit" ? gehst du aus einem "Browse" in dein "Detail" ?

wenn du einen solche Konstruktion verwendest solltest du über Thread nachdenken um eine "eigene" Workspacelist() zu haben.
du kannst dich also im Browse bewegen ( DbSkipper() ) und die Position verändern ohne den anderen Thread zu beeinflussen.

wenn du also bei einem Browse -> Detail -> "save" diese Fehlermeldung bekommst ...
Frage : ist einer von den "REPLACE" Feldern in einem aktiven Index ?

[Werner_Bayern]

Frage : wo bist du "vor" deinem "edit" ? gehst du aus einem "Browse" in dein "Detail" ?

Ja

wenn du einen solche Konstruktion verwendest solltest du über Thread nachdenken um eine "eigene" Workspacelist() zu haben.
du kannst dich also im Browse bewegen ( DbSkipper() ) und die Position verändern ohne den anderen Thread zu beeinflussen.

Dann müsste ich die dbf aber im Thread nochmal öffnen, positionieren, sperren, schließen. Bis dahin könnte das aber schon ein anderer User gemacht haben. Das Bearbeiten der Datensätze würde dann auch relativ langsam werden.
Ich weiß, man könnte das einmalig machen und den Thread vorhalten...
Deshalb sperre ich vorher das Browse-Fenster mit :disable(), öffne ein Fenster zur Bearbeitung, schließe und zerstöre es und gib dann mit :enable() das Browse-Fenster wieder frei. Satzwebegungen / Ergeugung finden ausschließlich vorher statt.

wenn du also bei einem Browse -> Detail -> "save" diese Fehlermeldung bekommst ...
Frage : ist einer von den "REPLACE" Feldern in einem aktiven Index ?

Nein, der aktive Index und auch die anderen sind davon nicht berührt.

Danke.

[AUGE_OHR]

hi,

Dann müsste ich die dbf aber im Thread nochmal öffnen, positionieren, sperren, schließen. Bis dahin könnte das aber schon ein anderer User gemacht haben. Das Bearbeiten der Datensätze würde dann auch relativ langsam werden.
Ich weiß, man könnte das einmalig machen und den Thread vorhalten...

das mit der eigenen Workspacelist() im Thread dauert wirklich nicht "so" lange aber du kannst zumindest dann "sicher" sein das keine "Bewegung" ein Einfluss haben kann.

Deshalb sperre ich vorher das Browse-Fenster mit :disable(), öffne ein Fenster zur Bearbeitung, schließe und zerstöre es und gib dann mit :enable() das Browse-Fenster wieder frei. Satzwebegungen / Ergeugung finden ausschließlich vorher statt.

ich sag es mal so : wenn es funktioniert OK ... wenn nicht ... Problem weiter "eingrenzen"

[Werner_Bayern]

Servus Jimmy,

ja, bei uns und bei anderen Kunden funktioniert es einwandfrei und vor allem: 1-3 replace pro Feld laufen durch, erst danach knallt es. Völlig verrückt. Als ob jemand mitten drin das Patchkabel zieht und gleich wieder ansteckt...

[AUGE_OHR]

ja, bei uns und bei anderen Kunden funktioniert es einwandfrei und vor allem: 1-3 replace pro Feld laufen durch, erst danach knallt es. Völlig verrückt. Als ob jemand mitten drin das Patchkabel zieht und gleich wieder ansteckt...

was mich auf Netzwerk bringt ... du verwendest ja Win7 ...

die üblichen Fragen wegen Workstation ( XP ? ) und Server und "SMB" Sachen ... mehr Informationen erwünscht ...

[Werner_Bayern]

Servus Jimmy,

1x hatte ich das jetzt übrigens auch bei einem Kunden, der Server 2003 im Einsatz hat, dort alle WS XP mit SP3.
Bei diesem Kunden Server 2008R2, WS Vista mit SP2 und XP SP3.
Wir Server 2003 und WS Vista SP2 und Win7 SP1.
Bei allen inzwischen UNC - Pfade lt. Deiner Empfehlung.
SMB-Infos folgen gleich, muss mir den aktuellen Stand holen.

[Werner_Bayern]

Hier die Servereinstellungen (2008 R2 SP1) des genannten Kunden.

[AUGE_OHR]

hi,

die Registry sieht "frisch" aus ...
benutzt du den "SMB2" Fix von Alaska für die "Workstation" ?

Frage : was sagt das Logbuch vom Server ?
sind da Angaben zum selben Zeitpunkt wie des Absturz vorhanden ?

Als ob jemand mitten drin das Patchkabel zieht und gleich wieder ansteckt...

auch PC Hardware geht kaputt ... "on-board" oder "externe" Netzwerkkarte ?
wurde der Treiber der Netzwehrkarte "verstellt" ( Jumbo Frames etc. ) ?

[Werner_Bayern]

benutzt du den "SMB2" Fix von Alaska für die "Workstation" ?

Hab das Problem ja auch auf XP SP3 - Workstations. Nein, noch nicht, wir werden den aber jetzt mal ins Login-Script packen.
Onboard-Netzwerkkarte, schon ausgiebig getestet, Treiber auf dem aktuellen Stand und alle Einstellungen des Treibers manuell durchgegangen und eingestellt. Die alte Treiberversion sorgte allgemein für Hänger des PCs, die jetzt weg sind.

Danke.

[AUGE_OHR]

hi,

da ich weiterhin davon ausgehe das es sich um ein Index Problem handeln könnte wäre ein weiterer Test möglich

Code: Alles auswählen

oldOrd := IndexOrd() 
OrdSetFocus(0)
IF RLOCK()
    REPLACE ...
    UNLOCK
ENDIF
OrdSetFocus(oldOrd)
SKIP 0

wenn er dann beim SKIP 0 crash stimmt mit deinem Index etwas nicht ...

[Werner_Bayern]

Servus Jimmy,

nein, der Index ist es nicht.

Seit 01.08. ist nun auf allen Arbeitsstationen der smb2 von Alaska installiert. Danach alle Indexe neu erzeugt.
Jetzt häufen sich die Fatal-Abstürze:

Code: Alles auswählen

FATAL ERROR LOG 
Error within the error handling!
SYS Thread-ID: 1340 
Module: EXE
Error Codes: EH: 5 Sub: -1073741818(c0000006) OS: 0 XPP: 41
Call Stack of Thread 1 (504):
PROGRAMMENDE(612)
(B)APPSYS@0000(77)
MAIN(367)
Call Stack of GUI Thread (748):
Call Stack of Thread 3 (1056):
Call Stack of Thread 4 (1340):
(B)formularsuche(34)
FORMULARSUCHE(174)
(B)adressen(241)
@XBPPUSHBUTTON@I@HANDLEEVENT(991)
ADRESSEN(313)
Call Stack of Thread 5 (1012):
SPEICHER_FORMULAR(1229)
(B)edit_Formular(374)
EDIT_FORMULAR(1095)
(B)formularsuche(153)
@XBPBROWSE@I@HANDLEEVENT(1542)
FORMULARSUCHE(174)
(B)adressen(219)
@XBPPUSHBUTTON@I@HANDLEEVENT(991)
ADRESSEN(313)
Call Stack of Thread 6 (1648):
Call Stack of Thread 7 (1688):
DBSKIPPER(83)
(B)GUIBROWSEDB@0000(22)
@XBPBROWSE@I@DOSKIP(2191)
@XBPBROWSE@I@REFRESHROWS(2362)
@XBPBROWSE@I@REFRESHALL(2305)
(B)adressen(148)
@XBPBROWSE@I@HANDLEEVENT(1542)
ADRESSEN(313)
File: J:\Win-WW\WW.EXE
TimeStamp: 20120803 15:37
End of FATAL ERROR LOG.


FATAL ERROR LOG 
Error within the error handling!
SYS Thread-ID: 1320 
Module: EXE
Error Codes: EH: 5 Sub: -1073741818(c0000006) OS: 0 XPP: 41
Call Stack of Thread 1 (504):
PROGRAMMENDE(612)
(B)APPSYS@0000(77)
MAIN(367)
Call Stack of GUI Thread (748):
Call Stack of Thread 3 (1056):
Call Stack of Thread 4 (1020):
ADRESSEN(312)
Call Stack of Thread 5 (1320):
(B)formularsuche(34)
FORMULARSUCHE(174)
(B)adressen(241)
@XBPPUSHBUTTON@I@HANDLEEVENT(991)
ADRESSEN(313)
File: J:\Win-WW\WW.exe
TimeStamp: 20120803 17:31
End of FATAL ERROR LOG.

PROGRAMMENDE(612)

ist

Code: Alles auswählen

sleep(10)

Weiß da jemand Rat?

[AUGE_OHR]

Seit 01.08. ist nun auf allen Arbeitsstationen der smb2 von Alaska installiert. Danach alle Indexe neu erzeugt.
Jetzt häufen sich die Fatal-Abstürze:

Code: Alles auswählen

Error within the error handling!
Error Codes: EH: 5 Sub: -1073741818(c0000006) OS: 0 XPP: 41
PROGRAMMENDE(612)

Weiß da jemand Rat?

hm ... "DAS" Problem kenne ich doch ... aus dem Grund hatte ich immer meine "Befürchtungen" mit "den" Registry Einträgen.
siehe auch PDR 6289

aber wenn ich mit dein XppFatal.log genauer ansehe "denke" ich das dass Programm ja beendet wird und nicht "abstürzt" oder ?
das Xppfatal.log kommt daher weil du jetzt Threads verwendest

[Werner_Bayern]

Zumindest bei Herbert hat es nichts gebracht, die Applikation lokal zu legen.
Aber Du bringst mich auf was anderes: Ja, ich arbeite sehr viel mit Threads, aufgrund Deiner Empfehlungen in meiner Anfangszeit mit Xbase++. Vielleicht liegt es an meiner Programmende-Procedure?

Je nach Anwendungsfall laufen da mehrere Threads. Meine Procedure fürs Programm beenden sieht so aus:

Code: Alles auswählen

function programmende(cGrund, nChange)
local nButton := XBPMB_RET_OK, i, aFensterliste, nAnzahl, cDatei, nRueck := XBP_ALLOW
#include "os.ch"

if cGrund == NIL
   cGrund := "N"  // normales beenden als Vorbelegung
endif
nChange := val(var2char(nChange))
if cGrund == "E"  // Energiesparmodus
   if .not. (nChange == 0 .or. nChange == 1 .or. nChange == 4 .or. nChange == 5)
      return NIL
   endif
endif
if cGrund == "N" .or. cGrund == "Q" // Quit, also runterfahren, ohne dass das Programm beendet wurde
   playAudio(SOUNDPFAD + "Beenden.wav")
   nButton := confirmbox(,"Geänderte Daten speichern und " + if(cGrund == "Q", os(OS_FULLNAME), PROGRAMMNAME) + " beenden?",;
   PROGRAMMNAME, XBPMB_OKCANCEL, XBPMB_QUESTION+XBPMB_APPMODAL+XBPMB_MOVEABLE)
endif
if nButton == XBPMB_RET_OK
   commit
   aFensterliste := setAppWindow():drawingArea:childlist()   // alle Fenster?
   nAnzahl := len(aFensterliste)
   for i := nAnzahl to 1 step -1
      PostAppEvent(xbeP_Close, NIL, NIL, aFensterliste[i])  // Close-Nachricht schicken, damit gespeichert wird!
      sleep(10)
   next i
   sleep(30)
   //   close all  passiert in appexit()
   quit
else
   nRueck := XBP_REJECT
endif
return nRueck  // wg. :quit()

Um die Threads kümmere ich mich nicht explizit, ich sende nur jeweils die close-Nachricht an die jew. Fenster.
Fehlt da was?

[AUGE_OHR]

Fehlt da was?

JA, du musst einen Thread auch "beenden" und dann per

Code: Alles auswählen

oThread:setInterval(NIL)
oThread := NIL

"terminieren" ( mir fällt kein bessere Wort ein )

das selbe gilt übrigens auch bei activeX und DLL das man die Verbindung vor Ende "terminiert" denn ein oDialog:destroy() wird nur die XbParts "zerstören"

[Werner_Bayern]

Servus Jimmy,

mein Wissensstand ist, dass ein Thread nicht extra beendet werden muss, er beendet sich, wenn das zugehörige Fenster geschlossen und damit die Thread-Ereignisschleife beendet wird.
Das mache ich in meiner Funktion programmende() durch das senden des Close-Events.

[AUGE_OHR]

Das mache ich in meiner Funktion programmende() durch das senden des Close-Events.

Ja ... gesehen ... und das "Timing" ?

Code: Alles auswählen

DO WHILE .T.

...
   aThread := SP_Thread()                        // Array Threasds holen
   IF aThread = NIL

   ELSE
      nPosi := LEN( aThread )                   // letzte laufenden MDI Thread
      DO WHILE nPosi > 0
         // set :lThreadExit := .T.
         aThread[nPosi][ID_OBJ]:lThreadExit := .T.
         PostAppEvent( xbeP_Close,,, aThread[nPosi][ID_OBJ])

         SLEEP(10)

         // aktuelles Array holen
         aThread := SP_Thread()
         IF aThread = NIL
            nPosi := 0
            EXIT
         ELSE
            nPosi := LEN( aThread )             // letzte laufenden MDI Thread
            IF nPosi > 0
            ELSE
               EXIT
            ENDIF
         ENDIF
      ENDDO
   ENDIF
...

ENDDO 

[Werner_Bayern]

Ja ... gesehen ... und das "Timing" ?

Welches timing? Das sleep(10) ist halt drin, war mal mit 20, aktuell auf 15 gesetzt.
setInterval benutze ich nicht.

[AUGE_OHR]

Welches timing? Das sleep(10) ist halt drin, war mal mit 20, aktuell auf 15 gesetzt.

weil man das SLEEP(x) nicht genau definieren kann muss man es in einer Schleife immer wieder prüfen wie im Code oben

setInterval benutze ich nicht.

wenn man unter Thread nach sieht merkt man das o:destroy() "fehlt". mit

Code: Alles auswählen

LOCAL oThread := Thread():new()

wird ein Tread angelegt.

Code: Alles auswählen

oThread:start( "showTime", MaxRow(), MaxCol()-7 )

wird "Code" in einem Thread "ausgeführt".

auch wenn der "Code" komplett ausgeführt wurde ist der Thread damit nicht "fertigt".
mittels oThread:setInterval(nHSeconds) könnte man den "Code" erneut ausführen.

Der Thread bleibt aktiv bis das Zeitintervall wieder auf NIL gesetzt wird. Erst dann wird der Thread beendet.

also nur ein oThread:setInterval(NIL) macht das was du von einem oThread:destroy() erwarten würdest.

[Werner_Bayern]

Servus Jimmy,

hab jetzt mal in meine programmende()-Funktion folgendes eingesetzt:

Code: Alles auswählen

   aFensterliste := setAppWindow():drawingArea:childlist()   // alle Fenster?
   nAnzahl := len(aFensterliste)
   for i := nAnzahl to 1 step -1
      PostAppEvent(xbeP_Close, NIL, NIL, aFensterliste[i])  // Close-Nachricht schicken, damit gespeichert wird!
      sleep(15)
   next i
   aThreads := ThreadInfo(THREADINFO_TOBJ)
   sleep(30)

Das Array aThreads hat exakt die Länge aller bisherigen Threads (je nach Programmausführung), bis auf die ersten beiden (setappWindow und seine Statusbar) sind jedoch alle brav auf NIL. Das wäre doch ok?

[AUGE_OHR]

Das Array aThreads hat exakt die Länge aller bisherigen Threads (je nach Programmausführung), bis auf die ersten beiden (setappWindow und seine Statusbar) sind jedoch alle brav auf NIL. Das wäre doch ok?

nach einem

Code: Alles auswählen

oThread:setInterval(NIL)
oThread := NIL

sollte "nichts" von oThread mehr "sichtbar" sein.

ich sehe

Code: Alles auswählen

PostAppEvent(xbeP_Close...)

was deine Fenster schliessen soll.
wenn ein Fenster geschlossen ist kannst du auch den Thread dazu "terminieren"

das SLEEP() ist hier ein "Denkfehler" denn deine PostAppEvent() werden ebenfalls "angehalten" und kommen gar nicht "durch" bis der Code "abgearbeitet" ist.
wenn da nicht das QUIT wäre würde am Bildschirm vermutlich zunächst nichts passieren und dann (vielleicht) "alle auf einmal".