dbskip(0)-Problem / abweichend von Doku seit 1.9

[Markus Walter]

Hallo,

bin gerade wegen eines Problems daraufgestossen: dbskip(0) refreshed den Satzzeiger nicht (oder nicht richtig)!

Meine Situation:
Arbeitsplatz 1 steht auf einem Datensatz (quasi im Anzeigen). An Arbeitsplatz 2 wird dieser Datensatz gelöscht. Arbeitsplatz 1 drückt nun Enter zum Bearbeiten. Bisher ging das, da ich vor dem Editieren ein dbskip(0) verwendet habe. Das liest ja den Datensatz neu ein und aktualisiert auch Filter/Scope- und Deleted-Bedingung (zumindet steht es so in der Hilfe - im SL1). Das ist aber nicht so. In obigen Fall steht der Satzzeiger noch immer auf dem Datensatz. Ich verwende FOXCDX, SET DELETED ON und der Index ist mit !deleted() gebaut.

Es gibt dazu auch einen PDR: 5715 (offen seit build 1.90.334), allerdings funktioniert der dort angegebene Workaround bei mir auch nicht, d. h. zumindest nicht richtig: deleted() liefert dann zwar .t., aber der Satzzeiger ist immer noch auf dem gelöschten Datensatz positioniert und den kann ich auch noch munter auslesen...

Das wenigstens deleted() mit dem Workaround geht, hilft mir in meiner konkreten Situation schon mal weiter. Aber ich halte das Ganze für kritisch...

[Manfred]

Hi Markus,

wie sieht bei Dir DBFDBE_LIFETIME aus? Ich hatte das auch mal, bzw. denke dass ich das immer noch habe. Ein Hinweis von Till aus dem Jahre 2006 war, diesen Wert auf 0 zu setzen.

Es war bei mir so, dass ich etwas geändert hatte an PC 1 und PC2 konnte den Wert nicht erkennen. Jedenfalls nicht sofort. Mit DbSkip(0) war da wohl damals auch nichts zu reissen.

[brandelh]

Hi,

hast du das dbskip(0) sowohl auf dem PC1 als auch auf dem PC2 ausgeführt ?

Das muss ich doch gleich mal bei meinem Programm das noch solche Sperren einsetzt prüfen.
Allerdings habe ich immer noch nur 331 in Produktion ...

[Manfred]

Hi Hubert,

beides habe ich gemacht. Andreas und Till wollten es damals nicht glauben. Ich müßte jetzt aber auch nochmals genau nachsehen, ob und wenn ja, wie ich das Problem behoben habe.

Habe ich gerade mal gemacht. Im Moment nutze ich in der Methode kein DbSkip(0) mehr, ich habe ein DbCommit() drin. Probleme habe ich aber jetzt nicht explizit erkennen können damit.

Ah, Moment mal eben. Da fällt mir etwas ein. Bei DbSkip(0) gibt es Probleme, wenn man Sätze gelöscht hat. Wenn Set Deleted ON gesetzt ist, dann springt der Zeiger woanders hin. Deshalb habe ich das entfernt bei mir. Aber ob das jetzt für eine andere WS eine Auswirkung hat? Hm, eigentlich dürfte das ja nicht sein. Aber nur mal so zum Nachdenken.

http://www.xbaseforum.de/viewtopic.php?f=16&t=2311

[Martin Altmann]

Hallo Manfred,
was Du als Problem schilderst, ist ja gewünscht (und kein Problem)!

Viele Grüße,
Martin

[Manfred]

Hach Martin,

Seiteneffekt, blöde wenn man nicht daran denkt.... So war das gemeint

[brandelh]

Hallo Manfred,

ob es bei deinem Programm stört, weiß ich natürlich nicht
aber auf jeden Fall MUSS der Datensatz auf den nächsten NICHT GELÖSCHTEN oder EOF springen,
wenn SET DELETED ON gesetzt ist und du etwas löschst.
Möglich dass dies unter Clipper noch anders war, aber clipper brauchte auch nicht mit anderen Tasks / Threads klar kommen

Ich habe bei meinem Programm gerade getestet und das Programm erkennt sofort und richtig, dass der andere Datensatz
gesperrt wird (einer ändert, die anderen dürfen dann nicht rein) oder gar zur Löschung markiert wird.
Ich verwende allerdings auch nicht SET DELETED ON, denn ich will ja gerade auch gelöschte Sätze wieder retten können.
Meine Übersichtsseite ruft jede Sekunde die aktuellsten Daten mit SKIP(0) wieder ab und zeigt den Zustand ... wie gesagt ein altes Programm mit Clipper Optik - aber es funktioniert.

[Manfred]

Hi Hubert,

um eine gelöschten Satz wieder zu retten, dafür gibt es dann Set DELETED OFF

Um das Sperren geht es doch gar nicht Das klappt ja auch so. Das wäre ja auch eine Dingen, wenn das zeitverzögert über irgend eine Puffer laufen würde.

[Markus Walter]

Hallo,

@Manfred: DBFDBE_LIFETIME hat mit meinem Problem nichts zu tun (ich habe es aber trotzdem probiert). DBFDBE_LIFETIME wird nur benötigt, wenn mit mehreren Threads innerhalb eines Programmes auf die gleichen Daten zugegriffen wird.

