Datensatzsperre geht verloren?

[Wolfgang Ciriack]

Hallo,

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.
Zitat:
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.

Ist dem wirklich so ??
Ich habe das so verstanden, dass wenn ein neuer Thread erzeugt wird und setInterval nicht benutzt wird (Standard nil),
der Thread auch mit der Beendigung wieder destroyed ist. Nur wenn explezit ein setInterval(x) gesetzt wird, bleibt der Thread erhalten !
Kann da jemand etwas zu sagen ?

[Martin Altmann]

Moin Wolfgang,
nicht anders hatte ich es verstanden - war auch etwas überrascht ob der neuen Erkenntnis. Heißt aber nicht, dass ich das auch vorher richtig interpretiert hatte

Viele Grüße,
Martin

[brandelh]

Wenn ein Interval() gesetzt ist, wird zwar versucht den Thread (genauer den auszuführenden Code) neu zu starten,
dies ist eine Alternative zu einer Schleife im Thread-Code.
Was bestehen bleibt ist das Thread-Objekt als solches und das kann über intervall automatisch den code neu ausführen.

Ein destroy() sollte aber alles platt machen, ob das brutale platt machen (destroy()) ohne vorheriges Ende des Threads gefährlich ist,
hängt sicher von der Art der Verarbeitung ab, daher ist ein setInterval(NIL) sicherlich sinnvoll.

Die Hilfe mag etwas missverständlich sein:

Die Methode :setInterval() definiert ein Zeitintervall, nach dessen Ablauf ein Thread automatisch erneut gestartet wird.
Er führt dann wiederholt den Programmcode aus, der bei der Methode :start() angegeben wurde.

so der code läuft durch, ähnlich einem Hauptprogramm das ein Fenster öffnet und keine eventloop setzt.
Das ist eindeutig !

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

Hiermit ist das ThreadObjekt gemeint und nicht der Code den der Thread ausführen soll.
Klar ist "der Thread" noch aktiv, sonst könnte er interval() nicht beachten, aber sobald der Code durch ist ist er durch.
Nun ja, solange der code schneller abgearbeitet werden kann, als das nächste interval() zuschlägt

[AUGE_OHR]

der Thread auch mit der Beendigung wieder destroyed ist.

bitte mal unter o:destroy() nachsehen ob ihr dort Thread "findet" ...

[brandelh]

dazu dient der Klassenbaum der Klassenfunktion Thread() ... und tatsächlich findet sich da kein destroy() =D>

[Werner_Bayern]

nach einem

Code: Alles auswählen

oThread:setInterval(NIL)
oThread := NIL

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

Code: Alles auswählen

aThreads := ThreadInfo(THREADINFO_TOBJ)

zeigt:

{{thread}, {thread}, {NIL}}

Ist doch nichts anderes, als Du schreibst?

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".

Richtig, aber falsch da jeder Thread in einer eigenen Ereignisschleife läuft wird das auch brav ausgeführt. Funktioniert soweit seit längerem.

[Werner_Bayern]

Alaka verweist hier auf PDR 6289.

[Werner_Bayern]

Heute wieder bei einem Kunden, Errorlog:

Satzsperre von Formulareintrag ging verloren, es wird neu versucht zu sperren. Satznr: 433779, aktuell gesperrt: 433778

Der Quelltext dazu:

Code: Alles auswählen

static function speicher_formeintrag(aEditControls)
local aSaetzegesperrt := formular->(DbRLockList()), nSatznr := formular->(recno())

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!", var2char(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

Kann das ein langsamer PC im Netz sein, dass das Browse irgendwie doch noch nicht ganz stabilisiert ist und dadurch der falsche Satz gesperrt wird? Nein, weil ja der gesperrte Satz zur Bearbeitung angezeigt wird...

Es wird einfach aus einem Browse ein Satz zum Bearbeiten ausgewählt, gesperrt, bearbeitet und danach obige Funktion aufgerufen. Ein Skip gibt es in der Bearbeitungs-Routine nicht...

Der Browse-Codeblock sieht so aus:

Code: Alles auswählen

oBrowse:itemSelected := {|| oFenster:disable(), edit_Formeintrag(.f., oDlg), xbpBrowse_stabil(oBrowse, .f.), oFenster:enable(), SetAppFocus( oBrowse ) }

In edit_Formeintrag() steht eigentlich nur:

Code: Alles auswählen

static function edit_Formeintrag(lNeu, oDlg)
if .not. rec_lock()
   return NIL
endif

oFenster := 

[AUGE_OHR]

Heute wieder bei einem Kunden, Errorlog:

Satzsperre von Formulareintrag ging verloren, es wird neu versucht zu sperren. Satznr: 433779, aktuell gesperrt: 433778

jetzt ist nur noch die Frage wie du die Meldung reproduzieren kannst ...

p.s. versuch statt rec_lock() -> DbRLock(nSatznr)

[Werner_Bayern]

jetzt ist nur noch die Frage wie du die Meldung reproduzieren kannst ...

p.s. versuch statt rec_lock() -> DbRLock(nSatznr)

Kann ich nicht, passiert nur bei 2 Kunden ab und an.

Warum DbRlock?

[AUGE_OHR]

Warum DbRlock?

einfach nur weil du dann eine Variabel für die RECNO() hättest die man vergleichen könnte ...