Unlock oder Commit ?
Moderator: Moderatoren
- Marcus Herz
- 1000 working lines a day
- Beiträge: 974
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 48 Mal
- Danksagung erhalten: 235 Mal
- Kontaktdaten:
Unlock oder Commit ?
Hallo
Die Xbase++ Doku ist da unklar. Was kommt zuerst ?
Es macht offensichtlich keinen Unterschied, ich entdecke keinen. Aber trotzdem: welche Reihenfolge ist richtig(er)?
Die Xbase++ Doku ist da unklar. Was kommt zuerst ?
Es macht offensichtlich keinen Unterschied, ich entdecke keinen. Aber trotzdem: welche Reihenfolge ist richtig(er)?
Gruß Marcus
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16704
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 139 Mal
- Danksagung erhalten: 62 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Moin Marcus,
von der Logik her (um auf der sicheren Seite zu sein): erst commit und dann unlock. Aber macht nicht ein unlock implizit ein commit?
Viele Grüße,
Martin
von der Logik her (um auf der sicheren Seite zu sein): erst commit und dann unlock. Aber macht nicht ein unlock implizit ein commit?
Viele Grüße,
Martin

Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9761
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 130 Mal
- Danksagung erhalten: 441 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Und ich sehe das andersherum. Erst wenn der Datensatz freigegeben ist, hat es Sinn, ihn auch durchzuschreiben.
Herzlich,
Tom
Tom
- Martin Altmann
- Foren-Administrator
- Beiträge: 16704
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 139 Mal
- Danksagung erhalten: 62 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Die Gefahr ist aber da, das dann bereits jemand anders dran ist - ihn ggf. gelocked hat. Dann kannst Du nicht mehr durchschreiben.
Viele Grüße
Martin
Viele Grüße
Martin

Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- brandelh
- Foren-Moderator
- Beiträge: 15778
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 82 Mal
- Danksagung erhalten: 43 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
in einer gesharten Datei kann man nicht in einen Datensatz schreiben, der nicht geblockt ist, ich stimme Martin zu.
Ich meine mich zu erinnern, dass unlock erst schreibt, dann freigibt.
COMMIT wirkt übrigens auf alle offenen Dateien
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9761
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 130 Mal
- Danksagung erhalten: 441 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Du kannst ja auch ein DbCommitAll() machen, ohne dass alle Tabellen vollständig gesperrt sind. Es geht nur darum, den Cache physisch durchzuschreiben. Das hat mit den Sperrmechanismen eigentlich überhaupt nichts zu tun; es sollte völlig egal sein, zu welchem Zeitpunkt man das macht. Nur werden Änderungen, die man nach einem Commit vorgenommen hat, erst mit dem nächsten Commit oder dem nächsten impliziten Durchschreiben auf die Platte gesetzt.
Herzlich,
Tom
Tom
- Marcus Herz
- 1000 working lines a day
- Beiträge: 974
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 48 Mal
- Danksagung erhalten: 235 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Da steht nichts dazu in der Hilfe. Wäre anzunehmen.Aber macht nicht ein unlock implizit ein commit?
Ein Unlock ist das Gegenstück zu rlock, egal ob man "replaced" hat.
Ist die Datei exclusiv, ist ein Commit immer nötig/sinnvoll, soweit ich das erkenne, wird sonst erst bei einem Skip geschrieben
@Frank++: Kannst du dazu näheres erläutern?
Gruß Marcus
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
- Manfred
- Foren-Administrator
- Beiträge: 21452
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 264 Mal
- Danksagung erhalten: 88 Mal
Re: Unlock oder Commit ?
die Frage ist evtl. was Marcus erzielen will? Möchte er nur die Reihenfolge wissen, weil er heute wissbegierig ist, oder auch ob und wann wirklich geschrieben wird? Ich meine mich erinnern zu können, das ein Skip(0) am Ende auf jeden Fall schreibt. Es gibt dazu auch einige Beiträge aus alten Zeiten hier im Forum.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Martin Altmann
- Foren-Administrator
- Beiträge: 16704
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 139 Mal
- Danksagung erhalten: 62 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Naja - weder ein Skip noch ein commit schreiben physisch durch auf die Platte. Darum kümmert sich das OS. Die Daten liegen im Cache - und das ggf. noch eine Ewigkeit (zumindest aus der Sicht eines Computers). Für Xbase++ gibt es kein Warten, bis die Daten physisch auf der Platte stehen - das OS meldet erfolgt, hält die Daten aber im Cache. Beim Lesen wird natürlich auch der Cache berücksichtigt, um aktuelle Daten zu erhalten.
Wenn man aber den PC nach einem erfolgreichen Commit ausschaltet, sind die vorher erfolgreich committeten Daten ggf. vergessen.
Viele Grüße
Martin
Wenn man aber den PC nach einem erfolgreichen Commit ausschaltet, sind die vorher erfolgreich committeten Daten ggf. vergessen.
Viele Grüße
Martin

Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Marcus Herz
- 1000 working lines a day
- Beiträge: 974
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 48 Mal
- Danksagung erhalten: 235 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Das liest den Satz neu von der Platte, also genau das Gegenstück zu CommitSkip(0)
Gruß Marcus
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
- komnick
- UDF-Programmierer
- Beiträge: 79
- Registriert: Mi, 04. Jun 2014 9:56
- Wohnort: Berlin
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 7 Mal
Re: Unlock oder Commit ?
Hallo allerseits,
historisch betrachtet käme zuerst UNLOCK und dann COMMIT.
Denn zu Clipper-Zeiten hat man noch zwischen dem Clipper-Puffer und dem DOS-Puffer unterschieden.
Ein UNLOCK (und auch eine Bewegung des Satzzeigers) bewirkte damals die Übergabe des Clipper-Puffers an DOS. Wollte man sicherstellen, dass die Daten aus dem DOS-Puffer auf die Platten geschrieben werden, hat man COMMIT benutzt.
(Quelle: "Das Clipper 5.2 Buch", Sybex)
Beste Grüße
Martin
historisch betrachtet käme zuerst UNLOCK und dann COMMIT.
Denn zu Clipper-Zeiten hat man noch zwischen dem Clipper-Puffer und dem DOS-Puffer unterschieden.
Ein UNLOCK (und auch eine Bewegung des Satzzeigers) bewirkte damals die Übergabe des Clipper-Puffers an DOS. Wollte man sicherstellen, dass die Daten aus dem DOS-Puffer auf die Platten geschrieben werden, hat man COMMIT benutzt.
(Quelle: "Das Clipper 5.2 Buch", Sybex)
Beste Grüße
Martin
- Marcus Herz
- 1000 working lines a day
- Beiträge: 974
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 48 Mal
- Danksagung erhalten: 235 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Nach einem dbAppend ist ja immer ein dbcommit nötig, kein unlock
Gruß Marcus
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9761
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 130 Mal
- Danksagung erhalten: 441 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
APPEND BLANK oder DbAppend() fügen einen leeren Datensatz an und sperren ihn. Wenn Du irgendwie damit weiterarbeiten willst, musst Du ihn durchaus wieder entsperren. Das Verhalten ist das gleiche wie der Sprung zu einem Datensatz und seine Sperre für die Bearbeitung, mit dem Unterschied, dass hier zu einem neuen, leeren Datensatz gesprungen wird.kein unlock
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15778
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 82 Mal
- Danksagung erhalten: 43 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Also ich speichere erst die neuen Daten in dem Datensatz, bevor ich weiter mache

