Code: Alles auswählen
orte->(DbSeek(nOrt2, , "ortnum"))
IF orte->(DbRLock())
orte->(DbDelete())
ENDIF
Jan
Moderator: Moderatoren
Code: Alles auswählen
orte->(DbSeek(nOrt2, , "ortnum"))
IF orte->(DbRLock())
orte->(DbDelete())
ENDIF
Code: Alles auswählen
do while 123->(!rlock())
enddo
123->(Dbdelete())
123->(Dbunlock())
schon mal ein orte->(DbCommit()) oder orte->(DbSkip(0)) nach orte->(DbDelete()) versucht ?Jan hat geschrieben:Schon wieder etwas, was ich nicht wirklich verstehe. Ich möchte einen Datensatz löschen.Der richtige Datensatz wird gefunden. Der wird auch gelockt. Der führt auch die Löschzeile aus im Debugger. Aber es wird nichts gelöscht. Wieso nicht?Code: Alles auswählen
orte->(DbSeek(nOrt2, , "ortnum")) IF orte->(DbRLock()) orte->(DbDelete()) ENDIF
Ich mache so etwas durchaus, und ich habe noch keine Deadlocks an solchen Stellen erlebt. Meine Applikation hat die Hoheit über die Daten, und gelockt wird nur, wenn auch umgehend geschrieben - und gleich wieder entsperrt - wird. Ich sorge dafür, dass a) Daten überhaupt nicht bearbeitet werden können, wenn das parallel bereits geschieht und b) Datensätze niemals länger als für den unmittelbaren Schreibvorgang gesperrt sind. Der Benutzer bearbeitet i.d.R. Memvars, keine Datenbankfelder. Und wenn man so arbeitet, kann man auch die Sperrungen wie von Rolf gezeigt auslösen, vielleicht noch mit einem Sleep(0) innerhalb der Schleife. Ich habe das mal eine Weile loggen lassen - es gab trotz intensiver Arbeit an zig Arbeitsplätzen niemals die Situation, dass die Schleife mehr als einmal passiert werden musste. Gleichzeitig hat man den Vorteil, dass man beim Schreiben in mehrere Tabellen nicht plötzlich auf ein scheiterndes Lock reagieren muss, indem man irgendeinen Warte- oder Auswahldialog anzeigt. Lock, schreiben und entsperren stellen immer eine zwingend aufeinanderfolgende Einheit dar.sowas werde ich niemals machen.