Warum wird nicht gesperrt?

[Jan]

Eine dumme Frage (vermutlich): Was verhindert, das ein DBRLock() nicht funktioniert? Der Satz ist nicht gesperrt(lt. DBRLockList() ist überhaupt kein Satz in der dbf gesperrt), der Datensatzzeiger steht auf einem gültigen Satz (ich kann den Satz ansprechen und auslesen), die Sperrung wird mir Alias ausgeführt, trifft also in jedem Fall die richtige dbf. Und dennoch gibt es mir ein .F. zurück. Warum?

Jan

[Tom]

Code?

[Jan]

Code: Alles auswählen

IF genealog->(RLock()) == .F.
   genealog->(DbUnlock())
   dummy := genealog->(DbRLockList())  // Rückgabe: {}
   dummy := genealog->rin              // Rückgabe: 1, Stimmt so für den ersten Datensatz.
ENDIF
IF genealog->(RLock()) == .T.          // Springt über die IF-Schleife. Warum?

Wenns denn weiterhilft...

Jan

[Martin Altmann]

Was soll das???
Wozu dein zweites If
Warum machst Du das nicht einfach in den else-Teil

Viele Grüße,
Martin

[Jan]

Was das soll? Ich will rausbekommen, warum der ständig über die 2. IF geht. Also hab ich vorher entsperrt und eine Liste aller gesperrten Sätze erzeugt. Und trotzdem: Der springt über die 2. Schleife. Warum? Das ist hier die Frage.

Jan

[Tom]

Hallo, Jan.

Alias->(DbRLock()) versucht, den Datensatz zu sperren, und gibt .T. zurück, wenn das gelingt. Wenn .F. zurückgegeben wird, kann der Datensatz nicht gesperrt werden. Du fragst also nicht ab, ob der Datensatz gesperrt ist, sondern Du versuchst, ihn zu sperren. Kann es sein, dass hier ein Verständnisproblem begraben liegt? Das zweite IF kann nie feuern, weil RLock() WAHR zurückgibt, wenn es gelingt, und wenn nur diese Anwendung auf die Tabelle zugreift, und sie shared geöffnet ist, wird das immer gelingen.

[Jan]

Hallo Tom,

ähm, ist es einfach nur zu spät, oder hab ich da wirklich ein Verständnisproblem? Du macht mich im Moment ganz irre.

Die eigentliche Schleife in meinem Code ist die 2. Schleife

Code: Alles auswählen

IF genealog->(RLock()) == .T.

So, und jetzt die Verständnisfrage. RLock() gibt zurück, ob das Sperren erfolgreich war oder nicht. Wenn das Sperren also erfogreich war, dann geht der in die Schleife rein, und wenn nicht, dann eben nicht. Oder etwa nicht?

Abgesehen davon: Ich entsprerre in der Schleife davor alles. Das passiert definitiv, das kann ich im Debugger sehen. Und dennoch kann ich in der 2. Schleife nicht sperren. Warum nicht? Es ist doch definitv keinerlei Sperre mehr vorhanden.

Abgesehen davon: Der Code funktioniert fast immer, bis auf einen Fall. Und genau das möchte ich rausbekommen, was denn dieser eine Fall ist. Alleine darum geht es mir. Die erste Schleife ist nicht original im Code drin, die hab ich nur zur Fehlerfindung reingeschrieben.

Jan

[Tom]

Hallo, Jan.

DbRLockList() gibt die die gesperrten Datensätze der aktuellen Workarea zurück. Ich nehme an, dass der Datensatz noch in einer anderen Workarea gesperrt ist. Was bekommst Du, wenn Du DbRLockList() vor dem Unlock aufrufst?

[Jan]

Hallo Tom,

das hatte ich auch schon versucht. Das gibt ebenfalls ein leeres Array.

Aber: Warum wird in der 2. Schleife nicht gespeert, wenn doch in der 1. Schleife definitiv nix mehr gesperrt ist? Und ich doch definitiv auch den gleichen Alias nutze? Der MUSS doch in die 2. Schleife reingehen. Oder?

Jan

[Tom]

Vermutlich, weil die Tabelle parallel unter einem anderen Alias geöffnet und dort gesperrt ist. Prüf doch mal WorkSpaceList() (und anschließend, wenn das etwas ergibt, weiter mit DbInfo()).

[Jan]

Tom,

WorkSpaceList() war eine gute Idee! Aber leider auch nicht das Richtige. Die dbf steht wirklich nur 1 mal drin.

Jan

[AUGE_OHR]

WorkSpaceList() war eine gute Idee! Aber leider auch nicht das Richtige. Die dbf steht wirklich nur 1 mal drin.

du arbeitest doch mit Thread ? Also hast du WorkSpaceList() für jeden Thread gemacht ?
btw. ein "re-boot" hast du doch sicherlich versucht ...

[Jan]

Moin Jimmy,

ja, ich arbeite mit Threads. Aber in jedem Thread werden die dbf neu geöffnet. Und damit kommen sich die Sperrungen nicht ins Gehege. Abgesehen davon: In dem anderen Thread wird ein anderer Satz gesperrt. Das kann es also auch nicht sein.

Jan

[Markus Walter]

Moin Jimmy,

ja, ich arbeite mit Threads. Aber in jedem Thread werden die dbf neu geöffnet. Und damit kommen sich die Sperrungen nicht ins Gehege.

Wie kommst Du auf die Idee? Wenn ein Satz gesperrt ist, egal ob von einem anderen Computer, einem anderen Thread, in einem Alias, what ever, ... kann er nicht mehr gesperrt werden.

Abgesehen davon: In dem anderen Thread wird ein anderer Satz gesperrt. Das kann es also auch nicht sein.

Bist Du da sicher?

Übrigens, diese Zeile

Code: Alles auswählen

IF genealog->(RLock()) == .F.

sperrt den Datensatz (falls er nicht schon gesperrt ist). und genealog->(RLock()) liefert dann .t., d. h. das Unlock darunter wird nicht ausgeführt. Da könnte der Hase begraben sein...

[Rolf Ramacher]

Hi Jan,

warum machst du das nicht so:

Code: Alles auswählen

Do While 123->(!RLock())
		EndDo
.... - anweisung
123->(DbUnlock())

So mache ich es immer

[Jan]

Markus,

ich wußte doch, daß ich da irgendwo einen Gedankenfehler habe. Das muß ich mal kontrollieren. Aber dennoch sollte es so sein, daß nie der gleiche Datensatz in zwei verschiendenen Threads geöffnet sind. Sollte sein. Werd ich heute Abend als erstes prüfen.

Rolf,

das wär ja eine Katastrophe! Was, wenn der nie sperren kann? Dann läuft der bis zum St.-Nimmerleinstag in der Endlosschleife.

Jan

[Rolf Ramacher]

Hi Jan

ja das stimmt. Aber dann müßte der Datensatz ja genausolange von einem anderen Programm / anwender gesperrt sein. Aber es kommt natürlich auf die anwendung an. Bei mir passt das immer.

[brandelh]

Hallo,

wenn ich die Dateien immer in der gleichen Reihenfolge sperrt,
die Daten replaced und danach wieder frei gebt, dann wird ein Satz der wartet
und es in einer Schleife versucht irgendwann zum Ziel kommen.

Wenn aber die gesperrte DBF 1 auf die Sperre von DBF 2 wartet und in einem anderen Teil / Programm
eine Funktion wartet die DBF 2 schon gesperrt hat und nun DBF 1 (entweder komplett oder diesen Satz)
braucht, dann habt eine DEAD LOCK Situation und wartet bis der Stom ausfällt