@Hubert: Ob es richtig ist, dass in so einer Situation auf den nächsten Datensatz gesprungen wird, darüber kann man trefflich diskutieren. Aber das passiert bei mir ja auch nicht. Bei mir ist es so, dass der Satzzeiger auf dem (von der anderen Station gelöschten) stehen bleibt und ich den Datensatz "normal" auslesen kann. Durch den workaround von Alaska liefert aber immerhin deleted() .t. zurück.

Ich habe ein kleines sample gemacht (mit Daten). Wer es mal probieren möchte, kann es gerne haben...

Faktum ist:
- der Datensatzzeiger wird durch dbskip(0) nicht auf den nächsten Satz positioniert (wie in der Hilfe beschrieben), wenn der aktuelle Datensatz mittlerweile gelöscht wurde
- der Workaround wirkt nur auf deleted(), positioniert aber nicht um (wie im PDR geschrieben)
- gleiches Verhalten mit Build 331, 337 und 355

EDIT: rlock() auf den gelöschten Datensatz ist möglich!

[brandelh]

Hi,

das mit dem Springen könnte auch mit dem Index zu tun haben ( for ! deleted() ) ...
Ich nutze in meinen Anwendungen nie den SET DELETED ON Schalter.

[brandelh]

- gleiches Verhalten mit Build 331, 337 und 355

wobei das ja dann auch nichts mit dem SL1 zu tun hat, sondern schon (immer) so war

[Manfred]

Hi Markus,

da muß ich Dich aber enttäuschen. Ich hatte das Problem nicht mit Threads, sondern mit 2 WS. Und daraufhin hat man mir von Alaska die Sache mit DBFDBE_LIFETIME genannt. Also wenn erzählen die was schräges.

[Markus Walter]

- gleiches Verhalten mit Build 331, 337 und 355

wobei das ja dann auch nichts mit dem SL1 zu tun hat, sondern schon (immer) so war

Hallo Hubert,

ja, aber seit 331 ist das Verhalten für dbslip(0) explizit in der Hilfe beschrieben. Aber es geht nicht. Der PDR hat den OpenBuild 334, woraus man schließen könnte, das es mit 331 wie beschrieben arbeiten würde. Das ist aber nicht so.

Edit: nicht nur SL1, ich ändere mal die Überschrift...

[Markus Walter]

Hi Markus,

da muß ich Dich aber enttäuschen. Ich hatte das Problem nicht mit Threads, sondern mit 2 WS. Und daraufhin hat man mir von Alaska die Sache mit DBFDBE_LIFETIME genannt. Also wenn erzählen die was schräges.

Hi Manfred, wie auch immer, ich verstehe die Online-Hilfe in diesem Punkt anders. Aber es hat in meinem Problem keine Auswirkungen:
1. kann man warten solange man will
2. habe ich die LIFETIME in meinem Sample auf 0 gesetzt

[Manfred]

Hi Markus,

stimmt, die Anleitung beschreibt es so, wie Du es erwähnst. Und ich bin doof. Es war genau andersherum. An der gleichen WS war die Änderung nicht zu sehen, aber an einem anderen Platz war sie schon zu sehen.

Wie gut dass ich den Mailverkehr mit Alaska aufhebe.

[Markus Walter]

Hallo Manfred,

gut das wir drüber geredet haben...

[Markus Walter]

Hallo,

ich wollte meine abschließenden Erkenntnisse mitteilen:

* dbskip(0) führt nicht, wie in der Online-Hilfe beschrieben dazu, dass zum nächsten logischen Satz navigiert wird, falls der aktuelle Satz nicht mehr "gültig" ist (z. B. gelöscht wurde), PDF 5715
* Die im PDR angegebene Solution funktioniert nicht (zumindest nicht be gelöschten Datensätzen)
* Die im PDR angegebene Solution hilft, um den Status von deleted() zu aktualisieren

Insgesamt ergibt sich für mich eine Verhaltensweise, mit der ich so nicht gerechnet habe. Ich habe deshalb grundlegend meine Satz-Sperrung überarbeitet. Ich bin bisher davon ausgegangen, dass ein gelöschter Satz nicht gesperrt werden kann, wenn SET DELETED ON gesetzt ist. Dem ist nicht so. Eine Satzsperre (und damit das Ändern des Datensatzes) funktioniert genau wie bei einem nicht gesperrten Satz.
Damit ergab sich in meine Applikation, dass Anwender an einem Arbeitsplatz Datensätze bearbeitet haben, die von einer anderen Arbeitsstation bereits gelöscht waren und keiner hat es gemerkt!

Wenn man sich also darauf verlassen möchte, dass ein rlock()/dbrlock() nur bei "noch gültigen" Datensätzen .t. liefert, muss man folgende Konstruktion verwenden:

Code: Alles auswählen

FUNCTION MyRlock()
local lRet := .t.

  IF .NOT. DbRLock()
    lRet := .F.
  ELSE
    // durch das dbrlock() wurde der Satz neu eingelesen und somit auch das deleted()-Flag aktualisiert
    IF Deleted()
      DbRUnlock()
      lRet := .F.
    ENDIF
  ENDIF

RETURN .T. 

Ich halte das Ganze in "Mehrbenutzer-Systemen" für unabdingbar, wenn man mit SET DELETED ON arbeitet und mit gelöschten Datensätzen "nichts zu tun haben möchte".