dbUnlock() reicht aus meiner Erfahrung (solange das Betriebssystem darunter nicht der Meinung ist, Änderungen erstmal zu verbergen),
danach mach ich ein skip(0) um tatsächlich alle Buffer neu zu laden.
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9761
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 130 Mal
- Danksagung erhalten: 441 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Ich habe Marcus' Behauptung widersprochen, dass nach einem DbAppend() kein Unlock nötig wäre. Tatsächlich ist es genauso nötig wie nach der Aktualisierung eines bestehenden Datensatzes, den man zuvor gesperrt hat. Technisch ist's sogar dasselbe, wobei DbAppend() zusätzlich den leeren Datensatz anhängt, den es zu bearbeiten (zu aktualisieren) gilt.Also ich speichere erst die neuen Daten in dem Datensatz, bevor ich weiter mache
Und "gespeichert" ist's sowieso. Ein FieldPut() bzw. REPLACE ist ein Vorgang, der Daten in einem Datensatz speichert. Das, was vermeintlich durch DbCommit ausgelöst wird, ist das Durchschreiben auf irgendwelche physikalischen Datenträger, aber ich wage tatsächlich zu bezweifeln, dass das im Jahr 2024 immer noch so ist. Ein Commit finalisiert Transaktionen auf einem Datenbankserver, aber wenn wir mit dateibasierten DBMS arbeiten, haben wir überhaupt keinen. Ich halte das genau genommen für überflüssig (obwohl wir's im Code haben, jedenfalls hier und da, aber eher aus den Gründen, aus denen sich Leute Christopherusplaketten ins Auto hängen).
Herzlich,
Tom
Tom
- mikehoffmann
- Rekursionen-Architekt
- Beiträge: 141
- Registriert: Mo, 21. Sep 2015 16:22
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 27 Mal
Re: Unlock oder Commit ?
Auf O/S Ebene hat man durchaus Einfluss darauf, ob ein File gepuffert wird. Da gäbe es zum Beispiel FILE_FLAG_NO_BUFFERING als Würze beim Öffnen einer Datei. Auch das physische Rausschreiben kann man mit FlushFileBuffers erzwingen. Wie weit das physische Schreiben wirklich physisch ist, hat man nicht unbedingt im Griff, denn spätestens wenn die Platte (oder was sich dafür hält) einen Puffer hat, dann kann es zu Staus auf der A3 kommen. Diese pikanten Details stehen einem bei einer DBF aber nicht zur freien Verfügung.
Dass die Caches für Differenzen in den sichtbaren Daten in den DB-Äffchen sorgen, glaube ich nicht. So schlau sind die Fensterchen schon, dass geteilte Dateien durch den selben Cache gefahren werden. So isses auch mit den Dateien im Netzwerk.
Was die Lockerei angeht, so ein Lock ist wie ein kritischer Bereich, in dem man die gelockten Daten verändern darf und es ist sichergestellt, dass alle anderen nach dem Freigeben des Locks die frisch geschriebenen Daten sehen. Das ist mehr oder minder heikel. Wenn ich nur lesend auf der DBF rumeiere ist das ziemlich egal, aber wenn ich durch einen Lock ankündige, etwas zurückschreiben zu wollen, dann muss erst mal neu gelesen werden.
Heißt:
RLock() => Locken, dann nochmal lesen.
UNLOCK: => Schreiben, dann unlocken.
Könnten wir mal ausprobieren, was wirklich passiert. Und vorher Wetten abschließen. Wer verliert, muss einen Vortrag halten und Fragen zulassen.
Dass die Caches für Differenzen in den sichtbaren Daten in den DB-Äffchen sorgen, glaube ich nicht. So schlau sind die Fensterchen schon, dass geteilte Dateien durch den selben Cache gefahren werden. So isses auch mit den Dateien im Netzwerk.
Was die Lockerei angeht, so ein Lock ist wie ein kritischer Bereich, in dem man die gelockten Daten verändern darf und es ist sichergestellt, dass alle anderen nach dem Freigeben des Locks die frisch geschriebenen Daten sehen. Das ist mehr oder minder heikel. Wenn ich nur lesend auf der DBF rumeiere ist das ziemlich egal, aber wenn ich durch einen Lock ankündige, etwas zurückschreiben zu wollen, dann muss erst mal neu gelesen werden.
Heißt:
RLock() => Locken, dann nochmal lesen.
UNLOCK: => Schreiben, dann unlocken.
Könnten wir mal ausprobieren, was wirklich passiert. Und vorher Wetten abschließen. Wer verliert, muss einen Vortrag halten und Fragen zulassen.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9761
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 130 Mal
- Danksagung erhalten: 441 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Bis zum "Und" wäre ich dabeigewesen.Wer verliert, muss einen Vortrag halten und Fragen zulassen.

Herzlich,
Tom
Tom
- Marcus Herz
- 1000 working lines a day
- Beiträge: 974
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 48 Mal
- Danksagung erhalten: 235 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Das hab ich mir für heute Vormittag vorgenommen. Ich teile die Ergebnisse dannKönnten wir mal ausprobieren,
Gruß Marcus
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
- Marcus Herz
- 1000 working lines a day
- Beiträge: 974
- Registriert: Mo, 16. Jan 2006 8:13
- Wohnort: Allgäu
- Hat sich bedankt: 48 Mal
- Danksagung erhalten: 235 Mal
- Kontaktdaten:
Re: Unlock oder Commit ?
Da hat Manfred schon recht. Im Browser gibt es eine generische Schreibroutine, welche alle Datenbankvarianten abdecken muss:die Frage ist evtl. was Marcus erzielen will? Möchte er nur die Reihenfolge wissen, weil er heute wissbegierig ist,
- DBF
- ADS
- PostgreSQL
- SqlExpress
- ODBC
Xbase+ DBF, shared
-> dbrlock() // Satz in dbrlocklist() sichtbar
-> dbunlock() // wie erwartet, jetzt auch für andere sichtbar
Aber:
-> dbrlock() // Satz in dbrlocklist() sichtbar
-> dbcommit() // Satz wird geschrieben, ist jetzt schon für andere sichtbar, aber immer noch gesperrt
-> dbunlock() // dbrlocklist() leer
Und:
-> dbrlock() // Satz in dbrlocklist() sichtbar
-> dbskip(0) // keine Auswirklung
-> dbunlock() // wie erwartet, jetzt auch für andere sichtbar
Aber:
-> dbrlock() // Satz in dbrlocklist() sichtbar
-> dbskip(1) // wie dbcommit()
-> dbunlock() // dbrlocklist() leer
Xbase+ DBF, exclusiv
dbrlocklist() bleibt leer, weil kein Satz gesperrt wird. dbrlock() gibt aber true zurück:
-> dbunlock() // schreibt satz
oder:
-> dbcommit() // schreibt satz
oder:
-> dbskip(1) // schreibt satz
Aber:
-> dbskip(0) // schreibt satz NICHT
Bei DbAppend() verhält sich Xbase++ DBF genauso. Der neue Satz ist auch in der DbRlocklist()
Ein DbCommit() nach einem dbUnlock() scheint keinen mir sichtbaren Effekt zu haben.
ADS, getestet auf API Ebene, nicht ADSDBE
Hier wir ein Schreibbefehl erwartet. API Funktion AdsWriteRecord, was einem Commit entspricht.
-> AdsLockRecord = DbRlock()
-> AdsWriteRecord() = DbCommit() UND dbUnlock()
-> AdsUnlockRecord() = DbCommit() UND dbUnlock() // es reicht also nur eine von beiden Funktionen aufzurufen
Oder:
-> AdsLockRecord = DbRlock()
-> AdsSkip(1) // schreibt Satz, bleibt gesperrt
Aber:
-> AdsLockRecord = DbRlock()
-> AdsSkip(0) // liest den Satz erneut ein und verwirft Änderungen!.
Bei PostgreSQL, ODBC erfolgt das Schreiben ja über die SQL Befehle und ist in dieer Auflistung nicht relevant.
So stehts übrigens in der Xbase Hilfe
undIF RLock()
REPLACE FIELD->LASTNAME WITH cLastName
DbCommit()
DbUnlock()
ELSE
Alert( "Record is locked. Cannot update data", {"Ok"} )
ENDIF
DbAppend()
FIELD->CUST_ID := 2006
FIELD->NAME := "CapeHorn"
DbCommit()
Gruß Marcus
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
Den Kopf in den Sand zu stecken rettet die Welt auch nicht.
- mikehoffmann
- Rekursionen-Architekt
- Beiträge: 141
- Registriert: Mo, 21. Sep 2015 16:22
- Hat sich bedankt: 1 Mal
- Danksagung erhalten: 27 Mal
Re: Unlock oder Commit ?
Ich wäre noch eine Etage tiefer eingestiegen, da wo Xbase++ das API bemüht. Nur so sieht man, was wirklich passiert.